雲計算 - 阿里雲最佳雲上實踐介紹 卓越架構

相較傳統IDC，雲計算的快速迭代增加了維持良好架構的難度。雲應用需關注穩定性、安全性、性能和成本。阿里雲通過多年經驗，發展了一套名爲"Alibaba Cloud Well-Architected Framework"的優秀架構框架，以協助用戶構建出色的雲架構。

關注【TechLeadCloud】，分享互聯網架構、雲服務技術的全維度知識。作者擁有10+年互聯網服務架構、AI產品研發經驗、團隊管理經驗，同濟本復旦碩，復旦機器人智能實驗室成員，阿里雲認證的資深架構師，項目管理專業人士，上億營收AI產品研發負責人。

一、卓越架構介紹

相比於傳統IDC環境，雲計算的基礎設施和服務在不斷快速迭代和演進，對雲用戶而言，在上雲、用雲、管雲過程中持續維持良好的雲上架構變得極具挑戰。對雲上應用來說，穩定、安全、性能、成本是架構設計中最通用領域的抽象，也是組織層面最需要關注的幾個維度。

基於多年服務各行各業客戶的經驗總結，我們將阿里雲上的架構設計最佳實踐總結爲一系列的方法論和設計原則，形成阿里雲卓越架構框架（Alibaba Cloud Well-Architected Framework），以幫助雲用戶構建良好直至卓越的雲上架構。

阿里雲卓越架構包含以下五個架構最佳實踐支柱：

• 安全合規：識別企業內部、外部的安全要求和監管訴求，在雲環境中針對網絡安全、身份安全、主機安全、數據安全等全方位地進行規劃和實施，同時持續對威脅進行檢測和快速響應。

• 穩定性：無論在何種環境都無法避免單個組件故障的發生。穩定性的目標就是要儘量降低單個組件故障對業務帶來的整體影響。該支柱側重於如何讓業務系統利用現代雲平臺的基礎設施達到高可用，做到面向失敗設計，具備一定容災性的能力。同時把控應用系統的變更流程、部署架構、配置規範等，制定企業應用治理規範，設定應用層面的治理標準。

• 成本優化：通過技術手段瞭解雲資源的成本分佈，幫助企業平衡業務目標與雲上成本，通過充分高效使用雲服務來構建業務應用，儘可能提升雲環境和業務需求之間的契合度，通過持續優化來避免資源浪費，減少不必要的雲上開支並提升運營效率。

• 卓越運營：側重於應用研發態、運行態相關工具與系統的構建和使用，同時也需要考慮組織內如何對應用、工作負載、資源、事件等進行響應，定義日常操作流程，指引企業構建自己的運營模型。

• 高效性能：根據性能監控指標自動觸發彈性伸縮能力，通過雲平臺的資源儲備應對流量高峯，建立完備的可觀測性體系協助定位性能瓶頸。通過性能測試手段建立性能基線，驗證架構設計目標並持續優化。

基於這五大支柱，卓越架構提供相應的設計原則和最佳實踐，以及可落地的方案。同時，卓越架構還提供了免費的架構評估工具和度量模型，來評估當前架構設計與期望值的差距，並提供相應的改進指引和方案。在設計和實施過程中，阿里雲提供了專家服務和認證的合作伙伴，協助架構的演進。

阿里雲卓越架構框架面向的是首席技術官（CTO）、架構師、運維、安全、研發等角色。通過了解卓越架構中定義的最佳實踐和解決方案，組織中的這些職能角色能夠不斷的將應用架構和卓越架構中的最佳實踐進行比較，並不斷進行架構的迭代和改進，從而降低風險、控制成本、提升效率，爲業務的高速發展提供堅實的基礎。

二、安全合規

2.1 概述

安全管理的目的是風險管理，企業選擇將業務遷移到雲上，並不意味着安全風險的降低，也並不表示企業的安全要由雲供應商來承擔。

雲安全的責任模型是共擔的責任模型，基於雲的客戶應用，雲供應商要保障雲平臺自身安全並提供相應的安全能力和產品給雲上的客戶。客戶則負責基於雲供應商提供的服務或原子化能力構建保障應用系統或業務的安全體系。

