系列文章目錄

系統(tǒng)架構(gòu)設計高級技能 · 軟件架構(gòu)概念、架構(gòu)風格、ABSD、架構(gòu)復用、DSSA（一）【系統(tǒng)架構(gòu)設計師】
系統(tǒng)架構(gòu)設計高級技能 · 系統(tǒng)質(zhì)量屬性與架構(gòu)評估（二）【系統(tǒng)架構(gòu)設計師】
系統(tǒng)架構(gòu)設計高級技能 · 軟件可靠性分析與設計（三）【系統(tǒng)架構(gòu)設計師】

現(xiàn)在的一切都是為將來的夢想編織翅膀，讓夢想在現(xiàn)實中展翅高飛。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

一、 云原生架構(gòu)內(nèi)涵

1.1 定義

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

1.2 特點

基于云原生架構(gòu)的應用特點包括：

（1） 代碼結(jié)構(gòu)發(fā)生巨大變化：不再需要掌握文件及其分布式處理技術(shù)，不再需要掌握各種復雜的網(wǎng)絡技術(shù)，簡化讓業(yè)務開發(fā)變得更敏捷、更快捷。
（2） 非功能特性大量委托給云原生架構(gòu)來解決：比如高可用能力、容災能力、安全特性、可運維性、易用性、可測試性、灰度發(fā)布能力等。
（3） 高度自動化的軟件交付：基于云原生的自動化軟件交付可以把應用自動化部署到成千上萬的節(jié)點上。

1.3 云原生的原則

云原生具有以下原則：

（1） 服務化原則：通過服務化架構(gòu)把不同生命周期的模塊分離出來，分別進行業(yè)務迭代。
（2） 彈性原則：彈性是指系統(tǒng)的部署規(guī)?？梢噪S著業(yè)務量的變化而自動伸縮。
（3） 可觀測原則：通過日志、鏈路跟蹤和度量等手段，使得多次服務調(diào)用的耗時、返回值和參數(shù)都清晰可見。
（4） 韌性原則：軟件所依賴的軟硬件組件出現(xiàn)各種異常時，軟件表現(xiàn)出來的抵御能力。
（5） 所有過程自動化原則：讓自動化工具理解交付目標和環(huán)境差異，實現(xiàn)整個軟件交付和運維的自動化。
（6） 零信任原則：不應該信任網(wǎng)絡內(nèi)部和外部的任何人/設備/系統(tǒng)，需要基于認證和授權(quán)重構(gòu)訪問控制的信任基礎。
（7） 架構(gòu)持續(xù)演進原則：架構(gòu)具備持續(xù)演進的能力。

1.4 主要架構(gòu)模式

云原生涉及的主要架構(gòu)模式。

1.4.1 服務化架構(gòu)模式

要求以應用模塊為顆粒度劃分一個應用軟件，以接口契約（例如IDL）定義彼此業(yè)務關(guān)系，以標準協(xié)議（HTTP、gRPC等）確保彼此的互聯(lián)互通，結(jié)合領(lǐng)域模型驅(qū)動（Domain Driven Design，DDD）、測試驅(qū)動開發(fā)（Test Driven Design，TDD）、容器化部署提升每個接口的代碼質(zhì)量和迭代速度。

1.4.2 Mesh化架構(gòu)模式

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

1.4.3 Serverless模式

業(yè)務流量到來/業(yè)務事件發(fā)生時，云會啟動或調(diào)度一個已啟動的業(yè)務進程進行處理，處理完成后云自動會關(guān)閉/調(diào)度業(yè)務進程，等待下一次觸發(fā)。開發(fā)者不用關(guān)心應用運行地點、操作系統(tǒng)、網(wǎng)絡配置、CPU性能等，將應用的整個運行都委托給云。Serverless模式適合事件驅(qū)動的數(shù)據(jù)計算任務、計算時間短的請求/響應應用、沒有復雜相互調(diào)用的長周期任務。

1.4.4 存儲計算分離模式

