云原生架構應該怎么設計？

作者：佚名 2021-07-07 17:26:20

阿里巴巴為大量各行各業的企業客戶提供了基于阿里云服務的解決方案和最佳實踐，以幫助企業完成數字化轉型，并積累了大量經驗和教訓。阿里巴巴將企業的核心關注點、企業組織與 IT 文化、工程實施能力等多個方面與架構技術相結合，形成了阿里巴巴獨有的云原生架構設計方法— ACNA（Alibaba Cloud Native Architecting ）。這套方法在阿里云官方最近出版的暢銷書《阿里云云原生架構實踐》中有更詳盡的介紹。

[[409977]]

ACNA 的概念

（1）ACNA 的作用與目的

1）提升研發團隊的能力，實現成本、進度計劃、功能和質量等目標。
2）指導研發團隊控制研發和運維過程，優化 IT 組織結構并打造更加高效的軟件工程流程機制。
3）引導研發團隊，在確定云原生架構的成熟度以及定位云原生化方面關鍵問題的過程中選擇改進策略。

（2）ACNA 的實現步驟

1）確定企業當前所處的云原生架構成熟度級別。
2）了解會對改進生產質量和優化過程起關鍵作用的因素。
3）將工作重點集中在有限的幾個關鍵目標上，從而有效達到優化現有研發流程的效果，進而持續改進產品。
ACNA 是一個“ 4+1 ”的架構設計流程，其中，“ 4 ”代表架構設計的關鍵視角，包括企業戰略視角（ACNA-S1）、業務發展視角（ACNA-S2）、組織能力視角（ACNA-S3）和云原生技術架構視角（ACNA-S4）；“ 1 ”表示云原生架構的架構持續演進閉環（ACNA-S5）。4 個關鍵視角和 1 個閉環的關系（命名為 ACNA-G1 ），如圖 1 所示。

圖 1 ACNA-G1：ACNA 架構設計流程關系示意圖

ACNA 除了是一種架構設計方法，還包含對云原生架構的評估體系、成熟度衡量體系、行業應用最佳實踐、技術和產品體系、架構原則、實施指導等。本書的其他章節將分別詳細講解云原生的技術和產品體系、架構原則、最佳實踐等方面，這里主要介紹云原生架構的成熟度衡量體系和實施指導兩個方面。

ACNA-S1：企業戰略視角

任何架構都必須服務于企業戰略，云原生架構也不例外！與以往架構的升級有所不同，云原生架構的升級不僅是技術的升級，更是對企業核心業務生產流程（即通過軟件開發和運營構建數字化業務）的一次重構，云原生架構升級的意義，如同工業時代用更自動化的流水線替換手工作坊一樣深刻。

企業必須清楚業務戰略與云 IT 戰略之間的關系，即云 IT 戰略只是對業務戰略進行必要的技術支撐，還是云 IT 戰略本身也是業務戰略的一部分。通常，高科技公司會對云計算提出更高的需求，比如，通過大量使用云廠商提供的 AI 技術為用戶提供智能化的用戶體驗，以及使用 IoT（物聯網）和音視頻技術為用戶建立更廣泛、生動的連接。

實際上，在數字化轉型的今天，越來越多的企業認為云 IT 戰略應該在企業業務戰略中扮演技術賦能業務創新的重要角色，云 IT 已經變成了“ Cloud First ”，甚至“ Cloud Only ”，只是在全部采用公有云還是采用混合云的策略上存在一些差別。基于云 IT 戰略，云原生架構可以幫助企業實現泛在接入技術，構建數字化生態系統，還可以從技術的角度確保數字化業務的快速迭代，構建面向用戶體驗管理的數字基礎設施，持續優化 IT 成本，降低業務風險。

ACNA-S2：業務發展視角

阿里巴巴在為企業提供云服務和咨詢的過程中發現，數字化業務對技術架構的主要訴求是保證業務連續性、業務快速上線、業務成本控制，以及科技賦能業務創新。業務連續性訴求主要是指數字化業務必須能夠為用戶持續提供服務，不能因為軟硬件故障或 Bug 導致業務不可用，還要能夠防止黑客攻擊、數據中心不可用、自然災害等意外事故發生。此外，當業務規模快速增長時，軟硬件資源的購買和部署一定要及時，以便企業能夠更好地拓展新用戶。

市場瞬息萬變，相較于傳統業務，數字化業務具有更靈活的特性，這就要求企業具備更快的“業務到市場”的能力，包括新業務快速構建、現有業務快速更新等。云原生架構能夠深刻理解企業對這些能力的訴求，并在產品、工具、流程等多個層面進行不同程度的處理。需要注意的是，這些訴求同時對組織結構帶來新的要求，可能會要求應用進行徹底重構（比如微服務化）。