隨着企業上雲的節奏越來越快，以及網絡攻擊的成本越來越低，安全的建設已經跟不上業務的發展。所以更應該在上雲之初就規劃安全體系的建設和設計，不要等到業務已經運行起來後在考慮安全建設。

2.2 安全責任模型

基於阿里雲的客戶應用，其安全責任由雙方共同承擔：阿里雲要保障雲平臺自身安全並提供安全產品和能力給雲上客戶，客戶負責基於阿里雲服務構建的應用系統的安全。

安全責任模型示意如下圖所示：

阿里雲負責基礎設施（包括跨地域、多可用區部署的數據中心，以及阿里雲骨幹傳輸網絡）和物理設備（包括計算、存儲和網絡設備）的物理和硬件安全，並負責運行在飛天分佈式雲操作系統之上的虛擬化層和雲產品層的安全。同時，阿里雲負責平臺側的身份管理和訪問控制、監控和運營，從而爲客戶提供高可用和高安全的雲服務平臺。

客戶負責以安全的方式配置和使用各種雲上產品，並基於這些雲產品的安全能力以安全可控的方式構建自己的雲上應用和業務，保障雲上安全。阿里雲基於阿里巴巴集團多年攻防技術積累，爲客戶提供雲原生的安全服務，保護客戶的雲上業務和應用系統。

2.3 雲平臺數據安全和隱私保障體系

數據安全是爲了推動數據可以被高效流動而核心打造的是一套信任機制。不碰用戶數據是阿里雲的紅線，也是最低要求。阿里雲數據安全體系的核心是賦予數據權利和義務，讓其所有者、共享者、監管者可以基於這些信任，釋放數據的價值，這是阿里雲數據安全的理念。

阿里雲已經完整覆蓋了基於地域和可用區概念，構建的基礎設施和平臺層的數據風險收斂能力。平臺之上，圍繞安全、合規、隱私三大命題，阿里云爲用戶提供原生的、高度自動化、高透明度的保護能力，致力構建值得信任的安全計算環境，促進數據在被保護的狀態下流動起來、使用起來。信任的基礎是明確其中的權利和義務。在分類分級的前提下，我們對數據的所有權、歸屬權、使用規範、刪除權等做了細粒度約定，並通過法律法規、資質認證等多種手段保障權利和義務的履行。因此，阿里雲也是亞太區擁有最全合規和隱私資質的雲廠商。

2.4 規劃和設計

安全是需要設計和規劃的，應在構建基於雲或本地數據中心的同時，建設安全系統和相關控制措施，建立配套安全管理流程和機制，建立安全意識管理體系等。並將技術控制措施、管理流程、人員組織配套的融入雲基礎設施的構建、業務開發，應用上線和日常運營當中。

三、穩定性

系統穩定性是指系統在運行過程中面對各種非預期事件影響下能夠持續提供可靠服務的能力，是系統建設的重中之重。但隨着各公司業務範圍的擴展和軟件系統架構持續迭代升級，系統的複雜度隨之增加，面對更多的非預期事件風險，如各類軟硬件故障、錯誤的變更、突發流量，甚至到光纖挖斷、自然災害等引起的整個機房不可用情況，如何保障系統穩定性具有很大挑戰。

一個穩定的分佈式系統需要能夠快速適應變化，及時發現和解決問題，並且能夠保持系統的一致性和可靠性。穩定性通常包含系統可用性、可靠性、可觀測性、可運維性、可擴展性、可維護性等。使用雲計算平臺服務可以更好的構建系統穩定性，例如雲計算平臺可以根據系統的實際需求，動態分配和釋放計算資源，使得系統更容易擴展，降低系統負載壓力，從而提高系統的可擴展性。再者雲計算平臺會提供冗餘存儲和備份能力，避免系統因爲硬件故障或其他原因導致的停機或數據丟失。這種備份機制可以提高系統的可靠性。

3.1責任共擔模型

阿里雲平臺提供高可用的基礎設施，並提供應用穩定性相關工具體系。用戶可以基於阿里雲提供的產品及本框架中定義的最佳實踐入手，來建設雲上應用的穩定性。

在分佈式系統中，需要考慮的穩定性問題比較複雜，貫穿軟件系統設計態、研發態、運維態、運行態，覆蓋從IaaS、PaaS到上層SaaS系統，所有這些都可能會影響系統的穩定性。爲了確保系統能夠持續穩定地工作，建議遵循以下設計原則。

