背景

流量治理和容量管理是作为一个应用管理平台最核心的两个技术领域，随着云计算的技术逐步演进，随着在基础设施和架构的不断演进，两者都发生了截然不同的变化。这篇文章是阿里云 EDAS 团队在近八年服务客户的过程中，在这个两个技术领域方向往云时代迈进时所呈现出来的不同进行深入剖析与总结，以帮助大家在更好的理解云上环境的特点，在生产实践中有效避坑。

进入正题之前，我们先从应用所需的算力视角来看，与传统的 IDC 管理应用相比，云到底带来的变化是啥？答案是算力的交付供给、分配及其管理方式发生了截然不同的变化。具体可以看下面这张图：

• 算力的生产：由资产采购的模式，变为在线租赁的模式；传统业务上线之前，通常由业务方发起资源采购需求，再由采购部门采购之后交由运维团队装机准备好相应的环境后，再交付给业务团队使用；这通常是一个很漫长的过程，严重影响业务创新的速度。云的出现悄然改变了这一形态，需要的算力资源，可以通过在线服务的方式轻松获得。算力的交付效率从之前的月级别一下降低到秒级。
  
• 算力的分配：由人为配给的模式，变为流量配给的模式；算力交付之后，就是将其分配给业务；传统的交付方式通常是整机的方式全部交付给业务方独享，长此以往，资源碎片会越来越大，资源利用率就会越来越低。但是云的形态下，业务使用的资源可以做到按照真实业务的流量和程序的服务能力，通过弹性的方式做到自动调节，也可利用业务对于算力需求时机的不同进行混部，从而有效提升资源使用率。
  
• 服务的运维：由专人管专项，变为面向角色的管控方式；如果说以上两点，通过自行搭建一套虚拟化系统外加一些系统调度与编排工具的方式也能做到的话，那么我们所认知的云与虚拟化一个本质的区别就是，在算力层所代表的 IaaS 上是否长出来了可充分发挥基础设施能力的 PaaS 服务。当应用程序所需要的基础设施（计算、网络、存储）以及周边依赖的平台服务（DB、中间件、大数据等）均以类似的服务化的方式提供交付与服务的时候，对应服务的运维也同时交给了云，云透露给我们的运维工作会更加简单，操作界面界面也会随之简化。我们不再需要专业的人去运维专门的事情，只需要面向同一角色人群，授予不同的角色，控制操作的影响范围即可。
  

如果一切都如我们理想中的样子：算力是无限的、资源永远是充足的。我们可能不需要花费如此长时间来探索。现实与理想总有错配，接下来，我们再来谈几点云与我们常规理解上的认知错配：

1. 物理资源受限：云厂商的算力总归需要依托在数据中心之上，在每一个城市，数据中心的建设总有土地规模的限制，对于常规的业务而言，在建设初期可以暂时忽略算力的规模，但随着业务越来越大，尤其是全民性的大规模算力需求产生时（如：所有零售业在双十一大促场景、AIGC 爆发时等），需要提前跟云厂商进行资源锁定，以防到点买不到资源的情况。为防止这种情况的出现，除了商务上的沟通之外，上规模的业务通常会采用多可用区、异地多活等多活架构，尽量减少物理环境对资源瓶颈的冲击。
   
2. 算力规格受限：另外一个会限制算力生产的原因是规格，同一种规格不可能无限制的存在，这里的原因是除了本身厂商会将原本有限的算力按照规格进行分配之外。还有一个原因就是厂商会自己会不停的更新换代，每年都会有新的规格和机型，同时也会将一些老的机型进行淘汰。正是由于上面这些原因的存在，在一个存在时长较长的业务集群中，总会出现不同规格的机型混合调度的情况；而不同规格的机型意味着不同的性能基线；不同的性能基线，就会影响同一个应用下不同节点之间计算能力的失衡。
   
3. 政策导向变化：另外一个会影响算力供给规模就是政策，随着科技自主国策的提出，国家开始要求部分行业在建设自己的信息系统时，需要严格采用我们自主可控的技术，这对于应用而言，基本上从底向上到提出来了明确的要求，对于算力而言，主要是体现在芯片和操作系统上。部分行业已经明确不能采用国外的芯片，所以很多的厂商均推出基于 Arm 架构的自研芯片。操作系统层面，随着 CentOS 的部分版本的停服，国内厂商（如龙蜥、麒麟、统信等）开始涌现。国内芯片的繁荣，带给了我们的用户更低的算力价格的同时。也在倒逼上层应用适配部署在不同芯片、不同的操作系统之上，带来了一定的交付、运维、甚至运行时的复杂性。

