2023 年 3 月 25 日，“城市領(lǐng)航之夜第一期”活動(dòng)在上海舉行，阿里云彈性計(jì)算控制系統(tǒng)技術(shù)架構(gòu)負(fù)責(zé)人李鐘出席了本次活動(dòng)并帶來(lái)了《彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)提效之路》的主題演講，為大家詳細(xì)分享了阿里云彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)所面臨的挑戰(zhàn)、如何通過(guò)技術(shù)架構(gòu)提效，以及工程師文化建設(shè)等一系列內(nèi)容。本文根據(jù)其演講內(nèi)容整理而成。

我從 2011 年開(kāi)始就入職了阿里巴巴，主要負(fù)責(zé) IM 服務(wù)端的工作，15 年加入了阿里云，在此期間一直負(fù)責(zé)業(yè)務(wù)的開(kāi)發(fā)，2019 年擔(dān)任了控制系統(tǒng)技術(shù)架構(gòu)負(fù)責(zé)人，主要完成了阿里云彈性計(jì)算單元化架構(gòu)的升級(jí)。今天的分享，我將從問(wèn)題、技術(shù)架構(gòu)、規(guī)范流程和工程師文化四個(gè)維度，通過(guò)彈性計(jì)算的角度以及技術(shù)和架構(gòu)的角度，來(lái)分享彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)的提效之路。

從問(wèn)題出發(fā)，看當(dāng)前的挑戰(zhàn)

阿里云彈性計(jì)算管控系統(tǒng)是一個(gè)大型的分布式系統(tǒng)，支持高并發(fā)和高可用，除此之外，也有自己獨(dú)特的復(fù)雜度。

• 規(guī)模大：管理全球 50 多個(gè)環(huán)境，支持 28 個(gè)公共云地域，兼容專有云技術(shù)和業(yè)務(wù)，并且已擴(kuò)展到新的本地云、專屬云等分布式云場(chǎng)景，規(guī)模非常龐大。以管理全球 50 個(gè)以上的環(huán)境為例，應(yīng)用在做配置發(fā)布時(shí)需要在全球范圍內(nèi)變更 50 余次，這對(duì)系統(tǒng)的開(kāi)發(fā)、運(yùn)維和管理都帶來(lái)巨大的挑戰(zhàn)。
• 業(yè)務(wù)復(fù)雜：彈性計(jì)算的產(chǎn)品類型不斷向前發(fā)展，我們需要對(duì)每種類型都提供支持。且因?yàn)樵朴?jì)算底層是物理資源，業(yè)務(wù)需要對(duì)物理資源的限制進(jìn)行描述和管理，因此業(yè)務(wù)邏輯也非常復(fù)雜。

對(duì)于阿里云而言，所有云產(chǎn)品都基于 ECS 構(gòu)建，因此穩(wěn)定性非常重要。但是系統(tǒng)本身還需要進(jìn)行架構(gòu)的升級(jí)和演進(jìn)。我們要在技術(shù)演進(jìn)、穩(wěn)定性以及效能三者之間做到平衡。保持業(yè)務(wù)和技術(shù)的快速演進(jìn)和升級(jí)，同時(shí)又要保障不出現(xiàn)穩(wěn)定性的問(wèn)題。

最后從團(tuán)隊(duì)的規(guī)模來(lái)看，彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)規(guī)模持續(xù)擴(kuò)大，近年內(nèi)已經(jīng)增長(zhǎng)近 6 倍。我們面臨的挑戰(zhàn)愈發(fā)嚴(yán)峻。

技術(shù)架構(gòu)優(yōu)先，構(gòu)建效能基座

我們主張優(yōu)先考慮技術(shù)架構(gòu)的升級(jí)和優(yōu)化來(lái)構(gòu)建效能的基座?？偨Y(jié)來(lái)說(shuō)，有下面圖中所示的 4 個(gè)方面。

首先，通過(guò)短期的方案快速解決問(wèn)題。主要是三個(gè)手段，通過(guò)并發(fā)的方式投入提高速度，這也意味著會(huì)使用更多的資源；通過(guò)自動(dòng)化和工具化的方式降低人力；通過(guò)引入標(biāo)準(zhǔn)化的流程來(lái)保證正確性。

短期的解決方案能夠達(dá)到立竿見(jiàn)影的效果，為團(tuán)隊(duì)建立信心，讓成員知道問(wèn)題正在被關(guān)注和解決，促使每個(gè)人都去思考如何解決自己面臨的問(wèn)題，并為長(zhǎng)期發(fā)展贏得時(shí)間。

