报告内容
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 平台，始终围绕着微服务这种工作负载类型结合云技术，给大家提供以应用为中心的最佳技术实践。让大家在微服务架构在云原生场景下落地的过程中，少走一些弯路，缩短落地路径。
