共计 5596 个字符，预计需要花费 14 分钟才能阅读完成。
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 框架由四个局部组成：
- 根底框架：蕴含了分布式后端服务开发的公共组件，包含缓存，配置，幂等，序列化等。
- 业务模块：蕴含了 OnECS 的公共业务组件，提供 OnECS 通用反对，包含 Quota，ActionTrail，Tag 等。
- SpringBoot Stater：整个框架会基于 springboot 进行输入，使得业务方能够十分不便集成和治理。
- 生命周期治理：提供业务域的生命周期治理，包含利用的初始化，运维等能力。
有了上述的 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 帮忙团队做决策，但想要利用人工智能辅助架构和技术设计，前提是先让人工智能了解咱们的技术和数据。
原文链接
本文为阿里云原创内容，未经容许不得转载。