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

下載地址：

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

阿里云以自身實踐與服務(wù)百萬付費用戶的豐富實踐經(jīng)驗為基礎(chǔ)。從云原生架構(gòu)定義出發(fā)，構(gòu)建基于實際業(yè)務(wù)場景的完整云原生架構(gòu)體系。為企業(yè)CTO/CIO提供戰(zhàn)略參考，為廣大研發(fā)工程師提供業(yè)務(wù)洞察，助力云上客戶建立最具業(yè)務(wù)價值的云原生架構(gòu)。

整個白皮書分了7個部分的內(nèi)容，準(zhǔn)備一次對每個部分內(nèi)容做個說明。

為什么需要云原生架構(gòu)

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

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

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

具體內(nèi)容解讀：

對于云計算技術(shù)發(fā)展這么多年，可以看到類似阿里，華為，騰訊等各大公有云服務(wù)廠商推出的IaaS云資源池，提供彈性計算和彈性存儲能力已經(jīng)被大部分企業(yè)所接受。即很多企業(yè)已經(jīng)從自建IDC數(shù)據(jù)中心，轉(zhuǎn)變?yōu)橹苯邮褂霉性铺峁┑膹椥杂嬎愫痛鎯Ψ?wù)能力。

而當(dāng)前企業(yè)面臨數(shù)字化轉(zhuǎn)型，面臨更加激烈競爭的市場環(huán)境，對企業(yè)本身的業(yè)務(wù)敏捷響應(yīng)能力要求也更加急迫。那么在這種背景下自然帶來新的問題，就是企業(yè)的IT系統(tǒng)如何能夠更加快速敏捷的響應(yīng)業(yè)務(wù)需求，能夠?qū)崿F(xiàn)高效率的從設(shè)計開發(fā)到云端環(huán)境的自動化交付能力，能夠在保證最低成本投入情況下實現(xiàn)IT應(yīng)用已有的高可用性和彈性擴展能力。

當(dāng)你在單純的使用IaaS資源池的時候，你開發(fā)的IT系統(tǒng)的技術(shù)平臺，架構(gòu)，開發(fā)過程方法等云服務(wù)商都不需要關(guān)心，但是到了敏捷高效的云端交付階段，那么實際對企業(yè)自動的IT應(yīng)用架構(gòu)，開發(fā)過程方法等都會提出更高的要求和需求。

當(dāng)然，企業(yè)在整個應(yīng)用交付過程中，也存在明確的需求如下：

• 敏捷性的需求：如何更加高效，快捷的進(jìn)行應(yīng)用集成交付
• 技術(shù)人員需求：企業(yè)IT團(tuán)隊人員應(yīng)該更加關(guān)注業(yè)務(wù)功能實現(xiàn)而非技術(shù)底層
• 可運維需求：IT系統(tǒng)應(yīng)該可運維，同時方便后續(xù)敏捷變更迭代
• 成本需求：在最低成本投入的情況下保證高可用性和高安全性

而以上就是需要云原生架構(gòu)的關(guān)鍵原因，至于云原生架構(gòu)里面提到的微服務(wù)，DevOps，容器云，持續(xù)集成和交付等都是為了上述目標(biāo)達(dá)成而努力。

再次重申我原來的一個觀點，即云原生架構(gòu)的推出，核心目標(biāo)就是方便企業(yè)能夠更加高效敏捷的使用云平臺各類服務(wù)能力，同時實現(xiàn)企業(yè)IT應(yīng)用快速向云端持續(xù)交付。

云原生架構(gòu)定義

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

因此云原生是一系列Cloud技術(shù)、企業(yè)管理方法的集合。在一般用法中，“云原生”是一種構(gòu)建和運行應(yīng)用程序的方法，它利用了云計算交付模型的優(yōu)勢。“云原生”是關(guān)于如何創(chuàng)建和部署應(yīng)用程序，和位置無關(guān)。 這意味著應(yīng)用程序位于云中，而不是傳統(tǒng)數(shù)據(jù)中心。

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

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