3.2面向失敗的架構設計原則

衆所周知，系統異常事件是不可避免的，如網絡延遲、硬件故障、軟件錯誤、突峯流量等，建議在系統設計階段就要從這些異常事件引起的系統執行“失敗”出發，提供冗餘、隔離、降級、彈性等能力，旨在確保系統的高可用性和高可靠性，以應對不可避免的故障和意外發生。

3.3面向精細的運維管控原則

由於業務的擴展和系統服務進一步拆分，分佈式系統的複雜度劇增。再加上產品迭代加快，版本繁多，同時某些業務對實時性有較高要求，運維的不確定性和複雜性大幅增加。建議通過精細化的管理和可觀測手段，如版本控制、灰度發佈、監控告警、自動巡檢等手段，旨在提高運維效率、確定性和穩定性。

3.4面向風險的應急快恢原則

在一些場景下，即使設計了各種技術手段去提高系統的冗餘、保持業務的高可用，但還是避免不了生產系統故障的發生，所以需要面對故障建立一個高效的故障應急流程機制和穩定的技術平臺，實現故障風險實時發現、應急團隊有效協同、處理過程準確記錄、故障快速止損和恢復以及後續故障覆盤，旨在提高故障應急效率，減小故障影響，降低類似故障的再次發生，提升系統整體高可用性。

基於穩定性支柱設計原則，整體穩定性設計方案可參考如下：

3.5 架構設計原則

軟件系統從所有的功能都在一個應用程序內運行的單體應用架構，到不同的功能模塊分別部署在不同的服務器上的傳統分佈式應用架構，再到服務細分通過輕量級的通信機制進行互相調用的微服務架構，到現在將雲計算、容器化、微服務架構等技術結合起來的雲原生架構。在軟件系統架構演進中不變的是系統的基本屬性，包含存儲、計算和網絡，變的是存儲、計算和網絡的實現方式和規模，往大規模、高性能、高可靠、易擴展等方向迭代演進，所以對架構穩定性提出了更高的要求。

系統可預見的穩定性風險包含軟硬件故障和不可預期的流量，小到線程級風險，大到地域級災難，從此出發可通過容災、容錯、容量三方面建立系統架構穩定性。

變更設計原則

在企業的運維管理與運行過程中，就會有變更產生。變更是指添加、修改或刪除任何可能對服務產生直接或間接影響的內容。當變更失敗時可能會帶來嚴重後果：業務中斷、客戶輿情等等一系列問題。爲了降低變更帶來的業務風險，需要遵循變更設計原則：可灰度、可監控、可回滾。

應急響應機制

應急響應機制的關鍵點在於事件發生後，有標準的操作流程和動作。阿里巴巴在過去十幾年的安全生產過程中，沉澱了一套故障應急響應機制，簡稱應急響應1-5-10。是指在1分鐘內發現故障，5分鐘內組織相關人員進行初步排查，10分鐘內開展故障恢復和處理工作。企業在設計應急響應機制時，可以參考該方式明確響應期間的標準動作和流程，確保在事件發生時，相關干係人都能夠明確自身職責和所需要採取的措施。

演練常態化

故障演練提供了一種端到端的測試理念與工具框架，本質是通過主動引入故障來充分驗證軟件質量的脆弱性。從提前發現系統風險、提升測試質量、完善風險預案、加強監控告警、提升故障應急效率等方面做到故障發生前有效預防，故障發生時及時應對，故障恢復後迴歸驗證。基於故障本身打造分佈式系統韌性，持續提升軟件質量，增強團隊對軟件生產運行的信心。故障演練可分爲方案驗證的容災演練、穩定性驗收的紅藍攻防，以及故障應急驗證的突襲演練。

四、成本優化

雲計算能夠爲企業IT基礎設施帶來敏捷性和效率提升，隨着雲上業務體量和業務場景複雜度不斷增加，企業在雲上資源配置不合理或配置過渡的現象普遍存在。與此同時，企業在多組織成本管理效率、成本可控、平衡業務目標與成本等方面均面臨巨大挑戰。