短期方案臨時(shí)解決問(wèn)題之后，就要持續(xù)規(guī)劃架構(gòu)技術(shù)的升級(jí)，解決核心問(wèn)題。這里主要包括三個(gè)方面，一是要思考問(wèn)題的根本原因，從而有效的解決問(wèn)題，而不是躲避問(wèn)題。規(guī)劃架構(gòu)和技術(shù)的持續(xù)升級(jí)來(lái)根據(jù)實(shí)際情況構(gòu)建高效的系統(tǒng)。二是堅(jiān)持使用工具化、可集成、平臺(tái)化的方式解決問(wèn)題。保障技術(shù)升級(jí)的可持續(xù)性。最后要持續(xù)升級(jí)基礎(chǔ)服務(wù)，中間件和基礎(chǔ)組件，在代碼不斷演進(jìn)的過(guò)程中，享受組件升級(jí)帶來(lái)的性能和效能紅利。

第三點(diǎn)，需要優(yōu)化研發(fā)流程，使其靈活有效，避免缺少流程導(dǎo)致出現(xiàn)問(wèn)題。也要避免流程過(guò)多導(dǎo)致系統(tǒng)臃腫的問(wèn)題，探索新的思路，使用先進(jìn)的思路和工具提效。

最后，需要不斷沉淀和積累，一方面是知識(shí)體系的沉淀，同時(shí)也要注重構(gòu)建可復(fù)用的系統(tǒng)框架和組件。下面我們重點(diǎn)來(lái)看上面提到的第一點(diǎn)，如何通過(guò)系統(tǒng)架構(gòu)升級(jí)來(lái)構(gòu)建效能的基座。

彈性計(jì)算管控系統(tǒng)負(fù)責(zé)處理的業(yè)務(wù)可以分為兩個(gè)部分，一方面是要管理底層的物理資源，負(fù)責(zé)對(duì)資源的狀態(tài)進(jìn)行管控。另外一方面響應(yīng)用戶 OpenAPI 調(diào)用，來(lái)完成用戶的業(yè)務(wù)請(qǐng)求處理。

在彈性計(jì)算控制系統(tǒng)之前的實(shí)現(xiàn)中，這兩個(gè)部分是相互耦合的。既需要進(jìn)行資源狀態(tài)的管理，也需要實(shí)現(xiàn)復(fù)雜的用戶業(yè)務(wù)。資源狀態(tài)管理的業(yè)務(wù)邏輯變化較小，并發(fā)度高，對(duì)穩(wěn)定性較為敏感。而用戶業(yè)務(wù)則變化快，實(shí)現(xiàn)較為復(fù)雜。

因此，我們將狀態(tài)管理和業(yè)務(wù)邏輯做了分層。底層是狀態(tài)管理的集群，集群邏輯簡(jiǎn)單但體量較大，比較穩(wěn)定，不需要有太多的發(fā)布。而業(yè)務(wù)邏輯部分被放到上層，由 RPC 調(diào)用連接的微服務(wù)集群，整個(gè)集群類似于 ServiceMesh，服務(wù)之間的依賴非常復(fù)雜，變化也非?？?，且無(wú)狀態(tài)。這使得邏輯上異構(gòu)的兩個(gè)部分可以分隔開(kāi)，解決了穩(wěn)定性和高并發(fā)的問(wèn)題，同時(shí)也滿足業(yè)務(wù)邏輯的高效迭代。

業(yè)務(wù)邏輯層采用模塊化和服務(wù)化架構(gòu)，使得各個(gè)系統(tǒng)之間的職責(zé)較清晰，各個(gè)服務(wù)的角色可以定義。各個(gè)系統(tǒng)使用標(biāo)準(zhǔn)的公共 API 進(jìn)行交互，使得系統(tǒng)耦合度降低，服務(wù)之間可以獨(dú)立快速演進(jìn)迭代。

另外，我們引入了事件驅(qū)動(dòng)架構(gòu)，通過(guò)事件模型將系統(tǒng)里面核心鏈路和非關(guān)鍵模塊解耦，解決非關(guān)鍵模塊對(duì)核心鏈路的穩(wěn)定性影響問(wèn)題。另外也使得系統(tǒng)的核心鏈路可以保持清晰有效，提升了系統(tǒng)的穩(wěn)定性和性能。也使得系統(tǒng)的開(kāi)發(fā)和迭代更加高效。