正是由于算力交付、供给、分配的变化，加上云上基础设施的多样化，才带来了我们今天云上应用管理的复杂度，同时由于成规模的微服务这种形态，有着算力需求规模之大，流量治理复杂等特性。从这一问题出发，我们将从四个角度来详细阐述 EDAS 在八年之中的摸索。这个四个角度分别是：多中心（可用区）、一云多芯的形态、弹性和平台工程。

视角一：多中心（代表性基础架构）

云上的机房通常会有地域（Region）和可用区（AZ）的概念，不同的 Region 一般分散在不同的城市，简单理解属于物理上相隔较远的机房，因为跨 Region 之间的带宽默认走的是骨干网，所以不同 Region 的机器之间默认内网是不通的。在同一个 Region 内部，会划分为多个可用区，简单理解为多个距离相近的机房，同一 Region 内的可用区之间默认是内网相通。可用区除了给客户提供服务的机房级别的容灾能力之外，还能帮助有线下线上进行资源打通的客户可选择就近的接入点，以此获得更低的延迟和服务保障。如下图所示：

那么我们进行应用管理的时候，该从哪些方面去重新思考整体的系统架构，以获得最佳的技术红利呢？

多可用区下的容灾能力建设

每个行业对于容灾的需求不一样，国家目前针对金融行业制定了专门的容灾标准，从技术形态上看主要分为：同城双活、异地容灾、两地三中心、异地多活（单元化）四种形态。公共云的多可用区的设计，可以以很低的成本来满足同城容灾的诉求，下图基本描述出来了多活能力建设过程中，几种不同形态的核心架构的异同，感兴趣的同学可供参考：

常规的技术架构形态

如果我们自己需要建设容灾能力的时，通常我们一般会采取一下的步骤实施：

1. 梳理出中间件（如 Zookeeper 等）各个组件的容灾模型：以 ZooKeeper 为例，为了满足挂掉一个机房也不影响服务的诉求，光有简单的对等部署是不行的，因为无法满足选举 Leader 票数过半的条件，我们推荐的架构方式如下图：
   

在上面的架构中，假设出现主可用区不可用的情况，我们可以马上将备机房的三个节点切成 Follower，主机房三节点切成 Observer ，以此完成选举操作。同样的，我们需要同时梳理其他所使用到的中间件，如 RocketMQ、MySQL、Nacos 等。

2. 从业务角度梳理出有状态和无状态的应用：其中无状态应用，意味着只需要有一个节点拉起在任意网络畅通的位置，即可对外提供服务，这种方式最为灵活。这也是为什么微服务体系下或者云上的应用中都推荐大家使用无状态应用的原因。而有状态比较容易忽略，比如：游戏场景下，线下玩家和服务器上的房间的关系，通过网络流量严格绑定；再比如 RocketMQ 的 Broker 的消息对于磁盘的依赖。这些情况都需要在灾备切换时根据业务形态做特殊处理。
   
3. 梳理流量接入和转发：流量接入通常以 DNS 为入口，DNS 解析后对接到一个公网 IP，这个 IP 一般是对外提供的一个负载均衡地址，在发生容灾切换时，有的时候需要对对应的 DNS 做一个全面的切换。但 DNS 通常在切换时有时延，有的客户端会存在 DNS 的缓存，导致切换不生效。安全起见，通常在 DNS 后面搭配一个可切换后端主机的负载均衡，能获得更好的效果。
   

云服务带来的变化

到了云上之后，由于 DNS、SLB、多可用区、中间件、DB 等等形态，均由云厂商提供，这些产品，默认都提供了跨可用区的同城双活容灾的能力，比如 SLB 可以默认跨多可用区，DB 也默认具备跨可用区的容灾。在这种形态之下，我们只需要考虑自身应用的容灾架构就行了。这就是云厂商所带来的技术红利之一，就是把尽可能多的技术问题，交由云厂商处理，而企业就可以把工程师的精力更多的聚焦在业务创新上。

多可用区下流量管理的变化

多可用区虽然带来了诸多好处，但是应用在这一形态下，也会带来诸多的复杂度。其中一个就是流量的调度和管理问题，原因是在单个可用区内部，默认是一个机房级别的局域网，机器之间的通信时延都会很短。但是一旦服务之间的访问跨出可用区，RT会增加几毫秒甚至更多，如下图所示：

