阿里云李钟：弹性计算控制系统团队的提效之路

2023-05-12
浙江
本文字数：4815 字
阅读完需：约 16 分钟

2023 年 3 月 25 日，“城市领航之夜第一期”活动在上海举行，阿里云弹性计算控制系统技术架构负责人李钟出席了本次活动并带来了《弹性计算控制系统团队提效之路》的主题演讲，为大家详细分享了阿里云弹性计算控制系统团队所面临的挑战、如何通过技术架构提效，以及工程师文化建设等一系列内容。本文根据其演讲内容整理而成。

我从 2011 年开始就入职了阿里巴巴，主要负责 IM 服务端的工作，15 年加入了阿里云，在此期间一直负责业务的开发，2019 年担任了控制系统技术架构负责人，主要完成了阿里云弹性计算单元化架构的升级。今天的分享，我将从问题、技术架构、规范流程和工程师文化四个维度，通过弹性计算的角度以及技术和架构的角度，来分享弹性计算控制系统团队的提效之路。

从问题出发，看当前的挑战

阿里云弹性计算管控系统是一个大型的分布式系统，支持高并发和高可用，除此之外，也有自己独特的复杂度。

规模大：管理全球 50 多个环境，支持 28 个公共云地域，兼容专有云技术和业务，并且已扩展到新的本地云、专属云等分布式云场景，规模非常庞大。以管理全球 50 个以上的环境为例，应用在做配置发布时需要在全球范围内变更 50 余次，这对系统的开发、运维和管理都带来巨大的挑战。
业务复杂：弹性计算的产品类型不断向前发展，我们需要对每种类型都提供支持。且因为云计算底层是物理资源，业务需要对物理资源的限制进行描述和管理，因此业务逻辑也非常复杂。

对于阿里云而言，所有云产品都基于 ECS 构建，因此稳定性非常重要。但是系统本身还需要进行架构的升级和演进。我们要在技术演进、稳定性以及效能三者之间做到平衡。保持业务和技术的快速演进和升级，同时又要保障不出现稳定性的问题。

最后从团队的规模来看，弹性计算控制系统团队规模持续扩大，近年内已经增长近 6 倍。我们面临的挑战愈发严峻。

技术架构优先，构建效能基座

我们主张优先考虑技术架构的升级和优化来构建效能的基座。总结来说，有下面图中所示的 4 个方面。

首先，通过短期的方案快速解决问题。主要是三个手段，通过并发的方式投入提高速度，这也意味着会使用更多的资源；通过自动化和工具化的方式降低人力；通过引入标准化的流程来保证正确性。

短期的解决方案能够达到立竿见影的效果，为团队建立信心，让成员知道问题正在被关注和解决，促使每个人都去思考如何解决自己面临的问题，并为长期发展赢得时间。

短期方案临时解决问题之后，就要持续规划架构技术的升级，解决核心问题。这里主要包括三个方面，一是要思考问题的根本原因，从而有效的解决问题，而不是躲避问题。规划架构和技术的持续升级来根据实际情况构建高效的系统。二是坚持使用工具化、可集成、平台化的方式解决问题。保障技术升级的可持续性。最后要持续升级基础服务，中间件和基础组件，在代码不断演进的过程中，享受组件升级带来的性能和效能红利。

第三点，需要优化研发流程，使其灵活有效，避免缺少流程导致出现问题。也要避免流程过多导致系统臃肿的问题，探索新的思路，使用先进的思路和工具提效。

最后，需要不断沉淀和积累，一方面是知识体系的沉淀，同时也要注重构建可复用的系统框架和组件。下面我们重点来看上面提到的第一点，如何通过系统架构升级来构建效能的基座。

弹性计算管控系统负责处理的业务可以分为两个部分，一方面是要管理底层的物理资源，负责对资源的状态进行管控。另外一方面响应用户 OpenAPI 调用，来完成用户的业务请求处理。

在弹性计算控制系统之前的实现中，这两个部分是相互耦合的。既需要进行资源状态的管理，也需要实现复杂的用户业务。资源状态管理的业务逻辑变化较小，并发度高，对稳定性较为敏感。而用户业务则变化快，实现较为复杂。

因此，我们将状态管理和业务逻辑做了分层。底层是状态管理的集群，集群逻辑简单但体量较大，比较稳定，不需要有太多的发布。而业务逻辑部分被放到上层，由 RPC 调用连接的微服务集群，整个集群类似于 ServiceMesh，服务之间的依赖非常复杂，变化也非常快，且无状态。这使得逻辑上异构的两个部分可以分隔开，解决了稳定性和高并发的问题，同时也满足业务逻辑的高效迭代。

业务逻辑层采用模块化和服务化架构，使得各个系统之间的职责较清晰，各个服务的角色可以定义。各个系统使用标准的公共 API 进行交互，使得系统耦合度降低，服务之间可以独立快速演进迭代。

另外，我们引入了事件驱动架构，通过事件模型将系统里面核心链路和非关键模块解耦，解决非关键模块对核心链路的稳定性影响问题。另外也使得系统的核心链路可以保持清晰有效，提升了系统的稳定性和性能。也使得系统的开发和迭代更加高效。

上面我们通过架构的演进和优化，解决系统快速的演进和迭代的问题，下面来看一下团队是如何通过积累和建设公共的框架和组件，使得业务开发可以事半功倍。

2015 年 6 月，弹性计算控制系统团队创建了 ecs-common-framework，在业务开发的过程中，将一些通用的组件积累到这个公共库中，其中包含了缓存，幂等，限流，工作流等等功能。到 2021 年，ecs-common-framework 中已经完成了近 230 多个版本的发布，为业务的开发提供了有效支持。到 2021 年，我们对其进行了模块化方式重构，并命名为 yaochi-peento-framework，目前已有多个云产品接入使用。