簡單來說，云原生架構(gòu)解決的一個核心問題就是IT系統(tǒng)和應(yīng)用的開發(fā)只需要關(guān)注業(yè)務(wù)功能需求實現(xiàn)，而對于其它的IT基礎(chǔ)設(shè)施，技術(shù)平臺，消息緩存等各類技術(shù)服務(wù)等和業(yè)務(wù)無關(guān)的東西都不需要關(guān)心，而應(yīng)該由云平臺來提供。其次，云平臺提供一種方便應(yīng)用開發(fā)和集成的工具和平臺，來實現(xiàn)持續(xù)集成和交付。

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

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

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

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

云原生架構(gòu)原則

書里面轉(zhuǎn)了談了云原生架構(gòu)的原則，在這里我們可以簡單總結(jié)下。

即云原生架構(gòu)的原則就是應(yīng)該方便企業(yè)IT應(yīng)用持續(xù)，高效敏捷，高可用，低成本的向云端環(huán)境交付。要實現(xiàn)這個特點，我們可以看到。

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

主要架構(gòu)模式

服務(wù)化架構(gòu)是云時代構(gòu)建云原生應(yīng)用的標(biāo)準(zhǔn)架構(gòu)模式，要求以應(yīng)用模塊為顆粒度劃分一個軟件，以接口契約(例如 IDL)定義彼此業(yè)務(wù)關(guān)系，以標(biāo)準(zhǔn)協(xié)議(HTTP、gRPC 等)確保彼此的互聯(lián)互通，結(jié)合DDD(領(lǐng)域模型驅(qū)動)、TDD(測試驅(qū)動開發(fā))、容器化部署提升每個接口的代碼質(zhì)量和迭代速度。服務(wù)化架構(gòu)的典型模式是微服務(wù)和小服務(wù)(Mini Service)模式。

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

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

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

反模式-單體應(yīng)用硬拆微服務(wù)

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

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

小規(guī)模軟件的服務(wù)拆分：軟件規(guī)模不大，團(tuán)隊人數(shù)也少，但是為了微服務(wù)而微服務(wù)，強行把耦合度高、代碼量少的模塊進(jìn)行服務(wù)化拆分，一次性的發(fā)布需要拆分為多個模塊分開發(fā)布和維護(hù)；

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

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

在我們進(jìn)行系統(tǒng)微服務(wù)化的時候務(wù)必不要犯類似的錯誤。

云原生主要技術(shù)

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

下面還是基于書里面的順序脈絡(luò)，多以上幾個關(guān)鍵技術(shù)點展開說明下：

容器技術(shù)

容器作為標(biāo)準(zhǔn)化軟件單元，它將應(yīng)用及其所有依賴項打包，使應(yīng)用不再受環(huán)境限制，在不同計算環(huán)境間快速、可靠地運行。

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

容器編排

一談到容器，一定會談到Kubernetes，對于Kubernetes已經(jīng)成為容器編排的事實標(biāo)準(zhǔn)，被廣泛用于自動部署，擴展和管理容器化應(yīng)用。Kubernetes 提供了分布式應(yīng)用管理的核心能力，其中就包括了動態(tài)資源調(diào)度，應(yīng)用自動化部署和托管，集群心跳監(jiān)測和自動修復(fù)，服務(wù)發(fā)現(xiàn)和負(fù)載均衡，集群彈性伸縮等。

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

微服務(wù)

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

此外，微服務(wù)模式通過分布式架構(gòu)將應(yīng)用水平擴展和冗余部署，從根本上解決了單體應(yīng)用在拓展性和穩(wěn)定性上存在的先天架構(gòu)缺陷。但也要注意到微服務(wù)模型也面臨著分布式系統(tǒng)的典型挑戰(zhàn)：如何高效調(diào)用遠(yuǎn)程方法、如何實現(xiàn)可靠的系統(tǒng)容量預(yù)估、如何建立負(fù)載均衡體系、如何面向松耦合系統(tǒng)進(jìn)行集成測試、如何面向大規(guī)模復(fù)雜關(guān)聯(lián)應(yīng)用的部署與運維。

書里面提到了微服務(wù)架構(gòu)的發(fā)展演進(jìn)模式，在這里總結(jié)如下：

• 第一代：只實現(xiàn)了單體應(yīng)用的微服務(wù)化拆分
• 第二代：增加了服務(wù)注冊和發(fā)現(xiàn)中心，實現(xiàn)集成的API接口治理能力
• 第三代：ServiceMesh服務(wù)網(wǎng)格
• 第四代：Serverless無服務(wù)器化架構(gòu)

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