上图中的右侧，展示的是一个微服务集群内的依赖情况，一个感性认知是理解服务之间的调用复杂度，随着服务数量与依赖关系指数级上升。但是是否能找到一些量化指标，却一直没有一个类似的公式进行佐证。比如：我们针对服务调用的 RT 和一些什么指标有关系？除了链路深度还有呢？

我们做了一次实验，假设A组 两台机器(A1, A2)之间 RT 是 T(ms)。一个请求链路是 A1 和 A2 之间来回访问10次（A1 -> A2 -> A1 -> A2 ....... ） 。然后再逐步加大数据包的大小，得出下图：

从上述结果可以看出来最终 RT 还受到数据包大小、系统配置与负载的影响。如果 A1 和 A2 横跨两个不同的可用区则影响更大。为减少流量横跨多可用区带来的影响，我们通常采取可用区内流量闭环的策略。在微服务场景实施时，我们可以在服务提供方进行服务注册时将可用区信息带入到注册中心中。同时在服务请求方发送调用请求时，在流量转发处再根据可用区信息做精准的路由。如下图所示：

多可用区下应用调度的变化

我们的业务最终会涌向多可用区的架构的其中一个原因，就是我们所需要的对应的规格，在一个可用区之内总会遇到紧缺的情况，比如在全民大促的场景（6.18 ，双11 等），很多公司都是提前很长一段时间和云厂商预定对应的资源。一旦某一类资源在一个可用区内出现资源紧缺的时候，就只能通过其他可用区的资源补充。

与使用普通的虚拟机相比，多可用区资源调度在容器的场景中会更加复杂；毕竟虚拟机场景，只要资源生产出来，可以手动分配给对应的应用，虽然效率上相比自动调度稍逊一筹，但这种方式至少是确定的，运维工程师可以充分决策干预。而容器中的调度，则需要依赖 Kubenetes 中 Scheduler 的能力。假设我们有一个 Kubernetes 集群，横跨两个可用区（如：cn-hangzhou-a, cn-hangzhou-b），一般情况，我们需要做以下的事情：

1. 将集群中的节点，分别打上 zone 标签：kubectl label nodes nodeName topology.kubernetes.io/zone=cn-hangzhou-a
2. 同时，kubernetes 引入 topologyKey 的概念，结合 Pod 调度时的 podAntiAffinity，从而达到跨可用区部署的能力 。
   

  affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: ${appLabel}
                      operator: In
                      values:
                        - ${labelValue}
                topologyKey: topology.kubernetes.io/zone

同样的逻辑，如果我们的应用，比较依赖可用区中的某一类型的资源，也可以在使用类似的方法做了同样的效果，比如：

• node.csi.alibabacloud.com/disktype.cloud_ssd: available：依赖具有阿里云 SSD 磁盘的机器
  
• node.kubernetes.io/instance-type: ecs.c6.2xlarge：依赖 c6.2xlarge 规格类型的机器。
  
• kubernetes.io/os: linux：依赖 Linux 操作系统
  
• kubernetes.io/arch: amd64：依赖 Amd64 芯片架构
  
• 等等
  

在阿里云的容器服务中，很多的属性（包括不限于以上的例子中的属性）都是在集群阶段默认会注入，无需额外手动操作运维。只需要在应用创建过程中指定相关的配置即可，省去诸多繁杂的人工操作。

EDAS中的实践

EDAS 的理念是始终以应用为中心去俯瞰底层资源的形态，无论业务是否出于容灾的目的进行架构设计，对于多可用区的流量管理和应用调度，我们都把能力植入到应用的管理中，其中：

• 对于流量管理：EDAS 会默认集成同可用区优先调度的能力，同时支持 Spring Cloud / Dubbo / HSF 这三种服务框架，在服务框架中需要额外扩展的能力（注册过程与路由过程），EDAS 会默认提供。且为了防止可用区资源不对等的情况，EDAS 中还支持设置所分布应用节点的规模阈值，以防止单边可用区节点被打挂的情况，如下图所示：
  

同时在可观测方面，结合 Arms 调用链默认植入跨可用区调用的提示标签，简化由于跨可用区调用而出现调用超时的排查耗时，如下图所示：

• 对于应用调度：将 Kubernetes 调度过程中的调度能力场景化呈现，除了支持自定义的方式之外，我们还抽象出 可用区调度 与 节点调度 两类场景。其中多可用区调度，可尽量满足容灾需求；而跨节点调度，可尽量将应用的不同实例打散到不同的节点，尽量保证 Kubernetes 节点之间的负载均衡。
  