分布式環(huán)境中的CAP困難主要是針對有狀態(tài)應用，由于一致性（Consistency，C），可用性（Available，A），分區(qū)容錯性（Partition Tolerance，P）三者無法同時滿足，最多滿足其中兩個。所以無狀態(tài)應用不存在一致性這個維度，可以獲得很好的可用性和分區(qū)容錯性，因而獲得更好的彈性。

1.4.5 分布式事務模式

由于業(yè)務需要訪問多個微服務，所以會帶來分布式事務問題，否則數(shù)據(jù)就會出現(xiàn)不一致。因此架構(gòu)師需要根據(jù)不同的場景選擇合適的分布式事務模式，常用的有：
（1）XA模式：由于XA規(guī)范是實現(xiàn)分布式事務處理的標準，通常采用兩階段提交（2 Prepare Commit，2PC）的方法，具有很強的一致性，但是由于需要兩次網(wǎng)絡交互，所以性能差。
（2）基于消息的最終一致性（BASE）：在可用性和一致性相沖突的情況下，為了權(quán)衡二者，BASE提出只要滿足基本可用（BA）和最終一致性（E），接受數(shù)據(jù)的軟狀態(tài)或未確定狀態(tài)（S），來優(yōu)先實現(xiàn)性能，所以這類系統(tǒng)通常具備很高的性能。但是由于應用的特點，選擇可用性和一致性的妥協(xié)方案，導致通用性很差。
（3）TCC模式：采用Try-Confirm-Cancel二階段模式，事務隔離行可控，高效，但需要應用代碼將業(yè)務模型拆成二階段，所以對業(yè)務侵入性強，設計開發(fā)維護等成本很高。
（4）SAGA模式：每個正向事務都對應一個補償事務，若正向事務執(zhí)行失敗，則會執(zhí)行補償事務進行回滾。所以開發(fā)維護成本高。
（5）開源項目SEATA的AT模式：它將TCC模式中的二階段委托給底層代碼框架，并且取消了行鎖，所以非常高性能且無代碼開發(fā)工作量，且可以自動化執(zhí)行回滾操作，但存在一些使用場景限制。

1.4.6 可觀測架構(gòu)

可觀測架構(gòu)包括Logging、Tracing、Metrics，其中Logging提供多個級別跟蹤，例如INFO/DEBUG/WARNING/ERROR；Tracing收集一個請求從前端到后端的訪問日志聚合，形成完整調(diào)用鏈路跟蹤；Metrics則提供對系統(tǒng)量化的多維度度量，包括并發(fā)度、耗時、可用時長、容量等。

1.4.7 事件驅(qū)動架構(gòu)

事件驅(qū)動架構(gòu)（Event Driven Architecture，EDA）是一種應用/組件間的集成架構(gòu)模式。適用于增強服務韌性、數(shù)據(jù)變化通知、構(gòu)建開放式接口、事件流處理、命令查詢的責任分離（Command Query Responsibility Segregation，CQRS）把服務狀態(tài)有影響的命令用事件來發(fā)起，而對服務狀態(tài)沒有影響的查詢才使用同步調(diào)用的API接口等。

1.5 典型的云原生架構(gòu)的反模式

架構(gòu)設計有時候需要根據(jù)不同的業(yè)務場景選擇不同的方式，常見的云原生反模式有：

（1） 龐大的單體應用：缺乏依賴隔離，代碼耦合，責任和模塊邊界不清晰，模塊間接口缺乏治理，變更影響擴散，不同模塊間的開發(fā)進度和發(fā)布時間難以協(xié)調(diào)，一個子模塊不穩(wěn)定導致整個應用都變慢，擴容時只能整體擴容而不能達到瓶頸的模塊單獨擴容等。
（2） 單體應用“硬拆”為微服務：強行把耦合度高、代碼質(zhì)量少的模塊進行服務化拆分；拆分后服務的數(shù)據(jù)是緊密耦合的；差分后成為分布式調(diào)用，嚴重影響性能。
（3） 缺乏自動化能力的微服務：人均負責模塊數(shù)上升，人均工作量增大，也增加了軟件開發(fā)成本。