主要微服務(wù)技術(shù)

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

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

Serverless無服務(wù)器化

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

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

在這種場景下沒有任何的中間件資源需要你去關(guān)心和維護(hù)，類似傳統(tǒng)模式下我們可能需要關(guān)心和運維我們的數(shù)據(jù)庫，關(guān)心和運維我們的Tomcat容器服務(wù)器，我們有復(fù)雜的編譯構(gòu)建，打包部署動作，而這些在無服務(wù)器架構(gòu)模式下都沒有了。體現(xiàn)出現(xiàn)的是函數(shù)或事件，而函數(shù)本身也是服務(wù)。

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

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

• 小程序 /Web/Mobile/API 后端服務(wù)
• 大規(guī)模批處理任務(wù)
• 基于事件驅(qū)動架構(gòu)的在線應(yīng)用和離線數(shù)據(jù)處理

所以可以看到當(dāng)前Servverless架構(gòu)和應(yīng)用還是具有很大的局限性，對于企業(yè)傳統(tǒng)IT應(yīng)用的開發(fā)并不適合采用Servverless架構(gòu)進(jìn)行。

ServiceMesh服務(wù)網(wǎng)格

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

換句話說，因為大量非功能性從業(yè)務(wù)進(jìn)程剝離到另外進(jìn)程中，Service Mesh 以無侵入的方式實現(xiàn)了應(yīng)用輕量化，下圖展示了 Service Mesh 的典型架構(gòu)。

對于ServiceMesh服務(wù)網(wǎng)格，可以很方便的和K8s和容器技術(shù)進(jìn)行集成，在鏡像制作階段自動下發(fā)邊車代理。因此服務(wù)網(wǎng)格我始終任務(wù)是在云原生架構(gòu)和解決方案下，解決微服務(wù)治理問題的關(guān)鍵技術(shù)，必將得到更加廣泛的應(yīng)用。

DevOps持續(xù)集成和交付

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

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

對于DevOps詳細(xì)內(nèi)容可以參考我前面文章：

阿里云原生架構(gòu)設(shè)計方法

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

ACNA 是一個 「4+1」 的架構(gòu)設(shè)計流程，「4」 代表架構(gòu)設(shè)計的關(guān)鍵視角，包括企業(yè)戰(zhàn)略視角、業(yè)務(wù)發(fā)展視角、組織能力視角和云原生技術(shù)架構(gòu)視角；「1」 表示云原生架構(gòu)的架構(gòu)持續(xù)演進(jìn)閉環(huán)。4 個架構(gòu)視角和一個閉環(huán)的關(guān)系如下圖。

ACNA 除了是一個架構(gòu)設(shè)計方法，也包含了對云原生架構(gòu)的評估體系、成熟度衡量體系、行業(yè)應(yīng)用最佳實踐、技術(shù)和產(chǎn)品體系、架構(gòu)原則、實施指導(dǎo)等。

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

云原生架構(gòu)成熟度模型的提出，對企業(yè)云原生化現(xiàn)狀、能力和發(fā)展路徑不清晰等問題, 給出評估與優(yōu)化方向，幫助企業(yè)走上數(shù)字化轉(zhuǎn)型“最短路徑”。

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

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

對于可觀測性而言，在二級就需要在資源池和日志監(jiān)控的基礎(chǔ)上具備完整的APM應(yīng)用性能監(jiān)控能力，而到了三級更加強調(diào)在一個大規(guī)模，分布式的軟硬件環(huán)境下的鏈路監(jiān)控能力和性能度量分析，問題診斷能力，以實現(xiàn)持續(xù)的性能優(yōu)化。

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

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

對于服務(wù)化能力在二級你只需要具備基礎(chǔ)的微服務(wù)治理能力即可，但是到了三級必須實現(xiàn)全面的服務(wù)化并建立服務(wù)治理管控體系，到了四級即更加強調(diào)基于ServiceMesh服務(wù)網(wǎng)格的思路來構(gòu)建分布式，去中心化的微服務(wù)治理管控體系。

---

注：對于阿里云原生產(chǎn)品介紹，云原生案例，云原生趨勢分析三個部分的內(nèi)容，準(zhǔn)備后續(xù)再單獨開一篇文章來進(jìn)行說明。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。