视角二：一云多芯（代表性基础技术）

指令集与芯片

“集成电路上可以容纳的晶体管数目在大约每经过18个月到24个月便会增加一倍。换言之，处理器的性能大约每两年翻一倍，同时价格下降为之前的一半。”这是英特尔联合创始人戈登摩尔总结出来的计算机发展的其中一条规律，也就是大名鼎鼎的摩尔定律。

而计算机行业另一个定律安迪比尔定律又说：“计算机软件的复杂度每18个月会翻一番”。这里的安迪是指 Intel 的联合创始人安迪-杰罗夫，而比尔指的是比尔盖茨。与摩尔定律结合之后，这一定律也被戏称："Andy gives, Bill takes away"。也就是说，硬件不断优化所带来的性能改进，马上会被上层的软件不断演讲的复杂度所吞噬。

软件经过编译之后，翻译成可以控制硬件的机器指令。指令架构不同，翻译后的机器指令也不一样，当前主流指令集架构主要有：X86、Arm和 RISC-V。而处理器芯片作为承载算力的大脑和灵魂，被誉为人类最为先进的制造工艺。他们在信息世界的发展历程中，不同芯片厂商扮演的角色不同、赶上的机遇也不同。

X86与英特尔

X86指令集是 PC 时代的王者，由英特尔公司于1978年推出的，它是一种复杂指令集计算机（CISC）指令集，逐渐成为了PC机的标准指令集。随着计算机技术的发展，它不断演变和改进，推出了Pentium、Core和Xeon等高性能处理器，同时还推出了MMX、SSE、AVX等多媒体扩展指令集。X86指令集广泛应用于个人电脑、服务器、工作站、游戏机等领域，是当前计算机领域中最为流行和广泛应用的指令集之一。

而英特尔这家商业公司，在半导体领域一直是那颗最为瞩目的明星，他很好的抓住了 PC 市场，推出与 Window 联盟的 “WINTEL” 战略，在存储器芯片落败的局面下，确定了以 CPU 为核心的产品路线，商业上确立了行业第一的位置。同时在技术发展的路线上，首先意识到了指令集向后兼容性，逐步把 X86 指令集做成了 IT 业的实施标准，才奠定了今天的江湖地位。

Arm指令集与Arm公司

Arm指令集是由英国公司ARM Holdings于1985年推出的，它是一种精简指令集计算机（RISC）指令集，主要应用于嵌入式系统、智能手机、平板电脑、智能电视等领域。Arm指令集的发展和其迭代的目标，一直围绕优化代码大小和提高处理器效率而进行。它的主要特点是低功耗、低成本、高效率，因此他特别适合嵌入式系统和移动设备领域。

除此之外，作为一家商业公司，与英特尔坚守 X86 指令集封闭的模式不同。Arm 在指令集的商业模式上首创了 IP 授权这种种灵活的方式，奠定了他成功的基础。移动时代厂商众多，定制需求剧增。基于灵活的授权模式，厂商可以基于他的精简指令集进行高度定制。低功耗配合高度定制，迎合了移动时代的发展特征。2020年，全球90%以上的智能手机芯片都是基于Arm架构设计的。可以说 Arm 是移动时代处理器领域的真正霸主。

RISC-V联盟

RISC-V指令集是由加州大学伯克利分校于2010年推出的，也是精简指令集（RISC）的其中一种，它采用开源协议，旨在推动指令集的开放标准化。RISC-V 的出现与开源，给了 IT 从业者一个深度参与感受一个计算机指令集从无到有到全方位生态发展的整个过程的机会。这一开源开放、标准化的特性，吸引了越来越多的国内厂商与生态的加入，使我们国产芯片自给自足、自立自强的进度进一步加快；有数据预测：“到 2025 年，RISC-V 的处理器将达到 800亿颗，有望成为第三大指令架构生态，其中一半将来自于中国”。

云的新角色

摩尔定律，不仅是 IT 行业中的一个发展规律，更像是这个产业中的一个指导思想，也是衡量一家公司竞争力水平的一个衡量标准。有一句话曾说：“真正认真对待软件的人应该自己制造硬件”，这里最为典型的代表就是苹果，无论是在最新的Mac 上搭载的 M 系列处理器，还是 iPhone 中推出的 A 系列处理器。依然在摩尔定律的指导思想下，不断推动硬件性能不断向前演讲。

