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幫助團隊做決策，但想要利用人工智能輔助架構和技術設計，前提是先讓人工智能理解我們的技術和數據。
本文爲阿里雲原創內容，未經允許不得轉載。