上面我們通過(guò)架構(gòu)的演進(jìn)和優(yōu)化，解決系統(tǒng)快速的演進(jìn)和迭代的問(wèn)題，下面來(lái)看一下團(tuán)隊(duì)是如何通過(guò)積累和建設(shè)公共的框架和組件，使得業(yè)務(wù)開(kāi)發(fā)可以事半功倍。

2015 年 6 月，彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)創(chuàng)建了 ecs-common-framework，在業(yè)務(wù)開(kāi)發(fā)的過(guò)程中，將一些通用的組件積累到這個(gè)公共庫(kù)中，其中包含了緩存，冪等，限流，工作流等等功能。到 2021 年，ecs-common-framework 中已經(jīng)完成了近 230 多個(gè)版本的發(fā)布，為業(yè)務(wù)的開(kāi)發(fā)提供了有效支持。到 2021 年，我們對(duì)其進(jìn)行了模塊化方式重構(gòu)，并命名為 yaochi-peento-framework，目前已有多個(gè)云產(chǎn)品接入使用。

yaochi-peento-framework 框架由四個(gè)部分組成：

• 基礎(chǔ)框架：包含了分布式后端服務(wù)開(kāi)發(fā)的公共組件，包括緩存，配置，冪等，序列化等。
• 業(yè)務(wù)模塊：包含了OnECS的公共業(yè)務(wù)組件，提供 OnECS 通用支持，包括 Quota，ActionTrail，Tag 等。
• SpringBoot Stater：整個(gè)框架會(huì)基于 springboot 進(jìn)行輸出，是的業(yè)務(wù)方可以非常方便集成和管理。
• 生命周期管理：提供業(yè)務(wù)域的生命周期管理，包括應(yīng)用的初始化，運(yùn)維等能力。

有了上述的 yaochi-peento-framework，使得業(yè)務(wù)方開(kāi)發(fā)新的云產(chǎn)品變得非常方便。正是因?yàn)樵?2015 年創(chuàng)建了 ecs-common-framework，寫(xiě)下第一行代碼， 才能在 21 年進(jìn)行重構(gòu)和升級(jí)。yaochi-peento-framework 使得開(kāi)發(fā)云產(chǎn)品控制系統(tǒng)的效率提升，并且成本大大降低。目前該模塊不僅僅是在彈性計(jì)算內(nèi)部使用，也被推廣到彈性計(jì)算之外的其他云產(chǎn)品團(tuán)隊(duì)。

下面我們來(lái)介紹一下在 yaochi-peento-framework 里面，我們是如何設(shè)計(jì)和實(shí)現(xiàn)一個(gè)公共的組件。

公共組件方面，標(biāo)準(zhǔn)化和高可用是首要的兩個(gè)的原則。組件的建設(shè)需要提供標(biāo)準(zhǔn)的 API，同時(shí)具有完備的文檔描述和嚴(yán)謹(jǐn)?shù)?Changelog 跟蹤。在高并發(fā)方面，一方面只得是組件需要能支持高并發(fā)的調(diào)用，另外也需要對(duì)高并發(fā)的業(yè)務(wù)有特殊的實(shí)現(xiàn)，組件應(yīng)該是高并發(fā)分布式系統(tǒng)的最佳實(shí)踐總結(jié)。

另外，可插拔和可擴(kuò)展也是系統(tǒng)非常關(guān)鍵的原則，彈性計(jì)算的部署架構(gòu)非常復(fù)雜，要支持多種不同的部署形態(tài)，包括公共云，專有云，分布式云等。在不同環(huán)境部署時(shí)，依賴往往不一致，因此作為基礎(chǔ)組件，需要提供可適配的能力。

yaochi-peento-framework 中的所有的組件都提供通用的 interface，并且做到可以支持多種實(shí)現(xiàn)。比如上面圖中左邊的部分所示，yaochi-pento-cache 模塊提供了統(tǒng)一的緩存的 interface，但在同一套 interface 下支持多種緩存的實(shí)現(xiàn)，可以做到在不同的部署形態(tài)依賴不同的緩存實(shí)現(xiàn)，但因?yàn)檫@些緩存系統(tǒng)都實(shí)現(xiàn)了同一套 interface 來(lái)工作，因此對(duì)業(yè)務(wù)邏輯部分無(wú)感，這使得系統(tǒng)往前演進(jìn)支持更多部署形態(tài)的時(shí)候會(huì)非常便捷。

