今天準備整理和分享下阿里云發布的云原生架構白皮書。在今年7月份，由阿里云20+位云原生技術專家共同編撰的《云原生架構白皮書》正式對外發布。據官方介紹，本書涵蓋了云原生架構的產生緣由、阿里云對于云原生架構的定義、目前行業領先的云原生技術、阿里巴巴的云原生架構設計、云原生架構的實踐案例、云原生架構未來發展趨勢等內容。

下載地址：

https://developer.aliyun.com/topic/cn-architecture-paper

阿里云以自身實踐與服務百萬付費用戶的豐富實踐經驗為基礎。從云原生架構定義出發，構建基于實際業務場景的完整云原生架構體系。為企業CTO/CIO提供戰略參考，為廣大研發工程師提供業務洞察，助力云上客戶建立最具業務價值的云原生架構。

整個白皮書分了7個部分的內容，準備一次對每個部分內容做個說明。

為什么需要云原生架構

對于企業的 CIO 而言，原來企業內部 IT 建設以“煙筒”模式比較多，每個部門甚至每個應用都相對獨立，如何管理與分配資源成了難題。大家都基于最底層 IDC 設施獨自向上構建，都需要單獨分配硬件資源，這就造成資源被大量占用且難以被共享。

但是上云之后，由于云廠商提供了統一的IaaS 能力和云服務，大幅提升了企業 IaaS 層的復用程度，CIO 或者 IT 主管自然而然想到 IaaS 以上層的系統也需要被統一，使資源、產品可被不斷復用，從而能夠進一步降低企業運營成本。

所有這些問題都指向一個共同點，那就是云的時代需要新的技術架構，來幫助企業應用能夠更好地利用云計算優勢，充分釋放云計算的技術紅利，讓業務更敏捷、成本更低的同時又可伸縮性更靈活，而這些正好就是云原生架構專注解決的技術點。

具體內容解讀：

對于云計算技術發展這么多年，可以看到類似阿里，華為，騰訊等各大公有云服務廠商推出的IaaS云資源池，提供彈性計算和彈性存儲能力已經被大部分企業所接受。即很多企業已經從自建IDC數據中心，轉變為直接使用公有云提供的彈性計算和存儲服務能力。

而當前企業面臨數字化轉型，面臨更加激烈競爭的市場環境，對企業本身的業務敏捷響應能力要求也更加急迫。那么在這種背景下自然帶來新的問題，就是企業的IT系統如何能夠更加快速敏捷的響應業務需求，能夠實現高效率的從設計開發到云端環境的自動化交付能力，能夠在保證最低成本投入情況下實現IT應用已有的高可用性和彈性擴展能力。

當你在單純的使用IaaS資源池的時候，你開發的IT系統的技術平臺，架構，開發過程方法等云服務商都不需要關心，但是到了敏捷高效的云端交付階段，那么實際對企業自動的IT應用架構，開發過程方法等都會提出更高的要求和需求。

當然，企業在整個應用交付過程中，也存在明確的需求如下：

• 敏捷性的需求：如何更加高效，快捷的進行應用集成交付
• 技術人員需求：企業IT團隊人員應該更加關注業務功能實現而非技術底層
• 可運維需求：IT系統應該可運維，同時方便后續敏捷變更迭代
• 成本需求：在最低成本投入的情況下保證高可用性和高安全性

而以上就是需要云原生架構的關鍵原因，至于云原生架構里面提到的微服務，DevOps，容器云，持續集成和交付等都是為了上述目標達成而努力。

再次重申我原來的一個觀點，即云原生架構的推出，核心目標就是方便企業能夠更加高效敏捷的使用云平臺各類服務能力，同時實現企業IT應用快速向云端持續交付。

云原生架構定義

對于Cloud Native翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)、康威定律(Conways Law)等，以及根據商業能力對公司進行重組。Cloud Native既包含技術(微服務，敏捷基礎設施)，也包含管理(DevOps，持續交付，康威定律，重組等)。

因此云原生是一系列Cloud技術、企業管理方法的集合。在一般用法中，“云原生”是一種構建和運行應用程序的方法，它利用了云計算交付模型的優勢。“云原生”是關于如何創建和部署應用程序，和位置無關。 這意味著應用程序位于云中，而不是傳統數據中心。

在白皮書里面，阿里從技術角度給出了云原生架構的一個定義如下：

從技術的角度，云原生架構是基于云原生技術的一組架構原則和設計模式的集合，旨在將云應用中的非業務代碼部分進行最大化的剝離，從而讓云設施接管應用中原有的大量非功能特性(如彈性、韌性、安全、可觀測性、灰度等)，使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。