时至今日，算力不断的从终端往云端转移，云厂商在今天所扮演的角色已经不是简单的硬件的转售。随着大数据、AI 等数据密集型与计算密集型任务需求同时迸发出来的时候，与传统的 CPU 架构相比，算力已经不再是衡量芯片的唯一指标，需要同时兼顾算力与数据传输速度。即如何将计算、存储、网络的处理能力同时提升，已经成为了云时代对于芯片架构最主要的挑战。以英伟达的 SuperPOD 超算集群为例，一个集群可包含 32台服务器折合256个H100 GPU，AI 算力高达 1 EFlops (参考：2022年中国算力总规模为 183 EFlops)；同时每套集群配 18 台 NVLink 架构的交换机，系统双向带宽达 57.6TB/s。除了传统芯片厂商，主流云厂商纷纷下场探索基于云时代的处理器，到目前为止，阿里云已经推出基于 RISC-V 架构的玄铁系列、基于 ARM 架构的含光、倚天系列。协同飞天操作系统，全力打造出符合云时代特征的 CIPU (Cloud Infrastructure Process Unit) 。

云上应用管理新的挑战

随着国家科技自主政策的进一步推进，以及云厂商“一云多芯”形态的涌现，应用架构需要开始考虑能同时运行在不同的芯片、不同的操作系统、甚至其上的依赖软件架构都不太可能一样，软件的运行时环境也会带来多样性；这样给云上的应用管理带来了更多的挑战，其中包括：

• 在软件开发的过程中，需要花费更多的精力去考虑并适配不同的技术栈。
  
• 在软件交付的过程中，需要尝试更多的努力在不同技术栈上将性能优化至尽可能一致的水平。
  
• 在软件运维的过程中，需要更多的精力与更好的工具维护不同技术栈上的基础设施依赖。
  
• .....
  

EDAS 中的实践

目前针对 x86 架构与 Arm 架构的同时运行和管理，在阿里云上已经有成熟的解决方案，阿里云容器服务提供了容器镜像的双架构解决方案，利用构建镜像时一次构建多份产出的能力，在运行的过程中，可自动根据 Node 节点上的芯片架构去拉取不同的镜像，从而做到软件构建交付后，在运行时与芯片解耦。而 EDAS 基于容器服务的这一特性，在上面封装了基于二进制到镜像构建流程，即只需要提供应用程序包，即可默认运行在 Arm/X86 的混部容器集群上，从而达到代码编写一次，多架构运行的效果。

视角三：弹性（释放技术红利的最短路径）

弹性用云模型

如果说上面两个（多中心与一云多芯）是云的基础能力的体现，而释放这些基础技术红利最快的技术手段就是弹性，极致的弹性可以由资源交付效率从传统的月级别缩减至秒级别，甚至毫秒级别（Function 场景）。在落地过程中，我们的绝大多数的客户的业务是从之前老的运行环境中搬迁上云，或是存量的云上业务逐渐由于很多的原因（如成本）开始使用弹性的方案。在这里，我们总结了一个弹性资源的一个基础模型：基础资源 + 弹性资源，即：

• 基础资源：用以保证常规低峰业务流量的资源保障。
• 弹性资源：用来应对突发流量的情况。
  

基于这一模型，我们总结了三种实践，接下来我们一一进行阐述。

场景一：线下资源 与 线上资源

在这个场景中，一部分资源在自己 IDC 里面，而有另外一部分资源，则在云上开对应资源，线上资源和线下资源共同服务同一业务。在阿里云上，可以使用云企业网（CEN）产品，实现同地域的云上云下网络互通，下图中的示例是通过物理专线网的方式打通线下 IDC 与阿里云 VPC 的示意图。

通常来说，这种架构通常能带来以下优势：

1. 容灾：主要从网络容灾和数据容灾两个方面去看。首先在网络容灾上，线下 IDC 的接入后可当成一个可用区，配合云上的可用区实现同城双活的效果。其次是在数据容灾上，我们还可以将线下的数据，利用线上的存储容量往进行备份，而且备份的副本数量还可以随着接入的云中心的区域进行异地多点备份。
   
2. 安全：云厂商提供的能力丰富，而且网络接入方式众多，在网络、安全、审计等各个方面都有对应的服务。而如果采用自建 IDC 的话，这些能力都需要自己的研发团队从 0 - 1 进行建设。一些面向互联网的业务，通常在安全(如：防侵入、安全审计等)和网络(如：CDN、DNS等)上有着较高的诉求。这样就诞生出来了一类很典型的架构：利用云上资源和服务作为流量接入能力和安全防护的能力，做完流量清洗并进行操作鉴权之后再转入到 IDC 内的生产区进行服务。
   