二、云原生架構(gòu)相關(guān)技術(shù)

1.1 容器技術(shù)

容器 作為標準化軟件基礎單元，他將應用及其所依賴項打包發(fā)布，由于依賴項齊備，應用不再受環(huán)境限制，在不同計算環(huán)境間快讀、可靠地運行。

容器部署模式與其他模式的比較，如圖，傳統(tǒng)、虛擬化、容器部署模式比較：

1.2 容器編排技術(shù)

容器編排技術(shù) 包括資源調(diào)度、應用部署與管理、自動修復、服務發(fā)現(xiàn)與負載均衡、彈性伸縮、聲明式API、可擴展性架構(gòu)、可移植性。

1.3 微服務

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

微服務設計約束如下：

（1）微服務個體約束
一個設計良好的微服務應用，所完成的功能在業(yè)務域劃分上應是相互獨立的。與單體應用強行綁定語言和技術(shù)棧相比，這樣做的好處是不同業(yè)務域有不同的技術(shù)選擇權(quán)，比如推薦系統(tǒng)采用 Python實現(xiàn)效率可能比Java要高效得多。從組織上來說，微服務對應的團隊更小，開發(fā)效率也更高。“一個微服務團隊一頓能吃掉兩張披薩餅”“一個微服務應用應當能至少兩周完成一次迭代”,都是對如何正確劃分微服務在業(yè)務域邊界的隱喻和標準。總結(jié)來說，微服務的“微”并不是為了微而微，而是按照問題域?qū)误w應用做合理拆分。進一步，微服務也應具備正交分解特性，在職責劃分上專注于特定業(yè)務并將之做好，即SOLID原則中單一職責原則 (Single Responsibility Principle,SRP)。 如果當一個微服務修改或者發(fā)布時，不應該影響到同一系統(tǒng)里另一個微服務的業(yè)務交互。

（2）微服務與微服務之間的橫向關(guān)系
在合理劃分好微服務間的邊界后，主要從微服務的可發(fā)現(xiàn)性和可交互性處理服務間的橫向關(guān)系。微服務的可發(fā)現(xiàn)性是指當服務A 發(fā)布和擴縮容的時候，依賴服務 A 的服務B 如何在不重新發(fā)布的前提下，如何能夠自動感知到服務A 的變化?這里需要引入第三方服務注冊中心來滿足服務的可發(fā)現(xiàn)性；特別是對于大規(guī)模微服務集群，服務注冊中心的推送和擴展能力尤為關(guān)鍵。微服務的可交互性是指服務A 采用什么樣的方式可以調(diào)用服務 B。 由于服務自治的約束，服務之間的調(diào)用需要采用與語言無關(guān)的遠程調(diào)用協(xié)議，比如 REST 協(xié)議很好地滿足了“與語言無關(guān)”和“標準化”兩個重要因素，但在高性能場景下，基于 IDL的二進制協(xié)議可能是更好的選擇。另外，目前業(yè)界大部分微服務實踐往往沒有達到HATEOAS啟發(fā)式的 REST 調(diào)用，服務與服務之間需要通過事先約定接口來完成調(diào)用。為了進一步實現(xiàn)服務與服務之間的解耦，微服務體系中需要有一個獨立的元數(shù)據(jù)中心來存儲服務的元數(shù)據(jù)信息，服務通過查詢該中心來理解發(fā)起調(diào)用的細節(jié)。伴隨著服務鏈路的不斷變長，整個微服務系統(tǒng)也就變得越來越脆弱，因此面向失敗
設計的原則在微服務體系中就顯得尤為重要。對于微服務應用個體，限流、熔斷、隔倉、負載均衡等增強服務韌性的機制成為了標配。為進一步提升系統(tǒng)吞吐能力、充分利用好機器資源，可以通過協(xié)程、 R x模型、異步調(diào)用、反壓等手段來實現(xiàn)。