成本優化支柱提供了雲上成本管理及優化的設計原則和最佳實踐，幫助企業高效地使用雲服務來構建業務應用，減少不必要的開支並提升運營效率，讓企業在雲上更具經濟效益。成本優化並不意味着只追求低價格，在過程中需要進行必要的權衡取捨，關鍵在於提升成本管理效率、合理選擇雲資源及避免成本浪費，並在業務目標、安全合規、穩定性等方面與成本之間達成平衡。

成本優化貫穿企業整個上雲用雲全生命週期，本支柱從雲財務規劃及管理、成本可視化及分攤、成本監控、雲服務及計費方式選擇、應用負載成本優化等方面進行闡述，爲企業在雲上以最優成本達成業務目標提供深入指導。
“雲成本管理與優化”不是一蹴而就的項目，是一個涵蓋企業上雲用雲全生命週期，關係到企業內部管理機制的體系化工程，是一個反覆迭代和持續運營的過程。

根據FinOps官網《What is FinOps》的描述，“FinOps 是一種不斷髮展的雲財務管理學科和文化實踐，通過幫助工程師、財務、技術和業務團隊協作制定數據驅動的支出決策，使組織能夠獲得最大的業務價值。”

FinOps 是“Finance”和“DevOps”的合成詞，強調業務團隊與工程師團隊之間的溝通和協作。

FinOps通過Inform、Optimize、Operate三個生命週期階段實現雲成本的可視、優化與持續運營，鼓勵實踐6大FinOps原則，將衆多FinOps能力劃分爲6大領域，最終通過Crawl（爬行）、Walk（行走）、Run（奔跑）3個程度來衡量實踐的成熟度。

“FinOps”在行業中常見的別名有 “雲成本管理（cloud cost management）”、“雲成本優化（cloud cost optimization） ”、 “雲財務管理（cloud financial management）”等。

阿里云云成本管理與優化框架

阿里雲在FinOps核心理念基礎上，融合自身實踐經驗，提出更加細化落地的本土化“雲上成本管理實施框架”，供企業客戶參考實施。

雲上成本管理貫穿上雲用雲全生命週期

從企業上雲及用雲的歷程看，大致可以分爲用雲計劃、用雲執行、監控分析、成本優化等階段，成本管理貫穿各個階段，每個階段的關注點各有不同。

用雲計劃階段：場景包括企業首次上雲、增量上雲、存量復購。

用雲執行階段：場景包括採購執行、用雲管雲規則執行（包括財務規則設置、資源配額設置等）、商務履約執行（包括對賬、充值、開票等）。在用雲執行階段，從財務管理和資源管理兩個視角做好成本管理。

監控分析階段：對應FinOps的Inform階段，主要解決成本分攤與成本可視化問題。

成本優化階段：對應FinOps的Optimize階段，主要通過計費方式優化、資源使用優化和架構優化來落地執行。

持續運營：雲上成本管理是一個反覆迭代和持續運營的過程，企業應持續循環以上四個階段，形成長效運作機制，使雲上成本可以有效管控、持續優化。

五、卓越運營

雲計算能夠爲企業IT基礎設施帶來敏捷性和效率提升，隨着雲上業務體量和業務場景複雜度不斷增加，企業在雲上資源配置不合理或配置過渡的現象普遍存在。與此同時，企業在多組織成本管理效率、成本可控、平衡業務目標與成本等方面均面臨巨大挑戰。

成本優化支柱提供了雲上成本管理及優化的設計原則和最佳實踐，幫助企業高效地使用雲服務來構建業務應用，減少不必要的開支並提升運營效率，讓企業在雲上更具經濟效益。成本優化並不意味着只追求低價格，在過程中需要進行必要的權衡取捨，關鍵在於提升成本管理效率、合理選擇雲資源及避免成本浪費，並在業務目標、安全合規、穩定性等方面與成本之間達成平衡。

成本優化貫穿企業整個上雲用雲全生命週期，本支柱從雲財務規劃及管理、成本可視化及分攤、成本監控、雲服務及計費方式選擇、應用負載成本優化等方面進行闡述，爲企業在雲上以最優成本達成業務目標提供深入指導。

構建運營模型

運營模型是指組織和業務團隊使用雲計算平臺支持業務的過程中，根據業務需求、企業架構、組織文化、現有的技術水平和工具等構建的模型。每個企業的運營模型都是獨特的，本文將介紹四種常見的運營模型以供參考。