3. 监管：国家对于特定的行业（如金融行业）对于数据安全的要求很高，中国人民银行 2020 年发布的《云计算技术金融应用规范安全技术要求》中明确指出，云计算平台部署的物理数据中心及附属设施，应保证用于服务金融业的云计算数据中心运行环境与其他行业物理隔离。这样很多的数据敏感型的金融业务，都只能部署在符合规定的自己的 IDC 机房内。但是有一些数据敏感程度不高的其他业务，则可以放在云厂商提供的资源池内。当有需要进行业务交互时，再通过线上线下接入的方式完成数据交换。
   
4. 成本：虽然云上提供了低成本、按需弹性使用的方式，可以将 IT 资源使用成本大幅度降低。但是很多的公司原本就在自己的 IDC 机房中存在很多的资源，这一部分资源不可能完全抛弃。同时存量的资源上的业务，如果一蹴而就改造成适应云产品的架构模式，也会带来一定的改造成本。在新老架构进行切换时，在流量治理、数据同步等方面也都会带来技术挑战。将线上和线下的资源拉通之后，原有资源和云上资源可以当成在一个局域网内来对待，为整体应用架构平滑迁移带来了可能。
   

场景二：包年包月 与 按量付费

越来越多的企业在使用云资源时，企业需要根据自己的需求选择哪种付费方式更为合适，目前主流云厂商主要提供有包年包月和按量付费两种付费方式。这个两种模式各有千秋，我们简单总结如下：

• 预算控制：采用包年包月的方式，客户可以提前预算成本，避免突发事件造成的支出增加。而使用按需计费的方式，在财务的角度成本不确定，使用量也难以预测。因此需要不断地监控和评估资源使用情况，以避免资源费用过高。
  
• 资源供给稳定性：包年包月的方式企业可以根据自己的需求和预算，在某些时期内提前锁定预留资源，以避免资源不足的情况，确保资源的稳定性和可用性；而按需购买的方式则不能百分之百确定在需要时能准确提供所需要的算力，存在一定的不稳定性。
  
• 成本：相对于按量付费，单价上包年包月的价格更为便宜。但按量付费可以根据具体的使用量进行计费，避免因为不必要的资源而付出额外费用；企业只需要支付实际使用的资源费用，就可以避免因为资源闲置而产生的额外支出。
  

总结完两种计费模式，到底采用那种还需要根据自身业务场景出发，据我们观察，绝大多数的业务都具备以下两个特点：

1. 业务增长很大程度上是不可预知的；业务的不可预知意味着预算就不可预知，成本控制就不可预知。
   
2. 业务会有明显的流量特征（比如：办公类型的内网应用，上班时间流量高峰，其余时间流量低谷；社交类型的应用晚间至凌晨流量高峰等等），业务流量的高峰和低谷的差值，意味着资源可供整理的理论空间，而整理资源碎片空间的方式就是弹性。
   

正式因为在预算、资源供给以及成本上存在很大程度上的区别（更确切的说是优势互补）。为满足业务发展的需求，这里也就带来了一种典型的弹性的场景，即 包年包月 + 按量付费 的场景，其中：

• 以包年包月为基础资源，锁定资源供给，满足常规业务低峰期的算力供应。
  
• 以按量付费的模式，以应对业务高峰流量对于算力的需求。
  

据我们的观察，阿里云上如果按量付费的资源一天之中的使用小于 16 小时（随着厂商策略调整，可能会变化）的话，按量付费的整体成本会比包年包月的成本更低。

场景三：Container 与 Serverless Container

随着云计算的深入普及，以容器技术为基础的云原生的理念也是越来越深入人心。在云原生场景下，弹性能力变得更加通用，实施成本也更多。这一技术的普及也能进一步减少资源碎片，提升资源的利用率。现在主流的云厂商都提供了两种类型的容器形态，以阿里云容器服务为例：

• 第一种是基于云主机的有着正常 Worker 节点的容器，这种形态下，我们可以提前准备好云主机作为 Kubernetes 的节点，然后容器服务会在节点上准备好 Kubernetes 的集群。
  
• 第二种是无需准备云主机的 Serverless 集群，这种形态下，用户感知不到 Worker 节点的存在，但是具备完整的 Kubernetes 的运维体验，当需要创建资源的时候，容器服务会负责临时生产 Serverless Container。
  