云計算必須為企業釋放成本紅利，幫助企業從原來的 CaPex 模式轉變為 OpEx 模式，即不用事先購買大批軟硬件資源，而是用多少支付多少；同時，大量采用云原生架構也會降低企業的開發和運維成本。有數據顯示，通過容器平臺技術可使運維支出成本降低 30%。

傳統模式下，如果要使用高科技賦能業務，則會經歷一個冗長的選型、POC、試點和推廣的過程，而如果選擇使用云廠商和第三方提供的云服務，則可以更快速地應用新技術進行創新。因為這些云服務具備更快的連接速度和更低的試錯成本，且在不同技術的集成上具備統一平臺和統一技術依賴的優勢。

ACNA-S3：組織能力視角

云原生架構升級是對企業的整個 IT 架構的徹底升級，每個組織在進行云原生架構升級時，必須根據企業自身的情況量體裁衣，其中，組織能力和技術棧處于同等重要的地位。云原生架構涉及的架構升級對企業中的開發、測試和運維等相關人員都帶來了巨大的影響，技術架構的升級和實現需要企業中相關組織的積極參與和配合。特別是在架構持續演進的過程中，需要類似“架構治理委員會”這樣的組織負責云原生的規劃和落地，并不斷檢查和評估架構設計與執行之間是否存在偏差。

此外，云原生架構的設計還需要考慮組織結構的改變。前面提到一個非常重要的云原生架構原則就是服務化（包括微服務、小服務等），這個領域的一個典型原則就是康威定律，要求企業的技術架構與溝通架構必須保持一致，否則會導致畸形的服務化架構，甚至導致組織溝通成本上升和“扯皮”現象增多的問題。

企業需要考慮的另外一個很重要的問題就是，企業接受改變的程度如何，或者說，企業能夠快速進行組織結構調整，并保持業務穩定性的能力如何。云原生架構升級要求大量的企業 IT 人員也進行技術體系的升級和崗位職能的重新設計，這勢必導致原本處于穩定和舒適區的技術領導者和底層員工必須破而再立，所以組織改變的風險不得不慎重考慮。

ACNA-S4：云原生技術架構視角

從技術架構的維度看，ACNA 認為架構維度包含七個重要的領域，具體說明如下。

（1）服務化能力
用微服務或小服務構建業務，分離大塊業務中具備不同業務迭代周期的模塊，業務以標準化 API 等方式對模塊進行集成和編排；服務間采用事件驅動的方式集成，減少相互依賴；通過可度量建設不斷提升服務的 SLA（Service Level Agreement，服務等級協議）能力。

（2）彈性能力
利用云資源的特性，根據業務峰值和資源負載情況來自動擴充或收縮系統的規模，業務不再需要進行容量評估、按量付費。

（3）無服務器化程度
在業務中，應盡量使用云服務，而不是自己持有第三方服務，特別是自己維護開源軟件的模式；應用的設計應盡量變換成無狀態模式，把有狀態的部分保存到云服務中。進一步采用 Serverless 技術體系重構應用運行時，讓軟件的底層運維逐漸“消失”。

（4）可觀測性
IT 設施需要得到持續治理，任何 IT 設施中的軟硬件發生錯誤后都要具備快速修復的能力，以避免影響業務，這就需要系統具備全面的可觀測性，內容涉及對傳統的日志方式、監控、APM、鏈路跟蹤、服務質量（Quality of Service，QoS）度量等多個方面。

（5）韌性能力
韌性能力除了包括服務化中常用的熔斷、限流、降級、自動重試、背壓等特性之外，還包括高可用、容災、異步化等特性。

（6）自動化水平
關注開發、測試和運維三個過程的敏捷性，推薦使用容器技術自動化軟件構建過程、使用 OAM 標準化軟件交付過程、使用 IaC（Infrastructureas Code ，基礎設施即代碼）和 GitOps 等自動化 CI/CD 流水線和運維過程。

（7）安全能力
關注業務的數字化安全，在利用云服務加固業務運行環境的同時，采用安全軟件生命周期開發，使應用符合 ISO27001、PCI/DSS、等級保護等安全要求。安全能力是基礎維度，要求在架構評測中關注，但它不會參與評分。

ACNA-S5：架構持續演進閉環

云原生架構演進是一個不斷迭代的過程，每一次迭代都要經歷從企業戰略、業務訴求到架構設計與實施這樣一個完整的閉環，整體關系（命名為 ACNA-G2）如圖2所示。

圖 2 ACNA-G2：架構持續演進閉環

下面就來詳細介紹架構持續演進閉環的關鍵輸入和實現過程。

1. 關鍵輸入

