2023年3月25日，“城市领航之夜第一期”活动在上海举行，阿里云弹性计算控制系统技术架构负责人李钟出席了本次活动并带来了《弹性计算控制系统团队提效之路》的主题演讲，为大家详细分享了阿里云弹性计算控制系统团队所面临的挑战、如何通过技术架构提效，以及工程师文化建设等一系列内容。
本文根据他的演讲内容整理而成：
阿里云弹性计算控制系统技术架构负责人 李钟
我从2011年开始就入职了阿里巴巴，前阶段主要负责IM服务端的工作，在2015年加入阿里云，期间一直负责业务开发，直到2019年担任弹性计算控制系统的技术架构负责人，主要完成了阿里云弹性计算单元化架构的升级。今天的分享，我将从问题、技术架构、规范流程和工程师文化四个维度，通过弹性计算的经验，以技术和架构的角度来分享弹性计算控制系统团队的提效之路，首先来看一下第一部分，问题和挑战：
一、从问题出发，看当前的挑战
阿里云弹性计算管控系统是一个大型的分布式系统，支持高并发和高可用，除此之外，也有自己独特的复杂度。
图1：问题和挑战 - 规模复杂度和业务复杂度
规模复杂度：管理全球50多个环境，支持28个公共云地域，兼容专有云技术和业务，并且已扩展到新的本地云、专属云等分布式云场景，规模非常庞大。应用在做配置发布时需要在全球范围内变更50余次，这对系统的开发，运维和管理都带来巨大的挑战。
业务复杂度：弹性计算的产品类型不断向前发展，我们需要对每种类型都提供支持。且因为云计算的底层是物理资源，业务需要对物理资源的限制进行描述和管理，业务逻辑也因此变得非常复杂。
图2：问题和挑战 - 技术演进&稳定性和团队规模
技术演进&稳定性：对于阿里云而言，几乎所有云产品都基于ECS构建，因此ECS作为IaaS基座的稳定性非常重要。但是系统本身还需要不断进行架构的升级和演进。我们需要在技术演进、稳定性以及效能三者之间做到平衡。保持业务和技术的快速演进和升级，但是又要保障不出现稳定性的问题。
团队规模：最后从团队的规模来看，弹性计算控制系统团队规模持续扩大，近年内已经增长近6倍。我们面临的效能方面的挑战愈发严峻。
二、技术架构优先，构建效能基座
我们主张优先考虑技术架构的升级和优化来构建效能的基座。总结来说，有下面图中所示的4个方面。
图3：技术架构优先，构建效能基座
首先，我们先来看一下上面图中右上角的部分，通过短期的方案快速解决问题。这其中主要是包括三个手段，首先通过并发的方式来提高速度，并发的方式是提高效率常用的手段，但这也意味着在同一时间会使用更多的资源；其次通过自动化和工具化的方式降低人力；第三就是通过引入标准化的流程来保证正确性。
短期的解决方案能够达到立竿见影的效果，为团队建立信心，让成员知道问题正在被关注和解决，促使每个人都去思考如何解决自己面临的问题，并为长期发展赢得时间。
短期方案临时解决问题之后，就要持续规划架构技术的升级，解决核心问题。这里主要包括几个方面，一，要思考问题的根本原因，从而有效的解决问题，而不是躲避问题。规划架构和技术的持续升级来根据实际情况构建高效的系统。二，坚持使用工具化、可集成、平台化的方式解决问题。保障技术升级的可持续性。最后要持续升级基础服务，中间件和基础组件，在代码不断演进的过程中，享受组件升级带来的性能和效能红利。三，需要优化研发流程，使其灵活有效，避免缺少流程导致出现问题。也要避免流程过多导致系统臃肿的问题，探索新的思路，使用先进的思路和工具提效。最后，需要不断沉淀和积累，一方面是知识体系的沉淀，同时也要注重构建可复用的系统框架和组件。
下面我们重点来看一下上面提到的第一点，如何通过系统架构升级来构建效能的基座。
图4：技术架构升级示意图
弹性计算管控系统负责处理的业务可以分为两个部分，一方面是要管理底层的物理资源，负责对资源的状态进行管控。另外一方面响应用户OpenAPI调用，来完成用户的业务请求处理。
在弹性计算控制系统之前的实现中，这两个部分是相互耦合的。既需要进行资源状态的管理，也需要实现复杂的用户业务。但其实这两个部分差异性比较大，资源状态管理的业务逻辑变化较小，并发度高，对稳定性较为敏感。而用户业务则变化快，业务逻辑较为复杂。
因此，我们将状态管理和业务逻辑做了分层。底层是状态管理的集群，集群逻辑简单但体量较大，比较稳定，不需要有太多的发布。而业务逻辑部分被放到上层，由RPC调用连接的微服务集群，等于是一个ServiceMesh集群，服务之间的依赖非常复杂，变化也非常快，且无状态。这使得逻辑上异构的两个部分分隔开，解决了稳定性和高并发的问题，同时也满足业务逻辑的高效迭代。
业务逻辑层采用模块化和服务化架构，使得各个系统之间的职责较清晰，各个服务的角色可以被清楚的定义。各个系统使用标准的公共API进行交互，使得系统耦合度降低，服务可以独立快速演进迭代。
另外，我们引入了事件驱动架构，通过事件模型将系统里面核心链路和非关键模块解耦，解决非关键模块对核心链路的稳定性影响问题。另外也使得系统的核心链路可以保持清晰有效，提升了系统的稳定性和性能，使得系统的开发和迭代更加高效。
上面我们通过架构的演进和优化，解决系统快速的演进和迭代的问题，下面来看一下团队是如何通过积累和建设公共的框架和组件，使得业务开发可以事半功倍。
图5：ecs-yaochi-peento架构图
2015年6月，弹性计算控制系统团队创建了ecs-common-framework，在业务开发的过程中，将一些通用的组件积累到这个公共库中，其中包含了缓存、幂等、限流、工作流等等功能。到2021年，ecs-common-framework中已经完成了近230多个版本的发布，为业务的开发提供了有效的支持。我们也对其进行了模块化方式重构，并命名为yaochi-peento-framework，使得项目更加规范化，简化依赖管理，接入更为方便。目前已有多个云产品接入使用。
yaochi-peento-framework框架由四个部分组成：
l 基础框架：包含了分布式后端服务开发的公共组件，包括缓存，配置，幂等，序列化等。
l 业务模块：包含了OnECS的公共业务组件，提供OnECS通用支持，包括Quota，ActionTrail，Tag等。
l SpringBoot Stater：整个框架会基于springboot进行输出，使得业务方可以非常方便集成和管理。
l 生命周期管理：提供业务域的生命周期管理，包括应用的初始化，运维等能力。
有了上述的yaochi-peento-framework，使得业务方开发新的云产品变得非常方便。正是因为在2015年创建了ecs-common-framework，写下第一行代码， 我们才能在2021年对其进行重构和升级，使其更为标准化和易于接入。yaochi-peento-framework使得开发云产品控制系统的效率提升，并且成本大大降低。目前该模块不仅仅是在弹性计算内部使用，也被推广到弹性计算之外的其他云产品团队。
图6：yaochi-peento-cache模块架构图
下面我们来介绍一下在yaochi-peento-framework里面，我们是如何设计和实现一个公共的组件。
公共组件方面，标准化和高可用是首要的两个原则。组件的建设需要提供标准的API，同时具有完备的文档描述和严谨的Changelog跟踪信息。另外组件需要对高并发，高可用的业务有实际的实现支持，是高并发分布式系统的最佳实践总结。
另外，可插拔和可扩展也是系统非常关键的原则，弹性计算的部署架构非常复杂，要支持多种不同的部署形态，包括公共云，专有云，分布式云等。在不同环境部署时，依赖往往不一致，因此作为基础组件，需要提供可适配的能力，yaochi-peento-framework中的所有的组件都提供通用的interface，并且做到可以支持多种实现。比如上面图6中左边的部分所示，yaochi-pento-cache模块提供了统一的缓存的interface，但在同一套interface下支持多种缓存的实现，可以做到在不同的部署形态依赖不同的缓存实现，但因为这些缓存系统都实现了同一套interface来工作，因此可以做到让业务逻辑对实际的实现部分无感，这使得系统往前演进支持更多部署形态的时候会非常便捷。
最后，可观测和可运维的能力也至关重要。所有组件都会有统一的可观察能力输出，全部通过SLS(阿里云内部的日志系统)接入，最后汇总到Grafana上，业务系统接入后即可马上获取到所有的观测数据。同时组件也会默认提供opsapi来支持运维能力。
yaochi-peento-framework累积了系统开发中的最佳实践的组件，对该框架的复用使得新的业务和服务开发可以直接使用现有组件的能力，大大提升了应用开发的效能。
图7：弹性计算多地域运维平台
除了分布式系统碰到的高并发，高可用问题之外，在弹性计算控制系统的场景里，还会有多地域管理的复杂度问题。这是因为地域管控的环境非常多（目前已经有50多个环境），中间件提供的控制台的能力已经无法满足我们的管理需求。使用API，工具化和自动化的方式是唯一的选择，这里我们引入了最近较为流行的平台工程（Platform Engineering）的概念。我们让中间件提供API，而不是控制台，我们通过调用中间件提供的API来提供单元化的运维能力，通过单元化的运维服务输出，然后由全局的运维服务平台整体集成。这样，运维多个地域时，不再需要切换控制台逐个操作，而只需要通过总的运维平台进行管理运维即可。
运维API的集成能力还使得采用自动化，流程化的平台方案成为可能。
图8：中间件和基础组件升级流程
最后，在技术方案上，我想讨论一下中间件和基础技术组件的升级。弹性计算控制系统内部设计了一个框架和组件的升级流程。组件的引入策略，引入之后有流程进行跟踪，评判组件状态，每个组件都会有相应owner，负责了解组件的情况，比如是否有大的bugfix，或大的功能更新等，并按照实际需要进行主动升级。我们并不一定会对每一次更新都进行升级，但能够做到对每一版本都了如指掌。
一方面这样做使得我们可以及时了解组件或者框架在功能，安全性和性能方面的升级，能及时评估并安排升级，获得相应的红利。另外一方面，当出现相关的安全性漏洞风险，需要进行临时紧急升级时，我们也会对相关的影响面较为了解，能充分评估升级影响，降低风险。
一句话来说，有准备的升级，相比较临时评估升级，效率要更高。
三、规范流程制定，建立效能脉络
图9：规范和流程
了解了技术方面的内容，我们来看一下流程。在弹性计算控制系统团队，我们的流程分为规划设计、编码测试、发布以及运维等几个阶段。
在每一个阶段，实际上我们都会有较为严格流程，在这里，我想要分享的是几个我认为较为有效的流程或者工具。
第一个是RFC机制，RFC的全文是“Request For Comments”，意思是“请求对方案进行评审”。规划设计阶段，RFC实际是一种重要的沟通方式，它是方案设计初期的核心设计思想的描述，我们鼓励同学在方案设计初期就通过记录RFC来进行沟通，并将讨论的过程通过comments进行记录，并对其进行不断补充完善，直至它能够成为一个完整的方案。这样使得构想和设计都能在一开始就记录，并能不断推进，最终形成可以讨论实施的方案。
另外在技术文档方面，对于开发人员而言，写文档是一件极具挑战的事。因为系统在不停的变化，今天写下的文档，可能在很短的时间之后就失效了。因此，在弹性计算控制系统团队内部，我们采用的方式是让开发人员在开发的每一步都将评审和方案做到足够详尽完善，最后我们输出的是当前方案的详细技术文档，这样等于我们记录了对系统每一次变更的详细方案，新的同学并不是通过学习一个大而全的文档，而是学习系统每一次更新的方案，来了解系统的全貌。
四、工程师文化建设，丰富效能氛围
图10：工程师文化
最后我们来看一下弹性计算内是如何来进行工程师文化的建设。 在考虑这个问题的时候，考虑到与时俱进，我也去问了一下ChatGPT，它给的答案是“好的工程师文化应该是大家共同拥有的目标，有共同的价值思考，有共同的实践”。
在我们团队内部，为了营造良好的工程师文化，会在内部举行定期的技术分享，比如每周4晚上举行的“Hacking Thursday”分享活动。另外有新的方案或有方案评审时，我们也会鼓励大家只在钉钉群内做直播。不论直播效果如何，工程师准备直播的过程也是一种自我促进，当你能讲清楚一个方案的时候，说明你的方案设计已经是比较完善了。
同时，我们会举办内部的技术比赛，促进工程师之间的相互交流与学习。我们还在内部推行了一项名为 “Feature Market”的项目，会将一些探索性的、重要但不紧急的工作作为员工平时的赛马项目，同时也作为实习生项目，调动实习生思考和探索的积极性，也取得了良好的效果。
图11：高效团队的技术展望
最后我们来看一下高能效团队的展望，我觉得重要的一点事需要拥抱云原生技术，这是因为现在很多软件工程和架构的创新都是基于云原生的技术来完成的，如果不紧跟技术前进的潮流，可能就会被落下。虽然弹性计算是一个IaaS层的基础服务，但是我们也需要积极采用云原生的技术，就像编译系统一样，阿里云IaaS到PaaS的整个技术栈也需要能实现自举能力。
另外一个就是人工智能技术，主要是下面的几个方案，一是可以帮助进行知识系统的建设，文档的生成和维护等等。其次，可以通过人工智能来进行编码辅助。第三是可以通过AI来实现智能技术支持。最后，我们也希望能够利用AI帮助团队做决策，但想要利用人工智能辅助架构和技术设计，前提是先让人工智能理解我们的技术和数据。