• 第三种是上面两种形态的结合，即在一个正常的 Kubernetes 集群中，配合 Serverless Container 的方式使用。
  

据我们观察，Serverless Container 在以下的场景中，能发挥出很大的优势：

1. 临时性短周期业务：对于需要短暂处理的任务，如图像处理、数据转换、临时开发环境等，Serverless Container 可以在任务完成后自动释放资源，避免长时间占用云资源。
   
2. 无状态服务的突发负载：API 网关、消息队列、事件处理器等，这些服务可以快速响应请求，遇到突发流量时，自动扩展容器的数量，同时在负载过低时自动释放资源。
   
3. 大规格应用的无损发布：在 Kubernetes 的应用滚动发布的过程中，一般都是需要先起一个新的实例，等到实例 Ready 后在滚动个升级下一个实例，这就意味着所在实例预留的资源至少要多出来一份才能做到常规更新。这样在机器上需要冗余的资源碎片会随着容器的规格而成比例放大，Serverless Container 很完美的解决了这个问题。
   

代入到我们的弹性模型中，基础资源可以使用正常的 Worker 节点搭配 Serverless Container，则结合两种形态的优点提供服务。在阿里云的容器服务中，可以使用 ElasticWorkload的资源形态将这两种资源的使用方式，用一份文件来进行描述，可以大大简化运维成本，如下图：

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
metadata:
 name: elasticworkload-sample
spec:
 sourceTarget:
  name: nginx-deployment-basic
  kind: Deployment
  apiVersion: apps/v1
  min: 2
  max: 4 # 副本数超过 4 个时，使用 elasticUnit 中的资源进行调度
 replicas: 6
 elasticUnit:
 - name: virtual-kubelet
  labels:
   alibabacloud.com/eci: "true"
  # min: 0 每个单元也可以指定自己的上下限。
  # max: 10

EDAS中的实践

在 EDAS 中针对上述三个场景的产品能力支持上，简单概括如下：

• 在 线上资源 + 线下资源 的场景，EDAS 除了默认支持云上的 ECS 节点作为应用的托管节点之外，也支持非阿里云集群（如 IDC 机房）的接入。在线下 IDC 进行网络接入后，在对应节点上安装 EDAS 的 Agent，就能托管线下的节点作为应用节点，在该集群中通过 EDAS 发布的应用，就能当成云上的应用一样统一管控：
  

• 在包年包月 + 按量付费的场景下，EDAS 中的弹性伸缩能力可以在对应指标触发之后，临时以按量付费的模式去“代购”指定形态的资源，同时在流量高峰过去后，可以自动将临时购买的机器资源释放回去。
  

• 在 Container + Serverless Container 的场景，EDAS 支持基于阿里云容器服务的ElasticWorkload工作负载，将应用的一部份实例运行在ECS节点上，超量部份运行在 Serverless Container 中。得益于Serverless Container的秒级弹性能力，在集群资源紧张的情况下，可将应用分钟级扩容缩短至秒级别。在缩容场景下，优先缩容Serverless Container实例，避免随机缩容的场景下，释放ECS节点上的实例，从而造成算力资源的空闲浪费。
  

视角四：平台工程（降低复杂度的理念）

平台工程诞生

平台工程这一技术领域，至今已经连续两年 (2023年与2024年) 被 Gartner 评为最需关注的十大科技趋势之一。尤其在去年(2022 年) 7 月份一条 Twitter ("DevOps is dead, long live Platform Engineering") 引爆了 IT 圈对于平台工程进一步的关注，讨论的焦点主要是两个：

第一，为什么他说 DevOps 已亡 ？先看 DevOps 的定义："DevOps 是一种文化和方法论，旨在通过协同工作、自动化和持续集成/交付来提高软件开发和运维的效率和质量。DevOps 的核心理念是打破开发和运维之间的壁垒，建立一个协作、互信、自动化的工作环境，以实现快速、高效、可靠的软件交付。DevOps 的主要特点包括：自动化、持续集成/交付、敏捷开发、协作和互信、可测量和可追溯" 。这些理念固然很好，只是大部分的公司，问题出在执行层面。我们观察的原因在于：

1. 所涉及技术领域太宽，除了大型企业，不是所有公司都有足够的人才宽度去承担起符合标准的产品研发团队。
   
2. 云原生崛起，工程师除了需要掌握常规的流水线工具之外，又突然带来的十多种额外的基础工具的学习和使用，如：Helm/Terrafrom 等。
   