1）企業戰略視角（ACNA-S1）：包括數字化戰略訴求、技術戰略（特別是云戰略）訴求、企業架構訴求等，建議量化描述創新效率提升百分比、IT 成本降低值、風險成本降低值等。

2）業務發展視角（ACNA-S2）：包括新業務（特別是數字化業務）的技術訴求、BI/AI（商業智能 / 人工智能）訴求、IoT（物聯網）訴求、用戶體驗訴求等，建議量化描述業務迭代速度提升值、用戶體驗改善百分比、業務開發效率提升百分比等。

2. 關鍵過程

1）識別業務痛點和架構債務（ACNA-S5-P1）：明確并量化業務痛點（比如，云上云下一套部署、端到端的可觀測性等）；技術債務依據各企業的具體情況而有所不同，通常包含容器化改造、CI/CD 完善、微服務改造、老應用下線、遺留系統集成方案、非 x86 架構的轉移等。

2）確定架構迭代目標（ACNA-S5-P2）：建議每次迭代不超過 1 年，并通過 OKR（ObjectiveandKey Result，目標與關鍵成果法）的方式，在目標中描述本次迭代的業務目標，在關鍵成果中量化業務價值和技術價值。注意，在確定迭代目標的時候，要充分識別架構升級的利益相關者（Stakeholder）及其價值訴求，避免出現項目很成功但是得不到業務方認同的情況。

3）評估架構風險（ACNA-S5-P3）：風險和價值往往是一對矛盾體，不要因為風險大而不做云原生架構升級，也不要因為迫切升級而忽視風險，建議在風險和價值間獲得平衡。P3 階段的重點是識別風險類別和風險點，它們會根據企業所在行業和企業自身特性的不同而不同。風險類別通常包括組織風險、市場風險、技術風險、設計實現風險、實施落地風險、運維風險、IT 文化風險、財務風險、數據風險、合規風險等。

4）選取云原生技術（ACNA-S5-P4）：P4 階段需要從云原生技術棧中選取在本次迭代中需要采用的云原生技術，也需要把采用該技術可能造成的風險和帶來的價值放在首位考慮。

5）制訂迭代計劃（ACNA-S5-P5）：P5 階段需要充分考慮是否每個里程碑都能夠得到各參與方的認同，一定要避免先閉門開發然后期望產出一個高價值產品的情況，因為像云原生架構升級這樣的項目，需要與各參與方深度合作，且在執行過程中很可能出現改變計劃和目標的情況。

6）架構評審和設計評審（ACNA-S5-P6）：P6 階段作為改變企業整個生產流水線的重要架構升級，需要在技術上進行架構評審和重要設計評審，讓重要設計在各參與方之間得到認同，這也是減少整體風險的重要手段。

7）架構風險控制（ACNA-S5-P7）：在 P3 階段確定了風險點之后，就需要馬上設定這些風險的監控方法和預警閾值，并在架構升級的過程中不斷監控這些閾值的變化情況，做到實時風險評估和預警。整體而言，在整個實施過程中，企業需要建立“識別—監控—評估—預警—改進”的風控閉環。

8）迭代驗收和復盤（ACNA-S5-P8）：為了讓云原生架構升級的下一個迭代取得成功，即使本次迭代已經成功驗收，也需要團隊客觀、深入地對本次迭代的得失進行復盤，特別是在組織能力、項目和產品的管理能力等軟技能。

云原生架構成熟度模型

云原生架構成熟度模型是一種能夠幫助企業找到當前軟件架構與成熟的云原生架構之間的差距，從而在后續的架構優化迭代中進行針對性改善的評估模型。ACNA 參考 CMM（Capability Maturity Model，能力成熟度模型）的定義，從主要的架構維度定義了云原生架構的成熟度模型。我們需要注意到，ACNA 的云原生架構成熟度評估模型不會幫助企業從通用技術架構、應用架構或信息架構的維度進行評估，因此它并沒有幫助實施者梳理架構的核心利益相關者和架構交付合同。同時，評估模型本身也沒有對團隊核心人員技能以及組織的流程、文化和流水線建設進行評估，而是從基于云的現代化應用這一特定的軟件技術架構進行評估。雖然這樣的評估范圍相對較小，但是更專業，可操作性更強。

此外，ACNA 云原生架構成熟度模型的評估對象不是企業或架構實施人員，而是某個具體軟件所采用的架構。因此，對于一個企業而言，可能部分軟件的評估結果是零級（初始級），部分軟件的評估結果是中級（發展級），這完全取決于每個軟件自身的架構情況。

6 個評估維度

ACNA 云原生架構設計共包含 6 個關鍵架構維度（Service + Elasticity + Serverless + Observability + Resilience + Automation，簡寫為 SESORA），在此我們先定義關鍵維度的成熟度級別，如圖 3 所示（命名為 ACNA-T1）。