簡單來說，云原生架構解決的一個核心問題就是IT系統和應用的開發只需要關注業務功能需求實現，而對于其它的IT基礎設施，技術平臺，消息緩存等各類技術服務等和業務無關的東西都不需要關心，而應該由云平臺來提供。其次，云平臺提供一種方便應用開發和集成的工具和平臺，來實現持續集成和交付。

從上圖可以看到增加了PaaS層內容，對于狹義的PaaS平臺更多的是實現中間件應用資源池，實現應用自動化部署和資源動態擴展能力，即我們常說的APaaS內容，但是到了云原生的PaaS需要進一步實現。

• 數據庫資源池能力，即數據庫即服務
• 各類技術服務能力，類似消息，緩存，通知，日志等
• 持續集成能力，即我們說的DevOps過程支撐能力

各類和業務無關的技術服務都應該由云平臺來提供，即業務代碼的開發人員技能棧中，不再需要掌握文件及其分布式處理技術，不再需要掌握各種復雜的網絡技，通過這種簡化讓業務開發變得更敏捷、更快速。

軟件一旦開發完成，需要在公司內外部各類環境中部署和交付，以將軟件價值交給最終客戶。基于云原生的自動化軟件交付相比較當前的人工軟件交付是一個巨大的進步。以微服務為例，應用微服務化以后，往往被部署到成千上萬個節點上，如果系統不具備高度的自動化能力，任何一次新業務的上線，都會帶來極大的工作量挑戰，嚴重時還會導致業務變更超過上線窗口而不可用。

云原生架構原則

書里面轉了談了云原生架構的原則，在這里我們可以簡單總結下。

即云原生架構的原則就是應該方便企業IT應用持續，高效敏捷，高可用，低成本的向云端環境交付。要實現這個特點，我們可以看到。

• 持續交付：涉及到微服務化，DevOps和容器云能力
• 高可用性：既涉及到應用本書的高可用性設計，也涉及云平臺的高可靠和安全
• 低成本：云平臺具備彈性擴展能力，按需使用

主要架構模式

服務化架構是云時代構建云原生應用的標準架構模式，要求以應用模塊為顆粒度劃分一個軟件，以接口契約(例如 IDL)定義彼此業務關系，以標準協議(HTTP、gRPC 等)確保彼此的互聯互通，結合DDD(領域模型驅動)、TDD(測試驅動開發)、容器化部署提升每個接口的代碼質量和迭代速度。服務化架構的典型模式是微服務和小服務(Mini Service)模式。

其次就是ServiceMesh服務網格，Mesh 化架構是把中間件框架(比如 RPC、緩存、異步消息等)從業務進程中分離，讓中間件 SDK與業務代碼進一步解耦，從而使得中間件升級對業務進程沒有影響，甚至遷移到另外一個平臺的中間件也對業務透明。

也就是我們常說的通過Mesh化實現在徹底去中心化的方式下完成微服務治理工作。

ServerLess無服務器化則是云原生的一個終極期望目標，雖然短期難以實現。但是在無服務器化下，IT應用和軟件的開發才能夠徹底不關心數據庫和應用中間件，不關心技術平臺和開發框架，而只需要關心具體核心業務功能的代碼實現，關心服務究竟如何組合和組裝。

反模式-單體應用硬拆微服務

在反模式部分這點需要特別拿出來強調，即我們在IT應用建設或傳統應用微服務化改造過程中經常犯錯的地方，就是不考慮業務邏輯復雜性和底層數據的耦合性，硬拆分為粒度太細的太多微服務，導致后續的集成和管理工作量劇增。

在書里面提到三個典型例子如下：

小規模軟件的服務拆分：軟件規模不大，團隊人數也少，但是為了微服務而微服務，強行把耦合度高、代碼量少的模塊進行服務化拆分，一次性的發布需要拆分為多個模塊分開發布和維護；

數據依賴：服務雖然拆分為多個，但是這些服務的數據是緊密耦合的，于是讓這些服務共享數據庫，導致數據的變化往往被刪除到多個服務中，造成服務間數據依賴；

性能降低：當耦合性很強的模塊被拆分為多個微服務后，原來的本地調用變成了分布式調用，從而讓響應時間變大了上千倍，導致整個服務鏈路性能急劇下降。

在我們進行系統微服務化的時候務必不要犯類似的錯誤。

云原生主要技術

對于云原生的主要技術，實際上在我前面多篇文章里面都有談到。簡單來說就是容器和容器編排技術，微服務，DevOps，ServiceMesh服務網格，Serverless幾個關鍵點。

下面還是基于書里面的順序脈絡，多以上幾個關鍵技術點展開說明下：

容器技術