3. 领域商业化严重，有过度营销包装，实际落地项目中，容易出现与理想的偏差。
   

第二，平台工程到底是什么？这里确实没有一个标准的答案和定义，我们搜寻了在这个领域中的很多答案，翻译之后如下：

• “平台工程是一种新兴的技术方法，可以加快应用程序的交付及其产生业务价值的速度” -- Gartner
  
• "平台工程是一门新兴学科，专注于通过降低现代软件交付的复杂性和不确定性来提高开发人员的生产力。” -- CircleCI
  
• “平台工程是设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。” -- platformengineering.org
  
• “平台工程是设计和构建自助服务功能的学科，以最大限度地减少开发人员的认知负荷，并实现快速的软件交付。” -- Puppet
  

从上述几个答案可以看出，这一概念至少目前没有一个统一的标准，但是可以从其中提取几个关键字，以便肃清我们对这个概念的认知：新、开发人员、工具链、自服务。

如何建设一个平台工程平台？

虽然“平台工程”这一概念刚刚诞生，但是所这份工作其实在很多公司中早早的就在做，在今年早期 Puppet 针对全球范围的 DevOps 领域的调查显示，绝大多数(超 70%)公司，已经在内部成立了平台工程相关的 IDP(Internal Development Platform) 团队，而且接近一大半的公司成立时间超过一年，即远早于这一概念提出的时间。

在现有的公司中对于这个团队进行深入跟踪分析后不难发现，平台工程的建设其实有规律可循，我们从定组织、定目标、定范围、定能力四个维度做了一些基础的总结如下图，希望可以带去一些帮助。

EDAS中的实践

EDAS 作为一个云上的微服务应用管理平台，或多或少的会引入新的概念，每增加一个新概念对于用户的使用成本就会上升，所以 EDAS 协助客户践行平台工程的理念就是：“不新造没必要的工具，将能力插件化的方式递送到工程师最熟悉的工具链中”。从 2019 年的 EDAS 2.0 开始，我们在工具链中持续迭代演进，到如今基本涵盖了应用的开发、构建、交付、测试、运维各个阶段，在标准工具中提供官方插件支持能力，如下：

• 应用开发中，全面兼容标准开源的 Spring Cloud/Dubbo 框架，同时在标准的 IDE 开发工具中（Eclipse/IDEA），推出官方插件 CloudToolkit，开发人员能在插件中完成应用创建、部署、端云互联、API 测试、配置管理、微服务治理、应用运行时日志，Shell 操作审计等能力。
• 应用构建与交付的过程中，提供官方 Jenkins / Gradle / Maven / Terraform / HelmChart 插件。
• 应用测试过程中，不仅提供 Web 版本的快速访问测试，也支持 JMeter / Postman / Apifox / IDE(CloudToolkit) 的官方标准插件。
• 应用运行时，EDAS 一直主打无侵入的方式提供微服务治理与 APM 应用监控的能力，同时针对常规应用管控场景，我们也支持完整的基于 kubectl 的黑屏完整能力，给用户提供白屏/黑屏/CD 工具三端完整的能力。
  

尾声

十年前开启的数字化转型的浪潮，拉开了以分布式互联网应用架构为主导、对企业数字化系统的迭代升级序幕。随着越来越多的开源框架的涌现，以及以 Kubernetes 技术为代表的云原生技术对基础设施技术架构的进一步重塑。云技术、云原生应用架构，已经在各个行业的基础设施中变得深入人心。以多中心（可用区）、一云多芯为代表的云基础设施，不仅仅是业务持续迭代演进的自信，更是符合政策监管要求的底气；弹性技术是释放技术红利最快的方式；而在这一过程中衍生出来的技术和概念的复杂度，希望借助平台工程的理念，在企业内部将其抹平。

EDAS 作为一个微服务应用管理平台，诞生之初是将阿里集团内部微服务应用管理实践经验以产品化的方式进行输出，迭代至今历经 4 个大版本，每一个大版本都在客户需求与技术趋势之间充分吸纳、平衡；将微服务应用管理的实践经验进一步优化，再产品化回馈给我们的客户。时至今日，我们将所有微服务应用管理相关的能力，均沉淀到一个 K8S 的 CRD （CloudApp）中，感兴趣的朋友欢迎留言或加入钉群：21958624 与我们进行深入沟通。

作者 | 孤弋、之卫

来源 | 阿里云开发者公众号