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

下載地址：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主要架構(gòu)模式

服務(wù)化架構(gòu)是云時(shí)代構(gòu)建云原生應(yīng)用的標(biāo)準(zhǔn)架構(gòu)模式，要求以應(yīng)用模塊為顆粒度劃分一個(gè)軟件，以接口契約(例如 IDL)定義彼此業(yè)務(wù)關(guān)系，以標(biāo)準(zhǔn)協(xié)議(HTTP、gRPC 等)確保彼此的互聯(lián)互通，結(jié)合DDD(領(lǐng)域模型驅(qū)動(dòng))、TDD(測(cè)試驅(qū)動(dòng)開發(fā))、容器化部署提升每個(gè)接口的代碼質(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)一步解耦，從而使得中間件升級(jí)對(duì)業(yè)務(wù)進(jìn)程沒有影響，甚至遷移到另外一個(gè)平臺(tái)的中間件也對(duì)業(yè)務(wù)透明。

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

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

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

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

在書里面提到三個(gè)典型例子如下：

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

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

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

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

云原生主要技術(shù)

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

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

容器技術(shù)

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

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

容器編排

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

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

微服務(wù)

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

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

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

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

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

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

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

為了鞏固 Dubbo 生態(tài)的整體競(jìng)爭(zhēng)力，2018 年阿里巴巴陸續(xù)開源了 Spring-Cloud Alibaba( 分布式應(yīng)用框架 )、Nacos( 注冊(cè)中心 & 配置中心 )、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ù)部署級(jí)別而不是服務(wù)器部署級(jí)別來管理你的應(yīng)用部署。它與傳統(tǒng)架構(gòu)的不同之處在于，完全由第三方管理，由事件觸發(fā)，存在于無狀態(tài)(Stateless)、暫存(可能只存在于一次調(diào)用的過程中)計(jì)算容器內(nèi)。

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

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

在本書里面，阿里也給出了一個(gè)對(duì)比表格如下：

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

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

所以可以看到當(dāng)前Servverless架構(gòu)和應(yīng)用還是具有很大的局限性，對(duì)于企業(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ù)間的連接、安全、流量控制和可觀測(cè)等通用功能下沉為平臺(tái)基礎(chǔ)設(shè)施，實(shí)現(xiàn)應(yīng)用與平臺(tái)基礎(chǔ)設(shè)施的解耦。這個(gè)解耦意味著開發(fā)者無需關(guān)注微服務(wù)相關(guān)治理問題而聚焦于業(yè)務(wù)邏輯本身，提升應(yīng)用開發(fā)效率并加速業(yè)務(wù)探索和創(chuàng)新。

換句話說，因?yàn)榇罅糠枪δ苄詮臉I(yè)務(wù)進(jìn)程剝離到另外進(jìn)程中，Service Mesh 以無侵入的方式實(shí)現(xiàn)了應(yīng)用輕量化，下圖展示了 Service Mesh 的典型架構(gòu)。

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

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

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

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

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

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

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

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

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

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

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

對(duì)于這個(gè)成熟度模型，我們?cè)僮鱿鲁醪降姆治鋈缦?#xff1a;

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

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

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

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

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

---

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

總結(jié)

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

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