容器作為標準化軟件單元，它將應用及其所有依賴項打包，使應用不再受環境限制，在不同計算環境間快速、可靠地運行。

如上圖，容器技術大家都比較清楚了，簡單來說和傳統虛擬機技術最大區別就是共享操作系統內核，但是又能夠通過類似沙箱機制實現資源和進程隔離。由于共享操作系統內核，因此整體整體更加輕量，性能更好，而且資源損耗也最少。

容器編排

一談到容器，一定會談到Kubernetes，對于Kubernetes已經成為容器編排的事實標準，被廣泛用于自動部署，擴展和管理容器化應用。Kubernetes 提供了分布式應用管理的核心能力，其中就包括了動態資源調度，應用自動化部署和托管，集群心跳監測和自動修復，服務發現和負載均衡，集群彈性伸縮等。

也就是我們常說的PaaS平臺中的應用托管和資源動態調度，實際上都需要通過Kubernetes來實現，因此Kubernetes可以理解為容器階段的核心PaaS應用組件。Kubernetes 的控制平面包含四個主要的組件：API Server、Controller、Scheduler 以及 etcd，具體如下圖所示：

微服務

微服務模式將后端單體應用拆分為松耦合的多個子應用，每個子應用負責一組子功能。這些子應用稱為“微服務”，多個“微服務”共同形成了一個物理獨立但邏輯完整的分布式微服務體系。這些微服務相對獨立，通過解耦研發、測試與部署流程，提高整體迭代效率。

此外，微服務模式通過分布式架構將應用水平擴展和冗余部署，從根本上解決了單體應用在拓展性和穩定性上存在的先天架構缺陷。但也要注意到微服務模型也面臨著分布式系統的典型挑戰：如何高效調用遠程方法、如何實現可靠的系統容量預估、如何建立負載均衡體系、如何面向松耦合系統進行集成測試、如何面向大規模復雜關聯應用的部署與運維。

書里面提到了微服務架構的發展演進模式，在這里總結如下：

• 第一代：只實現了單體應用的微服務化拆分
• 第二代：增加了服務注冊和發現中心，實現集成的API接口治理能力
• 第三代：ServiceMesh服務網格
• 第四代：Serverless無服務器化架構

如上圖，實際上從服務網格發展到無服務器化重要有兩點。其一是容器層下沉為FaaS服務統一提供能力，其二就是原來微服務進一步拆分為微邏輯或代碼片段，不再有開發技術框架概念。

主要微服務技術

Apache Dubbo 作為源自阿里巴巴的一款開源高性能 RPC 框架，特性包括基于透明接口的 RPC、智能負載均衡、自動服務注冊和發現、可擴展性高、運行時流量路由與可視化的服務治理。經過數年發展已是國內使用最廣泛的微服務框架并構建了強大的生態體系。

為了鞏固 Dubbo 生態的整體競爭力，2018 年阿里巴巴陸續開源了 Spring-Cloud Alibaba( 分布式應用框架 )、Nacos( 注冊中心 & 配置中心 )、Sentinel( 流控防護 )、Seata( 分布式事務 )、Chaosblade( 故障注入 )，以便讓用戶享受阿里巴巴十年沉淀的微服務體系，獲得簡單易用、高性能、高可用等核心能力。Dubbo 在 v3 中發展 Service Mesh，目前 Dubbo 協議已經被 Envoy 支持，數據層選址、負載均衡和服務治理方面的工作還在繼續，控制層目前在繼續豐富 Istio/Pilot-discovery 中。

Serverless無服務器化

Serverless是一種構建和管理基于微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統架構的不同之處在于，完全由第三方管理，由事件觸發，存在于無狀態(Stateless)、暫存(可能只存在于一次調用的過程中)計算容器內。

我在前面一篇文章里面談到過，在Servverless架構下可以看到沒有復雜的開發框架，也沒有重的中間件容器，只有一個個新粒度的微服務API，微功能的實現，這些實現也不存在傳統的打包和部署動作。也就是說整個軟件的開發過程實現完全的面向服務化，你可以使用第三方已有的服務，你開發完成的微功能也是服務，你呈現給用戶的是多個服務的串聯和組裝。

在這種場景下沒有任何的中間件資源需要你去關心和維護，類似傳統模式下我們可能需要關心和運維我們的數據庫，關心和運維我們的Tomcat容器服務器，我們有復雜的編譯構建，打包部署動作，而這些在無服務器架構模式下都沒有了。體現出現的是函數或事件，而函數本身也是服務。

在本書里面，阿里也給出了一個對比表格如下：