yaochi-peento-framework 框架由四个部分组成：

基础框架：包含了分布式后端服务开发的公共组件，包括缓存，配置，幂等，序列化等。
业务模块：包含了 OnECS 的公共业务组件，提供 OnECS 通用支持，包括 Quota，ActionTrail，Tag 等。
SpringBoot Stater：整个框架会基于 springboot 进行输出，是的业务方可以非常方便集成和管理。
生命周期管理：提供业务域的生命周期管理，包括应用的初始化，运维等能力。

有了上述的 yaochi-peento-framework，使得业务方开发新的云产品变得非常方便。正是因为在 2015 年创建了 ecs-common-framework，写下第一行代码，才能在 21 年进行重构和升级。yaochi-peento-framework 使得开发云产品控制系统的效率提升，并且成本大大降低。目前该模块不仅仅是在弹性计算内部使用，也被推广到弹性计算之外的其他云产品团队。

下面我们来介绍一下在 yaochi-peento-framework 里面，我们是如何设计和实现一个公共的组件。

公共组件方面，标准化和高可用是首要的两个的原则。组件的建设需要提供标准的 API，同时具有完备的文档描述和严谨的 Changelog 跟踪。在高并发方面，一方面只得是组件需要能支持高并发的调用，另外也需要对高并发的业务有特殊的实现，组件应该是高并发分布式系统的最佳实践总结。

另外，可插拔和可扩展也是系统非常关键的原则，弹性计算的部署架构非常复杂，要支持多种不同的部署形态，包括公共云，专有云，分布式云等。在不同环境部署时，依赖往往不一致，因此作为基础组件，需要提供可适配的能力。

yaochi-peento-framework 中的所有的组件都提供通用的 interface，并且做到可以支持多种实现。比如上面图中左边的部分所示，yaochi-pento-cache 模块提供了统一的缓存的 interface，但在同一套 interface 下支持多种缓存的实现，可以做到在不同的部署形态依赖不同的缓存实现，但因为这些缓存系统都实现了同一套 interface 来工作，因此对业务逻辑部分无感，这使得系统往前演进支持更多部署形态的时候会非常便捷。

可观测和可运维的能力也至关重要。所有组件都会有统一的可观察能力输出,全部通过 SLS（阿里云内部的日志系统），最后汇总到 Grafana 上，业务系统接入后即可马上获取到所有的观测数据。同时组件也会默认提供 opsapi 来支持运维能力。

yaochi-peento-framework 累积了系统开发中的最佳实践的组件，对该框架的复用使得新的业务和服务开发可以直接使用现有组件的能力，大大提升了应用开发的效能。

除了分布式系统碰到的问题之外，在弹性计算控制系统的场景里，还会有多地域管理的复杂度问题，这是因为地域管控的环境非常多（目前已经有 50 多个环境），中间件提供的控制台的能力已经无法满足我们的管理需求。使用 API，工具化和自动化的方式是唯一的选择，这里我们引入了近几年较为流行的平台工程（Platform Engineering）的概念。我们希望中间件提供 API，而不是控制台给我们，将所有 API 汇集，通过单元化的运维服务输出，然后由全局的运维服务平台整体集成。这样，运维多个地域时，不再需要切换控制台逐个操作，而只需要通过总的运品台进行管理运维即可。

运维 API 的集成能力还使得采用自动化，流程化的平台方案成为可能。

最后，在技术方案，我们想讨论一下中间件和基础技术组件的升级。弹性计算控制系统内部设计了一个框架和组件的升级流程。组件的引入策略，引入之后有流程进行跟踪，评判组件状态，每个组件都会有相应 owner，负责了解组件的情况，比如是否有大的 bugfix，或大的能力更新等，并按照实际需要进行主动升级。我们并不一定会对每一次更新都进行升级，但能够做到对每一版本都了如指掌。

一方面这样做是的我们可以及时了解组件或者框架在功能，安全性和性能方面的升级，能及时评估并安排升级，获得相应的红利。另外一方面，当出现相关的安全性漏洞风险，需要进行升级时，也会对相关的影响面较为了解，升级影响评估充分，风险降低。

一句话来说，有准备的升级，相比较临时评估升级，效率要更高。

规范流程制定，建立效能脉络

了解完技术方面的内容，我们来看一下流程。在弹性计算控制系统团队，我们的流程分为规划设计、编码测试、发布以及运维等几个阶段。

在每一个阶段，实际上我们都会有较为严格的流程，在这里，我想分享的是几个我认为较为有效的流程或者工具。

第一个是 RFC 机制，RFC 的全文是“Request For Comments”，意思是让大家来评审。规划设计阶段，RFC 是一种重要方式。我们鼓励同学记录下所有灵光一现的想法，并在日常对其进行不断补充扩大，直至它能够成为一个完整的方案，才会最终被呈上供团队进行讨论和决策，提高讨论效率，避免浪费时间。

另外在技术文档方案，但对于开发人员而言，写文档是一件极具挑战的事。因为系统在不停的变化，今天写下的文档，可能在很短的时间之后就失效了。因此，在弹性计算控制系统团队内部，我们采用的方式是让开发人员在开发的每一步都将评审和方案做到足够详尽完善，最后我们输出的是当前方案的详细技术文档，这样等于我们记录了对系统每一次变更的详细方案，新的同学并不是通过学习一个大而全的文档，而是学习系统每一次更新的方案，来了解系统的全貌。