可觀測(cè)和可運(yùn)維的能力也至關(guān)重要。所有組件都會(huì)有統(tǒng)一的可觀察能力輸出,全部通過(guò) SLS（阿里云內(nèi)部的日志系統(tǒng)），最后匯總到 Grafana 上，業(yè)務(wù)系統(tǒng)接入后即可馬上獲取到所有的觀測(cè)數(shù)據(jù)。同時(shí)組件也會(huì)默認(rèn)提供 opsapi 來(lái)支持運(yùn)維能力。

yaochi-peento-framework 累積了系統(tǒng)開(kāi)發(fā)中的最佳實(shí)踐的組件，對(duì)該框架的復(fù)用使得新的業(yè)務(wù)和服務(wù)開(kāi)發(fā)可以直接使用現(xiàn)有組件的能力，大大提升了應(yīng)用開(kāi)發(fā)的效能。

除了分布式系統(tǒng)碰到的問(wèn)題之外，在彈性計(jì)算控制系統(tǒng)的場(chǎng)景里，還會(huì)有多地域管理的復(fù)雜度問(wèn)題，這是因?yàn)榈赜蚬芸氐沫h(huán)境非常多（目前已經(jīng)有 50 多個(gè)環(huán)境），中間件提供的控制臺(tái)的能力已經(jīng)無(wú)法滿足我們的管理需求。使用 API，工具化和自動(dòng)化的方式是唯一的選擇，這里我們引入了近幾年較為流行的平臺(tái)工程（Platform Engineering）的概念。我們希望中間件提供 API，而不是控制臺(tái)給我們，將所有 API 匯集，通過(guò)單元化的運(yùn)維服務(wù)輸出，然后由全局的運(yùn)維服務(wù)平臺(tái)整體集成。這樣，運(yùn)維多個(gè)地域時(shí)，不再需要切換控制臺(tái)逐個(gè)操作，而只需要通過(guò)總的運(yùn)品臺(tái)進(jìn)行管理運(yùn)維即可。

運(yùn)維 API 的集成能力還使得采用自動(dòng)化，流程化的平臺(tái)方案成為可能。

最后，在技術(shù)方案，我們想討論一下中間件和基礎(chǔ)技術(shù)組件的升級(jí)。彈性計(jì)算控制系統(tǒng)內(nèi)部設(shè)計(jì)了一個(gè)框架和組件的升級(jí)流程。組件的引入策略，引入之后有流程進(jìn)行跟蹤，評(píng)判組件狀態(tài)，每個(gè)組件都會(huì)有相應(yīng) owner，負(fù)責(zé)了解組件的情況，比如是否有大的 bugfix，或大的能力更新等，并按照實(shí)際需要進(jìn)行主動(dòng)升級(jí)。我們并不一定會(huì)對(duì)每一次更新都進(jìn)行升級(jí)，但能夠做到對(duì)每一版本都了如指掌。

一方面這樣做是的我們可以及時(shí)了解組件或者框架在功能，安全性和性能方面的升級(jí)，能及時(shí)評(píng)估并安排升級(jí)，獲得相應(yīng)的紅利。另外一方面，當(dāng)出現(xiàn)相關(guān)的安全性漏洞風(fēng)險(xiǎn)，需要進(jìn)行升級(jí)時(shí)，也會(huì)對(duì)相關(guān)的影響面較為了解，升級(jí)影響評(píng)估充分，風(fēng)險(xiǎn)降低。

一句話來(lái)說(shuō)，有準(zhǔn)備的升級(jí)，相比較臨時(shí)評(píng)估升級(jí)，效率要更高。

規(guī)范流程制定，建立效能脈絡(luò)

了解完技術(shù)方面的內(nèi)容，我們來(lái)看一下流程。在彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)，我們的流程分為規(guī)劃設(shè)計(jì)、編碼測(cè)試、發(fā)布以及運(yùn)維等幾個(gè)階段。

在每一個(gè)階段，實(shí)際上我們都會(huì)有較為嚴(yán)格的流程，在這里，我想分享的是幾個(gè)我認(rèn)為較為有效的流程或者工具。