（3）微服務與數(shù)據(jù)層之間的縱向約束

在微服務領(lǐng)域，提侶數(shù)據(jù)存儲隔離 (Data Storage Segregation,DSS) 原則，即數(shù)據(jù)是微服務的私有資產(chǎn)，對于該數(shù)據(jù)的訪問都必須通過當前微服務提供的API來訪問。如若不然，則造成數(shù)據(jù)層產(chǎn)生耦合，違背了高內(nèi)聚低耦合的原則。同時，出于性能考慮，通常采取讀寫分離(CQRS) 手段。同樣，由于容器調(diào)度對底層設施穩(wěn)定性的不可預知影響，微服務的設計應當盡量遵循無狀態(tài)設計原則，這意味著上層應用與底層基礎設施的解耦，微服務可以自由在不同容器間被調(diào)度。對于有數(shù)據(jù)存取(即有狀態(tài))的微服務而言，通常使用計算與存儲分離方式，將數(shù)據(jù)下沉到分布式存儲，通過這個方式做到一定程度的無狀態(tài)化。

（4）全局視角下的微服務分布式約束
從微服務系統(tǒng)設計一開始，就需要考慮以下因素：高效運維整個系統(tǒng)，從技術(shù)上要準備全自動化的CI/CD流水線滿足對開發(fā)效率的訴求，并在這個基礎上支持藍綠、金絲雀等不同發(fā)布策略，以滿足對業(yè)務發(fā)布穩(wěn)定性的訴求。面對復雜系統(tǒng)，全鏈路、實時和多維度的可觀測能力成為標配。為了及時、有效地防范各類運維風險，需要從微服務體系多種事件源匯聚并分析相關(guān)數(shù)據(jù)，然后在中心化的監(jiān)控系統(tǒng)中進行多維度展現(xiàn)。伴隨著微服務拆分的持續(xù)，故障發(fā)現(xiàn)時效性和根因精確性始終是開發(fā)運維人員的核心訴求。

1.4 無服務技術(shù)

無服務技術(shù)的特點：

(1)全托管的計算服務，客戶只需要編寫代碼構(gòu)建應用，無需關(guān)注同質(zhì)化的、負擔繁重的基于服務器等基礎設施的開發(fā)、運維、安全、高可用等工作；

(2)通用性，結(jié)合云 BaaSAPI的能力，能夠支撐云上所有重要類型的應用；

(3)自動彈性伸縮，讓用戶無需為資源使用提前進行容量規(guī)劃；

(4)按量計費，讓企業(yè)使用成本得有效降低，無需為閑置資源付費。

1.5 服務網(wǎng)絡

服務網(wǎng)格 (ServiceMesh) 是分布式應用在微服務軟件架構(gòu)之上發(fā)展起來的新技術(shù)，旨在將那些微服務間的連接、安全、流量控制和可觀測等通用功能下沉為平臺基礎設施，實現(xiàn)應用與平臺基礎設施的解耦 。這個解耦意味著開發(fā)者無需關(guān)注微服務相關(guān)治理問題而聚焦于業(yè)務邏輯本身，提升應用開發(fā)效率并加速業(yè)務探索和創(chuàng)新。換句話說，因為大量非功能性從業(yè)務進程剝離到另外進程中，服務網(wǎng)格以無侵入的方式實現(xiàn)了應用輕量化。

如圖，服務網(wǎng)格的典型架構(gòu)：

在這張架構(gòu)圖中，服務A 調(diào)用服務B 的所有請求，都被其下的服務代理截獲，代理服務A 完成到服務B 的服務發(fā)現(xiàn)、熔斷、限流等策略，而這些策略的總控是在控制平面 (Control Plane) 上配置。文章來源地址http://www.zghlxwxcb.cn/news/detail-674683.html

到了這里，關(guān)于系統(tǒng)架構(gòu)設計高級技能 · 云原生架構(gòu)設計理論與實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！