構建運營模型的目的是爲了實現更高效、更靈活的基於雲計算平臺的管理和運營。具體來說，構建運營模型的目的包括以下幾個方面：

1. 實現快速部署和擴容：通過雲計算平臺構建標準的發佈工程，實現快讀部署和擴容，提高服務的響應速度和靈活性。

2. 提升決策的有效性：通過構建可觀測系統，從而以高度統籌與整合的方式將業務數字化操作所產生的可觀測數據進行反饋並創造決策循環，提高組織決策有效性。

3. 優化資源配置和利用效率：通過對雲計算平臺中各種資源（如計算、存儲、網絡等）的實時監控，配合一些優化措施，能夠提高資源的利用效率，降低雲服務的成本。

4. 提高業務的穩定性和可靠性：基於雲平臺提供的監測和專業技術能力，可以協助企業提升故障響應速度，縮短故障診斷時間，提高業務的穩定性和可靠性。

雲卓越中心CCoE運營模型

雲卓越中心CCoE是驅動雲轉型的最佳實踐。企業通常至少有一個雲管理團隊，或由相關負責人組建一個雲卓越中心（Cloud Center of Excellence，簡稱CCoE）負責規劃和對接上雲的整體方案，包括在組織層面確認上雲的整體計劃、步驟，以及收集組織的具體需求。

雲卓越中心運營模型組織通常包括：

• 企業管理層：企業管理層需要明確雲在公司的戰略地位以及各個團隊應該如何使用雲。

• 雲卓越中心：該團隊可以是虛擬的組織，設計雲服務的供給模式和管理體系，並提供相應的技術準備。其中的成員包括：

  • 架構師和專業技術人員，負責上雲架構設計和業務上雲遷移工作；

  • 安全、合規等領域專家，負責設計企業IT治理方案、預估風險和制定治理規則；

  • 財務專家，負責制定財務的管理流程和成本分攤規則。

• 雲管理團隊：在企業業務全面上雲之後，持續優化雲上架構，爲新業務提供雲上環境。建立企業雲上運維體系，搭建運維平臺，以及通過自動化運維的方式，對雲上環境進行持續治理和管理。根據新業務需求，分配所需雲資源和所需權限，並對資源進行初始化配置後交付。應用團隊只需用雲，無需關注基礎設施搭建。

六、高效性能

性能度量了系統在單元環境內承載工作負載的效率，系統性能通常可以由 QPS、併發和RT（響應時間）等典型指標來衡量。在傳統 IT 環境中，系統的容量評估和規劃是系統設計的重要環節，通常會基於系統對峯值負載表現出來的性能承載能力來給系統選擇合適的節點數量規劃，在雙活系統中考慮到 failover 會需要給單節點設計更大的冗餘，對於過載的場景也需要有過載控制相關功能模塊來避免整體宕機。這個設計的環節是相對固定和長週期的工作，因爲往往節點的部署和交付都是相對長週期的工作。

在雲的基礎設施環境中，靈活的彈性功能很好地解決了傳統 IT 環境中的痛點，將容量評估和線上擴容變得相對簡單，同時也爲高性能設計帶來了更多選項和複雜性。除了設計層面的容量評估和靈活彈性，實現層面的性能測試、性能監控和性能優化之外，充分發揮雲產品因爲技術迭代帶來的性能紅利同樣成爲高性能系統需要考量的重要因素。本章節會全面描述基於雲基礎設施的高性能系統設計、實施和優化等環節，包括如下主要內容：

• 高性能架構設計：包括高性能架構常見設計準則、業務適應規格和類型、可伸縮和可擴展、性能層面部分架構設計最佳實踐和挑戰和注意事項等內容。

• 性能測試：包括性能測試介紹、性能測試的適用場景和性能測試最佳實踐等內容。

• 性能監控：包括爲什麼需要性能監控、什麼是性能監控和性能監控最佳實踐等內容。

• 常見性能優化手段：包括彈性計算優化、網絡優化、數據庫優化和架構優化等內容。

性能是系統的一個重要指標，如果性能無法達到用戶預期，會造成大量的用戶流失。而很多時候性能問題和系統最初的架構設計相關（當然系統架構是可以持續演進和迭代的），任何架構設計都必須考慮可能帶來的性能問題。