第一個(gè)是 RFC 機(jī)制，RFC 的全文是“Request For Comments”，意思是讓大家來(lái)評(píng)審。規(guī)劃設(shè)計(jì)階段，RFC 是一種重要方式。我們鼓勵(lì)同學(xué)記錄下所有靈光一現(xiàn)的想法，并在日常對(duì)其進(jìn)行不斷補(bǔ)充擴(kuò)大，直至它能夠成為一個(gè)完整的方案，才會(huì)最終被呈上供團(tuán)隊(duì)進(jìn)行討論和決策，提高討論效率，避免浪費(fèi)時(shí)間。

另外在技術(shù)文檔方案，但對(duì)于開(kāi)發(fā)人員而言，寫(xiě)文檔是一件極具挑戰(zhàn)的事。因?yàn)橄到y(tǒng)在不停的變化，今天寫(xiě)下的文檔，可能在很短的時(shí)間之后就失效了。因此，在彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)內(nèi)部，我們采用的方式是讓開(kāi)發(fā)人員在開(kāi)發(fā)的每一步都將評(píng)審和方案做到足夠詳盡完善，最后我們輸出的是當(dāng)前方案的詳細(xì)技術(shù)文檔，這樣等于我們記錄了對(duì)系統(tǒng)每一次變更的詳細(xì)方案，新的同學(xué)并不是通過(guò)學(xué)習(xí)一個(gè)大而全的文檔，而是學(xué)習(xí)系統(tǒng)每一次更新的方案，來(lái)了解系統(tǒng)的全貌。

工程師文化建設(shè)，豐富效能氛圍

最后我們來(lái)看一下彈性計(jì)算內(nèi)是如何來(lái)進(jìn)行工程師文化的建設(shè)。

在考慮這個(gè)問(wèn)題的時(shí)候，我也去問(wèn)了一下 ChatGPT，它給的答案是“好的工程師文化應(yīng)該是大家共同擁有的目標(biāo)，有共同的價(jià)值思考，有共同的實(shí)踐”。

在我們團(tuán)隊(duì)內(nèi)部，為了營(yíng)造良好的工程師文化，會(huì)在內(nèi)部舉行定期的技術(shù)分享，比如每周四晚上舉行的“Hack Thursday”分享活動(dòng)。另外有新的方案或有方案評(píng)審時(shí)，我們會(huì)鼓勵(lì)大家做直播。不論直播效果如何，工程師準(zhǔn)備直播的過(guò)程也是一種自我促進(jìn)。

同時(shí)，我們會(huì)舉辦內(nèi)部的技術(shù)比賽，促進(jìn)工程師之間的相互交流與學(xué)習(xí)。

最后，我們還推行了一項(xiàng)名為 feature marke 的工作，會(huì)將一些探索性的、重要但不緊急的工作作為員工平時(shí)的賽馬項(xiàng)目，同時(shí)也作為實(shí)習(xí)生項(xiàng)目，調(diào)動(dòng)實(shí)習(xí)生思考和探索的積極性，也得到了良好的效果。

最后我們來(lái)看一下高能效團(tuán)隊(duì)的展望。

首先我們需要擁抱云原生技術(shù)，因?yàn)楝F(xiàn)在很多軟件工程和架構(gòu)的創(chuàng)新都是基于云原生的技術(shù)來(lái)完成的，雖然彈性計(jì)算是一個(gè) IaaS 層的基礎(chǔ)服務(wù)，但是我們也需要積極采用云原生的技術(shù)，就像編譯系統(tǒng)一樣，實(shí)現(xiàn)自舉能力。

另外一個(gè)就是人工智能技術(shù)，主要是下面的幾個(gè)方案：

• 首先，可以幫助進(jìn)行知識(shí)系統(tǒng)的建設(shè)，文檔的生成和維護(hù)等；
• 其次，可以通過(guò)人工智能來(lái)進(jìn)行編碼輔助；
• 第三是可以通過(guò) AI 來(lái)實(shí)現(xiàn)智能技術(shù)支持；
• 最后，我們也希望能夠利用 AI 幫助團(tuán)隊(duì)做決策，但想要利用人工智能輔助架構(gòu)和技術(shù)設(shè)計(jì)，前提是先讓人工智能理解我們的技術(shù)和數(shù)據(jù)。

阿里云李鐘：彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)的提效之路文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-794192.html

到了這里，關(guān)于阿里云李鐘：彈性計(jì)算控制系統(tǒng)團(tuán)隊(duì)的提效之路的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！