共计 4064 个字符，预计需要花费 11 分钟才能阅读完成。
作者：孤戈
最近一年来，随着咱们的客户对于云技术的诉求从资源疾速交付的服务，转变为对资源精益使用的服务。EDAS 团队联合公共云上所服务的企业类客户的几万个利用，选取了 8 个最具代表性的指标，进行了一次系统性的剖析整顿和总结，心愿能够给以后正在从事软件架构的从业人员一个侧面的视角，来理解一些当下产生在身边的技术景象。
报告内容
JDK 版本散布
解读
在 JDK 9 之前，JDK 基本上均匀每三年出一个版本。然而自从 2017 年 9 月分推出 JDK9 到当初，JDK 开始了疯狂更新的模式，基本上放弃了每年两个大版本的节奏。到当初曾经公布了十个版本到 JDK 19。其中包含了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏显著放慢之外，JDK 也围绕着云原生场景的能力，推出了一系列诸如容器内资源动静感知、无进展 ZGC、云原生平安等方面的能力。不过从 EDAS 中的数据也能够看出，目前大部分的用户目前次要停留在 JDK8 上，近一年能看得出大家无意识的在往高版本上聚拢。这里情谊揭示一下，JDK8 的确是最为经典的一个版本，然而他的推出曾经是八年前，官网的反对与更新也曾经进行一段时间，倡议大家尽快降级到比拟新的 LTS 版本。如果的确因为客观原因无奈降级的用户，也倡议应用阿里巴巴开源的收费的 JDK 版本 DragoonWell，可取得无差别的兼容能力。
微服务框架散布
解读
服务框架是微服务体系中最为重要的一个技术组件，在业务开始之初确定选型之后，基本上会随同整个业务的生命周期，直至业务呈现大范畴重构。HSF 是阿里巴巴外部应用最为宽泛的一个服务框架，整个电商零碎都围绕 HSF 进行构建，EDAS 产品化之后，HSF 也追随商业化节奏输入到了很多的国计民生的业务中。到起初咱们重启了 Dubbo 的开源，Dubbo 以优雅的设计，丰盛的扩大能力，和性能强劲的通信框架取得了程序员的宽泛认可。在起初的云原生席卷之下，有越来越多的客户开始抉择了 Spring Cloud + Kubernetes 这一状态作为架构选型上的默认搭配。云原生下另一被认为是将来的微服务架构是 Service Mesh，它以语言无侵入的设计，交融全流程的流量治理能力推出之初就足够惊艳，然而任何技术都不会相对的完满，近几年微服务框架是 Fast SDK 还是 Mesh 的争执也始终在进行。在目前咱们察看到的景象来看，这一理念曾经被越来越多的客户承受，但落地场景目前大部分还是存量异构业务架构的通信能力上。从技术成熟度曲线来看，Mesh 行将往成熟期迈进。
云资源状态散布
解读
在公共云上 EDAS 一共反对虚拟机 ECS、Kubernetes 与 Serverless 三种状态，从数据上看，随着 Kubernetes 成为微服务架构状态下的默认抉择，Kubernetes 利用的占比第一年超过 ECS，从去年的 45% 攀升至 67%。另外随着大家对于降本诉求显著减少，Serverless 以低资源碎片、免运维全托管、随用随弹的个性，变得越来越风行。阿里云本身的云产品也很多都在以 Serverless 的状态进行从新托管，而微服务以无状态的属性，和 Serverless 的弹性更加的符合。针对存量利用曾经是 Kubernetes 集群的场景，EDAS 也反对以原有资源为根底，应用 Serverless 资源承载弹出来的负载的混合资源调度形式。也加强了以利用为维度将微服务和 Serverless 的技术交融，可使原有利用在无需任何革新和迁徙的状况下取得 Serverless 的技术红利。
利用实例规格散布
解读
ECS 利用的规格次要集中在 2C4G、4C8G、8C16G 中，同时大规格的利用也占据了相当大的一部分；同时以 Kubernetes 利用的规格更加多样化，除去有将近 30% 的利用没有设置 Request 或 Limit 的场景，有设置的利用中，支流 Kubernetes 的利用规格均以小规格为主，占比最大的规格为 CPU:MEM = 0.25C1G 的规格。这一数据很能阐明云原生的劣势，即容器以轻量隔离的形式，反对主机内任意资源的调配，即便在 JVM 默认会占用大块内存的利用状态下，大部分的微服务利用在运行时仍然只须要很小的资源就能保障稳固运行。相比于虚拟机的的场景，不仅能提供更加丰盛的规格来满足业务的状态，而且还能以更高密的部署状态来晋升资源的整体使用率。
JVM 堆内存设置散布
解读
内存资源区别于其余的根底资源（网络、计算、存储），是一种非压缩的资源。咱们给客户提供优化倡议时，这是一个最重要的参考指标。在 JVM 中，因为自身堆的设计，叠加容器内 CGroup 对于内存调配的影响，让容器内的内存变得愈发的奢侈迷离。在最近的几个 JDK 版本公布过程中，GC 技术是每个版本中最为重要的更新之一，从 G1 到 ZGC 再到 Shenandoah GC，在以前经典且优良的 GC 设计根底之上，新陈代谢。围绕着云原生场景推出了一系列让人振奋的新的能力，如：JEP 351 中定义的 “Uncommit Unused Memory” 让 JVM 能够有机会将未应用的堆偿还内存给操作系统。JEP 387 中定义的 “Elastic Metaspace” 让 JVM 能够有机会将未应用的 Metaspace 归还给操作系统。JEP 393/424 中定义了全新的 Foreign Memory/Function/Linker Access API 等等，这些迹象表明即便 JVM 也在新的云原生场景下，正在一步步的实现本人的变质，使本人更加云原生，一步步的将云计算的红利向咱们开释。
利用启动时长散布
解读
利用启动时长间接影响整个业务的衰弱水平，尤其是在公布场景下，因为过程有一个重启切换的过程，利用启动越快，能够更小范畴的影响利用的公布带来的流量损耗。近年来，各个云计算的厂商在应用各种不同的技术手段来优化利用冷启动的时长，在不思考利用本身启动时长的前提下，很多云厂商基本上都冲破了秒级启动的场景，当初在进一步攻克毫秒级的冷启动能力。抛开云厂商利用自身的基础设施进行一直的优化之外，咱们本人的业务初始化是否能做到疾速的冷启动这个话题更值得咱们本人去探索。失常来说，启动的工夫次要散布在利用的构建，调度与初始化阶段：
- 在构建和调度阶段，构建之后须要将更新的镜像层进行从新推送，这也会进一步导致在 POD 调度之后更新所更新镜像层的从新拉取。所以咱们要正当利用容器镜像自身的分层机制，做最大水平的缓存是晋升的要害
- 在初始化阶段，在主容器启动之前，要尽量避免 init-container 执行工夫过长；同时在主容器启动拉起 JVM 之后，新版本的 JDK 也提供了 CDS 这样的 Class 预加载技术，如果能正当利用在业务类很大的利用中，可节俭大量的冷启动工夫。
弹性策略应用状况散布
解读
从数据上来看，虚拟机的利用类型弹性（8.2% 的利用设置了弹性策略）占比反而比容器状态（仅有 1.37% 的利用设置了弹性策略）比拟高，不过都处在一个较低的程度。而弹性规定上，60% 的利用都趋向于间接应用根底指标的 CPU 弹性。弹性能力是云计算诞生以来，带来的最大的技术红利。在满足业务平时流量的前提下，用户能够将突发流量所须要用到的资源以弹性的形式看待。站在资源供应的角度来说可分为以下三种：
- 第一种是按需新购：即从 0 到 1 的供应模式，在须要应用时再长期将资源买入。
- 第二种是资源池化：即先将资源进行池化解决，在须要时调配，不须要时偿还。利用各个利用的资源峰值不一样，将资源进行主动的调配。
- 第三种是混合调度：即池化和按需新购相结合，在池化的资源仍然不能满足最终容量的时候，将须要弹性调配的资源按需购买再进行利用的扩容。
EDAS 始终继续在优化各个场景下的弹性伸缩能力，如：在 ECS 虚拟机类型的利用场景中，从利用视角反对长期购买的形式将资源一步接入到利用中；在容器的场景中，不仅提供资源混合调度的能力，而且也提供基于容器服务 ACK 的智能预测 AHPA 机制，让弹性行为先一步于业务顶峰触发，保障流量顶峰真正到来时的服务质量。在资源高效利用、业务间断稳固这两个场景下，咱们会继续耕耘，永不平息。
利用衰弱度指标散布
解读
第一张图的 CPU 利用率是统计了所有利用在一天中的平均指标，简略了解就是绝大多数的 CPU 利用率为 10% 以下。第二张图和第三张图别离是所有利用的错误率（4xx/5xx/RPC Error 等）分布图和响应工夫分布图。这个三个数据，如果是在同一个业务中（即有业务的上下游关联关系），它大抵能够解读为：在提供肯定的资源容量下，零碎的稳定性（响应工夫 + 响应错误率）状况。这在压测场景下是一个通用的零碎容量评估指标。
如上图所示，资源供给量和零碎稳定性，不是一个相对的线性关系，在性能评估的过程中，咱们次要是须要评估两个点：第一个性能前拐点是 P1，在这个点之前，能够简略了解为整个的稳定性吞吐会随着资源的减少而减少。然而达到这个点之后，单纯的资源减少并不能带来更好的零碎稳定性，这个时候咱们须要去优化的是业务逻辑、业务架构、或者其余的基础设施（如参数调优等）。找到并一直的将这个点往左移，是咱们在惯例的零碎压测时最次要的指标。
第二个性能后拐点是图中的 P2，这个往往被大部分人所疏忽，因为相对意义上的程度伸缩的零碎太现实了，咱们绝大多数利用尤其是微服务利用依赖盘根错节，单纯优化一处的资源等到咱们的业务量真正上来的时候往往是不够的，因为我的依赖方（DB、Redis、上游利用、或其余基础设施容量等）可能无奈做到程度扩大来应答有限的容量。
尾言
这一份报告，某些数据能反馈出当下风行的技术趋势，能够联合咱们本人所从事的业务零碎有一个行业维度的对照，然而不能一概而论简略的套到咱们本人的业务状态中。技术跟随着肯定的趋势像大河一样往前涌动。在每一个当下，如何使用技术为咱们的业务发明更多更大的价值，是咱们技术人员始终应该去谋求的指标。EDAS 作为一个云原生利用 PaaS 平台，始终围绕着微服务这种工作负载类型联合云技术，给大家提供以利用为核心的最佳技术实际。让大家在微服务架构在云原生场景着落地的过程中，少走一些弯路，缩短落地门路。
点击此处查看 EDAS 详情