可以看到Servverless架構粒度更加細，更加輕量高效，彈性效率也更高，而且按量計費的模式也更加靈活。對于書里面也給出了Servverless架構的一些適用場景，如下：

• 小程序 /Web/Mobile/API 后端服務
• 大規模批處理任務
• 基于事件驅動架構的在線應用和離線數據處理

所以可以看到當前Servverless架構和應用還是具有很大的局限性，對于企業傳統IT應用的開發并不適合采用Servverless架構進行。

ServiceMesh服務網格

Service Mesh 是分布式應用在微服務軟件架構之上發展起來的新技術，旨在將那些微服務間的連接、安全、流量控制和可觀測等通用功能下沉為平臺基礎設施，實現應用與平臺基礎設施的解耦。這個解耦意味著開發者無需關注微服務相關治理問題而聚焦于業務邏輯本身，提升應用開發效率并加速業務探索和創新。

換句話說，因為大量非功能性從業務進程剝離到另外進程中，Service Mesh 以無侵入的方式實現了應用輕量化，下圖展示了 Service Mesh 的典型架構。

對于ServiceMesh服務網格，可以很方便的和K8s和容器技術進行集成，在鏡像制作階段自動下發邊車代理。因此服務網格我始終任務是在云原生架構和解決方案下，解決微服務治理問題的關鍵技術，必將得到更加廣泛的應用。

DevOps持續集成和交付

對于DevOps我在前面很多文章都談到過，要特別注意的就是DevOps不僅僅是一系列開源的技術和工具的融合，更加重要的是一種持續集成的思維和敏捷的文化。

文化、自動化、度量和共享四個方面相輔相成，獨立而又相互聯系，所以要落實 DevOps 時，要統一考慮。通過 CAMS 也認識到，CI/CD 僅僅是實現 DevOps 中很小的一部分。DevOps 不僅僅是一組工具，更重要是代表了一種文化，一種心智。

對于DevOps詳細內容可以參考我前面文章：

阿里云原生架構設計方法

在該書里面，阿里還給出了一個云原生的4+1架構設計模型ACNA。

ACNA 是一個 「4+1」 的架構設計流程，「4」 代表架構設計的關鍵視角，包括企業戰略視角、業務發展視角、組織能力視角和云原生技術架構視角；「1」 表示云原生架構的架構持續演進閉環。4 個架構視角和一個閉環的關系如下圖。

ACNA 除了是一個架構設計方法，也包含了對云原生架構的評估體系、成熟度衡量體系、行業應用最佳實踐、技術和產品體系、架構原則、實施指導等。

ACNA將云原生化分割成服務化能力(Service)、彈性能力(Elasticity)、無服務器化程度(Serverless)、可觀測行(Observability)、韌性能力(Resilience)、自動化水平(Automation)六個不同維度(SESORA)，每個評估維度設立ASNA-1至ASNA-4 四個不同等級并依次計作0至3分，同時設立零級、基礎級、發展級、成熟級四個不同成熟等級。

云原生架構成熟度模型的提出，對企業云原生化現狀、能力和發展路徑不清晰等問題, 給出評估與優化方向，幫助企業走上數字化轉型“最短路徑”。

對于這個成熟度模型，我們再做下初步的分析如下：

對于自動化能力，在二級就需要具備基于容器的CI/CD能力，到了三級和四級只是更加的自動化和智能化。可以看到DevOps是整原生的一個基礎。

對于可觀測性而言，在二級就需要在資源池和日志監控的基礎上具備完整的APM應用性能監控能力，而到了三級更加強調在一個大規模，分布式的軟硬件環境下的鏈路監控能力和性能度量分析，問題診斷能力，以實現持續的性能優化。

對于無服務化程度這個維度很有意義，即我們希望的就是一些底層資源和基礎設施都應該服務化，其中最難的就是我們常說的數據庫資源的服務化，即表格里面說的有狀態存儲的服務化和云化，到了三級階段這點就必須實現了。

彈性計算和擴展，二級還可以是半自動或半閉環，但是到了三級希望就是全部自動化和閉環，而這個跟數據庫本身的服務化關系緊密，如果數據庫沒有服務化就很難完全做到全自動擴展。

對于服務化能力在二級你只需要具備基礎的微服務治理能力即可，但是到了三級必須實現全面的服務化并建立服務治理管控體系，到了四級即更加強調基于ServiceMesh服務網格的思路來構建分布式，去中心化的微服務治理管控體系。

---

注：對于阿里云原生產品介紹，云原生案例，云原生趨勢分析三個部分的內容，準備后續再單獨開一篇文章來進行說明。

總結

以上是生活随笔為你收集整理的阿里云技术白皮书_对阿里重磅发布的云原生架构白皮书的初步解读的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。