因爲性能問題幾乎無處不在，所以優化性能的手段也非常多，從用戶瀏覽器到數據庫，影響用戶請求的所有應用相關環節都可以進行性能優化。隨着雲計算在IT支出佔比的不斷提升，越來越多的用戶核心業務系統跑在雲上，雲的架構設計和選型也對性能非常重要。基於雲的特點，雲架構中有關性能設計的方面，有以下注意事項和基本原則：

有效的雲資源選型

作爲一個軟件系統，應用層面有很多性能優化和架構設計的考慮點，但是一個系統的性能基石其實是底層計算和存儲資源的性能，這個是原子能力。當系統使用的計算和存儲資源性能越好，越有利於上層應用進行整體性能調優和優化，所謂“工欲善其事必先利其器”。

在大規模分佈式系統不斷髮展的趨勢下，計算場景和對算力的需求越來越豐富。比如在很多通用計算的場景下，最關心的其實是計算集羣的規模，對計算節點本身的單節點能力並沒有高要求（比如短時大量計算請求的峯值場景）；而在現在火熱的AI模型訓練場景下，則必須使用類似A100 GPU計算卡的裸金屬機器來快速滿足大規模AI訓練的要求。同時雲資源大都是按可用區維度進行部署的，一旦選擇可用區進行大量資源部署後遷移和改造成本會很高，因此選擇有效的可用區也非常重要。在選擇可用區時，需要綜合考慮延時，庫存，資源類型等因素。

即在場景越來越豐富的情況下，雲資源的資源選型從一開始就能很大程度影響最終的系統性能。因此從雲架構的實際角度來看，雲資源的選型非常重要，具體選型的原則可以參考評估合適的雲服務。

可伸縮、可擴展的雲架構

大型系統需要面對大量用戶的高併發訪問和存儲海量數據，不可能只用固定數量的服務器來處理全部用戶請求，這樣既不經濟，也沒有辦法有效應對靈活的業務訪問。通過集羣的方式將計算資源和存儲資源等組成一個整體提供服務，在需要的場景下，可以及時通過調整計算和存儲資源來緩解高併發帶來的計算和存儲壓力，從而實現在訪問峯值場景下可以向用戶有效提供穩定的服務，在訪問低谷的時期又可以釋放不必要的資源或保持系統的低位運行來節省IT支出。

對於一個嚴格設計的系統來說，存在不同功能的計算節點，如應用服務器集羣、緩存服務器集羣、數據庫集羣等。應用服務器集羣如果是無狀態的場景下（數據保存在另外的節點上），那麼伸縮機器是比較簡單直接的；對於緩存服務器集羣來說，新加入的計算節點則需要進行相關緩存刷新或預熱等來保證數據的可訪問性；對於數據庫來說，實時的伸縮是比較困難的，需要提前做好數據備份和數據同步等方式，輔助路由手段等提升數據庫集羣的整體可用性和性能。

雲上架構設計的部分最佳實踐

在雲計算高度發展的今天，公共雲上已經運行了大量的核心業務系統。這些業務系統從設計到邏輯等方面都考慮了雲本身帶來的便利性，同時公共雲的發展也不斷吸取這些業務系統的需求來不斷優化自身的產品設計，並推出更適配業務需求的雲產品。因此在一些比較有特點的場景下形成了最佳實踐，藉助這些最佳實踐預期可以有效提升雲架構設計初期的架構設計能力，提升系統整體性能，具體可以參考每個雲產品文檔中的最佳實踐相關內容，以及阿里雲最佳實踐頻道。

關注架構設計的注意事項

性能並不需要盲目地追求極致，在高性能架構設計的過程中，還需要關注性能設計中的一些挑戰和注意事項，避免引起不必要的資源浪費和研發投入。具體可以參考挑戰和注意事項。

關注【TechLeadCloud】，分享互聯網架構、雲服務技術的全維度知識。作者擁有10+年互聯網服務架構、AI產品研發經驗、團隊管理經驗，同濟本復旦碩，復旦機器人智能實驗室成員，阿里雲認證的資深架構師，項目管理專業人士，上億營收AI產品研發負責人。
如有幫助，請多關注
TeahLead KrisChang，10+年的互聯網和人工智能從業經驗，10年+技術和業務團隊管理經驗，同濟軟件工程本科，復旦工程管理碩士，阿里雲認證雲服務資深架構師，上億營收AI產品業務負責人。