阿里云資深技術(shù)專家談對云原生軟件架構(gòu)的觀察與思考 | IDCF
來源：阿里巴巴云原生 作者：易立 阿里云資深技術(shù)專家
前言
在《解讀云原生基礎(chǔ)設(shè)施》一文中，我們談到了云原生計算包含三個維度的內(nèi)容：云原生基礎(chǔ)設(shè)施，軟件架構(gòu)和交付與運維體系，本文將聚焦于軟件架構(gòu)層面。
“Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. ”?
——維基百科
個人理解，軟件架構(gòu)主要目標是解決下列挑戰(zhàn)：
控制復(fù)雜性：由于業(yè)務(wù)的復(fù)雜性，需要我們用更好的手段幫助研發(fā)組織克服認知障礙，更好的分工協(xié)作。分而治之，關(guān)注點分離等手段皆是如此。 應(yīng)對不確定性：業(yè)務(wù)在快速發(fā)展，需求在不斷變化。即使再完美的軟件架構(gòu)，然而隨著時間的推移，團隊的變化，軟件架構(gòu)的調(diào)整不可避免。讀《設(shè)計模式》，《微服務(wù)設(shè)計》等書字里行間寫的都是“解耦”兩字，讓我們關(guān)注架構(gòu)中確定性和不確定性的分離，提升架構(gòu)的穩(wěn)定性和應(yīng)變能力。 管理系統(tǒng)性風險：管理系統(tǒng)中的確定性以及不確定性風險，規(guī)避已知陷阱，對未知的風險做好準備。
云原生應(yīng)用架構(gòu)的目標是構(gòu)建松耦合、具備彈性、韌性的分布式應(yīng)用軟件架構(gòu)，可以更好地應(yīng)對業(yè)務(wù)需求的變化和發(fā)展，保障系統(tǒng)穩(wěn)定性，本文將分享一下在這個領(lǐng)域的觀察和思考。
一、緣起：12要素應(yīng)用
2012 年，Heroku 創(chuàng)始人 Adam Wiggins 發(fā)布十二要素應(yīng)用宣言。它為構(gòu)建一個優(yōu)雅的互聯(lián)網(wǎng)應(yīng)用，定義了需要遵循的一些基本原則和方法論，也廣泛影響了眾多的微服務(wù)應(yīng)用架構(gòu)。十二要素重點關(guān)注：應(yīng)用程序的健康成長，開發(fā)者之間的有效的協(xié)作，以及避免軟件架構(gòu)腐化的影響。其內(nèi)容在今天也值得每個同學(xué)認真體會。
圖片來源：https://12factor.net/zh_cn/
12 要素應(yīng)用為我們提供了很好的架構(gòu)指導(dǎo)，幫助我們：
構(gòu)建水平伸縮的彈性應(yīng)用架構(gòu)，更好支撐互聯(lián)網(wǎng)規(guī)模應(yīng)用。 提升研發(fā)流程的標準化、自動化水平，提升研發(fā)效率。 減少開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異，并使用持續(xù)交付實施敏捷開發(fā)。 提升應(yīng)用的可移植性，適合云化部署，降低資源成本和管理復(fù)雜性。
二、松耦合架構(gòu)設(shè)計
微服務(wù)的核心理念是，系統(tǒng)中的各個服務(wù)可被獨立開發(fā)、獨立部署，獨立升級，各個服務(wù)之間是松耦合的。云原生應(yīng)用架構(gòu)理念是進一步強調(diào)架構(gòu)的松耦合，降低服務(wù)之間相互依賴的程度。
2.1 API 優(yōu)先的應(yīng)用架構(gòu)設(shè)計
在面向?qū)ο蟮能浖軜?gòu)中，最重要的是定義對象以及對象的接口契約。SOLID 原則是最被人廣為熟知的設(shè)計原則：
Single responsibility principle - 單一職責原則 Open/closed principle - 開放/封閉原則 Liskov substitution principle - 里氏替換原則 Interface segregation principle - 接口隔離原則 Dependency inversion principle - 依賴翻轉(zhuǎn)原則
將以上五個原則的英文首字母拼在一起就是 SOLID 原則，這也是幫助我們構(gòu)建高內(nèi)聚，低耦合、具備柔性的應(yīng)用架構(gòu)。在分布式微服務(wù)應(yīng)用架構(gòu)中，API 優(yōu)先是契約優(yōu)先（Contract First）的自然拓展。
API 應(yīng)該是被優(yōu)先設(shè)計的：我們知道用戶需求是復(fù)雜多變的，比如從桌面到移動端，應(yīng)用的展現(xiàn)方式和操作流程都有可能不同；然而業(yè)務(wù)邏輯的概念模型和服務(wù)交互是相對穩(wěn)定的。相對而言，API 的接口是更加穩(wěn)定的，而具體的實現(xiàn)是可以迭代實現(xiàn)和持續(xù)變化的。定義良好的 API 可以更好保障應(yīng)用系統(tǒng)的質(zhì)量。 API 應(yīng)該是聲明式，可描述/自描述的：通過規(guī)范化的描述，API 易于溝通、易于理解、易于驗證，簡化開發(fā)協(xié)同。支持服務(wù)的消費者和提供者并行開發(fā)，加速開發(fā)周期。支持不同的技術(shù)棧的實現(xiàn)，比如對于同一個 API 接口，其服務(wù)實現(xiàn)采用 Java 。前端應(yīng)用可以使用 JavaScript ，而服務(wù)器端應(yīng)用可以使用 Golang 進行服務(wù)調(diào)用等等。這樣可以讓開發(fā)組織可以根據(jù)自己的技能棧和系統(tǒng)要求靈活選擇合適的技術(shù)。 API 應(yīng)該具備 SLA：API 作為服務(wù)間的集成界面，與系統(tǒng)的穩(wěn)定性息息相關(guān)。SLA 應(yīng)該作為 API 設(shè)計的一部分，而不是部署后再考慮。在分布式系統(tǒng)中，穩(wěn)定性風險無處不在，通過 API 優(yōu)先的設(shè)計模式，我們對獨立的服務(wù)進行穩(wěn)定性架構(gòu)設(shè)計、容量規(guī)劃；我們還可以對獨立的 API 進行故障注入、穩(wěn)定性演練，來消除系統(tǒng)性的穩(wěn)定性風險。
在 API 領(lǐng)域，最重要的趨勢是標準化技術(shù)的崛起。gRPC 是 Google 開源的的高性能、通用的、平臺無關(guān)的 RPC 框架。它采用分層設(shè)計，其數(shù)據(jù)交換格式基于 Protobuf (Protocol Buffers) 協(xié)議開發(fā)，具備優(yōu)秀的序列化/反序列化效率，也支持眾多開發(fā)語言。在傳輸層協(xié)議， gRPC 選擇了 HTTP/2，相較于 HTTP/1.1，其傳輸效率有了很大提升。
此外 HTTP/2 作為一個成熟的開放標準，具備豐富的安全、流控等能力，同時擁有良好的互操作性。gRPC 不僅可以用于 Server 端服務(wù)調(diào)用，也可以支持瀏覽器、移動 App 和 IoT 設(shè)備與后端服務(wù)的交互。gRPC 在功能上已經(jīng)具備完整的 RPC 能力，也提供了擴展機制來支持新的功能。
在 Cloud Native 的潮流下，跨平臺、跨廠商、跨環(huán)境的系統(tǒng)間互操作性的需求必然會催生基于開放標準的 RPC 技術(shù)，而 gRPC 順應(yīng)了歷史趨勢，得到了越來越廣泛地應(yīng)用。在微服務(wù)領(lǐng)域， Dubbo 3.0 宣布了對 gRPC 協(xié)議的支持，未來我們也會看到更多的微服務(wù)架構(gòu)基于 gRPC 協(xié)議開發(fā)，并提供良好的多語言支持。此外，在數(shù)據(jù)服務(wù)領(lǐng)域，gPRC 也成為一個優(yōu)秀的選擇。
此外在 API 領(lǐng)域 Swagger (OpenAPI 規(guī)范)，GraphQL 都是大家值得關(guān)注的開放標準。大家根據(jù)自己的業(yè)務(wù)訴求靈活選用，本文不再贅述。
2.2 Event Driven Architecture 的崛起
談事件驅(qū)動架構(gòu) （EDA - Event Driven Architecture），我們首先來解釋一下什么是事件。事件是指對已經(jīng)發(fā)生的事情、狀態(tài)變化等的記錄。它們是不可變的（無法更改或刪除），并且按其創(chuàng)建順序排序。相關(guān)各方可以通過訂閱已發(fā)布的事件來獲取有關(guān)這些狀態(tài)變化的通知，然后使用所選擇的業(yè)務(wù)邏輯根據(jù)這些信息采取操作。
事件驅(qū)動架構(gòu)是一種構(gòu)建松耦合的微服務(wù)系統(tǒng)的架構(gòu)方式，微服務(wù)之間通過異步事件通信來進行交互。
事件驅(qū)動架構(gòu)實現(xiàn)了事件的生產(chǎn)者和消費者的徹底解耦。生產(chǎn)者無需關(guān)注事件如何被消費，同時消費者無需關(guān)注事件的生產(chǎn)方式；我們可以動態(tài)添加更多消費者而不影響生產(chǎn)者，可以增加消息中間件對事件進行動態(tài)路由和轉(zhuǎn)換。這還意味著事件的生產(chǎn)者和消費者沒有時序上的依賴，即使由于應(yīng)用宕機無法及時處理消息，在重新恢復(fù)后，程序可以繼續(xù)從消息隊列中獲取這些事件繼續(xù)執(zhí)行。這樣的松耦合架構(gòu)，為軟件架構(gòu)提供更高的敏捷性、靈活性和健壯性。
事件驅(qū)動架構(gòu)的另一個重要優(yōu)點是提升了系統(tǒng)的可伸縮性。事件生產(chǎn)者在等待事件消費時不會被阻塞，并且可以采用 Pub/Sub 方式，讓多個消費者并行處理事件。
事件驅(qū)動架構(gòu)還可以完美地與 Function as a Service (FaaS) 相整合。事件觸發(fā)函數(shù)執(zhí)行業(yè)務(wù)邏輯，在函數(shù)中也可以編寫集成多個服務(wù)的“膠水代碼”，簡單、高效地構(gòu)建事件驅(qū)動架構(gòu)的應(yīng)用。
但是 EDA 架構(gòu)依然存在很多挑戰(zhàn)：
分布式的松耦合架構(gòu)大大增加了應(yīng)用基礎(chǔ)設(shè)施的復(fù)雜性?；谠频牟渴鸾桓斗绞胶驮品?wù)（消息隊列、函數(shù)計算服務(wù)等）可以使得該架構(gòu)的穩(wěn)定性，性能和成本效益進一步提高。 與傳統(tǒng)同步處理方式相比，異步事件處理存在與事件排序、冪等性、回調(diào)和異常處理相關(guān)的要求，整體設(shè)計難度更大一些。 在大多數(shù)情況下，由于缺乏跨多個系統(tǒng)的分布式事務(wù)支持，維護數(shù)據(jù)一致性是非常具有挑戰(zhàn)性的。開發(fā)者可能需要權(quán)衡可用性和一致性之間的關(guān)系。比如通過 Event Sourcing（事件溯源）實現(xiàn)最終一致性。 互操作性。在現(xiàn)實世界中，事件無處不在，然而不同生產(chǎn)者對事件的描述卻不盡相同。開發(fā)者希望無論事件是從哪里發(fā)出，都能夠以一致的方式構(gòu)建事件驅(qū)動的應(yīng)用程序。CloudEvents 是一種以通用、一致的方式描述事件數(shù)據(jù)的規(guī)范，由 CNCF Severless 工作組提出，提升了事件驅(qū)動應(yīng)用的可移植性。目前，阿里云 EventBridge、Azure Event Grid 等事件處理中間件，以及 Knative Eventing，阿里云函數(shù)計算等 FaaS 技術(shù)已經(jīng)提供了對 CloudEnvents 的支持。
由于 EDA 自身架構(gòu)的優(yōu)點，在互聯(lián)網(wǎng)應(yīng)用架構(gòu)，業(yè)務(wù)數(shù)據(jù)化和智能化、IoT 等場景有非常廣闊的前景。關(guān)于 EDA 的架構(gòu)討論，不在此繼續(xù)展開。
三、面向交付的應(yīng)用架構(gòu)
在云原生軟件架構(gòu)中，我們在設(shè)計階段不只是關(guān)注軟件如何被構(gòu)建，也需要以終為始。關(guān)注如何合理設(shè)計和實現(xiàn)軟件，才可以被更好地交付和運維。
3.1 應(yīng)用和運行環(huán)境解耦
在 12 要素應(yīng)用中，應(yīng)用和運行環(huán)境解耦就已經(jīng)被提出。而 Docker 容器的出現(xiàn)則進一步加強了這個理念。容器是一種輕量化的應(yīng)用虛擬化技術(shù)，容器之間共享操作系統(tǒng)內(nèi)核，支持秒級啟動，Docker 容器鏡像是一個自包含的應(yīng)用打包格式，將應(yīng)用和其依賴（如系統(tǒng)庫、配置文件）等打包在一起，在不同環(huán)境保持部署一致性。
容器可以作為 Immutable Infrastructure （不可變基礎(chǔ)設(shè)施）的基礎(chǔ)，提升應(yīng)用交付的穩(wěn)定性。不可變基礎(chǔ)設(shè)施是由 Chad Fowler 于 2013 年提出的構(gòu)想：在這種模式中，任何基礎(chǔ)設(shè)施的實例（包括服務(wù)器、容器等各種軟硬件）一旦創(chuàng)建之后便成為一種只讀狀態(tài)，不可對其進行任何更改。如果需要修改或升級某些實例，就是創(chuàng)建一批新的實例進行替換。
這種模式的可以減少了配置管理工作的負擔，保障系統(tǒng)配置變更和升級可以可靠地重復(fù)執(zhí)行，避免令人頭疼的配置漂移問題；易于解決部署環(huán)境間的差異，讓持續(xù)集成與持續(xù)部署過程變得更流暢；支持更好的版本管理，在部署出錯時可進行快速回滾。
Kubernetes 作為容器的分布式編排調(diào)度系統(tǒng)，進一步提升了容器應(yīng)用的可移植性。K8s 通過一系列抽象如 Loadbalance Service / Ingress / CNI / CSI，幫助業(yè)務(wù)應(yīng)用可以屏蔽底層基礎(chǔ)設(shè)施的實現(xiàn)差異，靈活遷移。通過這樣的能力，我們可以實現(xiàn)工作負載在數(shù)據(jù)中心、邊緣計算和云環(huán)境的動態(tài)遷移。
在應(yīng)用架構(gòu)中，我們需要避免將靜態(tài)環(huán)境信息，比如 IP / mac 地址等與應(yīng)用邏輯耦合。在微服務(wù)架構(gòu)中，可以利用 Zookeeper/Nacos 等實現(xiàn)服務(wù)的注冊發(fā)現(xiàn)；在 Kubernetes 中，我們可以通過 Service / Service Mesh 減少對服務(wù)端點 IP 的依賴。此外，對應(yīng)用狀態(tài)的持久化也盡可能通過分布式存儲或者云服務(wù)等實現(xiàn)，這樣可以大大提升應(yīng)用架構(gòu)可伸縮性和自愈能力。
3.2 自包含可觀測性
分布式系統(tǒng)所面對的最大挑戰(zhàn)之一就是可觀測性?？捎^測性可以幫助我們解系統(tǒng)當前的狀態(tài)，并作為應(yīng)用自愈，彈性伸縮和智能運維的基礎(chǔ)。
在云原生架構(gòu)中，微服務(wù)應(yīng)用是自包含的，應(yīng)該自己具備可觀測性，可以方便地被系統(tǒng)進行管理和探查。首先是，應(yīng)用應(yīng)該具備自身健康狀態(tài)的可視化能力。
在 Kubernetes 中，業(yè)務(wù)應(yīng)用可以提供一個 liveness 探針，可以通過 TCP、HTTP 或者命令行方式對應(yīng)用就緒進行檢測。對于 HTTP 類型探針，Kubernetes 會定時訪問該地址，如果該地址的返回碼不在 200 到 400 之間，則認為該容器不健康，會殺死該容器重建新的容器。
對于啟動緩慢的應(yīng)用，為了避免在應(yīng)用啟動完成之前將流量導(dǎo)入。Kubernetes 支持業(yè)務(wù)容器提供一個 readiness 探針，對于 HTTP 類型探針，Kubernetes 會定時訪問該地址，如果該地址的返回碼不在 200 到 400 之間，則認為該容器無法對外提供服務(wù)，不會把請求調(diào)度到該容器。
同時在新的微服務(wù)架構(gòu)中已經(jīng)內(nèi)置了可觀測探針，比如在 SpringBoot 的 2.3 發(fā)布了兩個新的 actuator 地址：/actuator/health/liveness 和 /actuator/health/readiness ，前者用作存活探針，后者用作就緒探針。業(yè)務(wù)應(yīng)用可以通過Spring系統(tǒng)事件機制來讀取、訂閱、修改 Liveness State 和 Readiness State ，這樣可以讓 Kubernetes 平臺可以做更加準確的自愈和流量管理。
此外，應(yīng)用可觀測性包含三個關(guān)鍵能力：日志、監(jiān)控與鏈路追蹤。
Logging – 日志（事件流）：用于記錄離散的事件，包含程序執(zhí)行到某一點或某一階段的詳細信息。不但包括應(yīng)用、 OS 執(zhí)行過程的日志，還應(yīng)包含運維過程中的日志信息，如操作審計等。 Metrics – 監(jiān)控指標：通常是固定類型的時序數(shù)據(jù)，包括 Counter、Gauge、Histogram 等，是可聚合的數(shù)據(jù)。系統(tǒng)的監(jiān)控能力是多層次的，既包含計算、存儲，網(wǎng)絡(luò)等基礎(chǔ)設(shè)施服務(wù)層次的監(jiān)控指標，也應(yīng)該包含業(yè)務(wù)應(yīng)用的性能監(jiān)控和業(yè)務(wù)指標監(jiān)控。 Tracing – 鏈路追蹤：記錄單個請求的完整處理流程，可以為分布式應(yīng)用的開發(fā)者提供了完整的調(diào)用鏈路還原、調(diào)用請求量統(tǒng)計、應(yīng)用依賴分析等能力，能夠幫助開發(fā)者快速分析和診斷分布式應(yīng)用架構(gòu)下的性能和穩(wěn)定性瓶頸。
在分布式系統(tǒng)中，穩(wěn)定性、性能、安全等問題可能發(fā)生在任何地方，需要全鏈路可觀測性能力保障，需要覆蓋基礎(chǔ)設(shè)施層、 PaaS 層，應(yīng)用等不同層次，并且可以在不同系統(tǒng)間實現(xiàn)可觀測性數(shù)據(jù)的關(guān)聯(lián)、聚合、查詢和分析。
軟件架構(gòu)的可觀測領(lǐng)域具備廣闊的前景，也涌現(xiàn)出眾多的技術(shù)創(chuàng)新。2020 年 9 月 CNCF 發(fā)布了云原生可觀測性的技術(shù)雷達。
其中，Prometheus 已成為企業(yè)首選的云原生應(yīng)用程序的開源監(jiān)控工具之一。Prometheus 培養(yǎng)了一個活躍的開發(fā)者和用戶社區(qū)。在 Spring Boot 應(yīng)用架構(gòu)中，通過引入 micrometer-registry-prometheus 的依賴，既可以讓應(yīng)用的監(jiān)控指標被 Prometheus 服務(wù)所采集。
在分布式追蹤領(lǐng)域，OpenTracing 是 CNCF 下屬的開源項目。它是一個技術(shù)中立的分布式追蹤的規(guī)范，提供統(tǒng)一接口，可方便開發(fā)者在自己的服務(wù)中集成一種或多種分布式追蹤的實現(xiàn)。Jaeger 是Uber 開源的分布式追蹤系統(tǒng)，兼容 OpenTracing 標準，已經(jīng)成功在 CNCF 畢業(yè)。此外OpenTelemetry是一個潛在的標準，它試圖在融合 OpenTracing 和 OpenCensus 這兩個項目，形成統(tǒng)一的技術(shù)標準。
對于很多遺留的業(yè)務(wù)系統(tǒng)，現(xiàn)有應(yīng)用并不具備完備的可觀測性能力。新興的服務(wù)網(wǎng)格技術(shù)可以成為提升系統(tǒng)可觀測性的新方式。通過數(shù)據(jù)平面代理的請求攔截，網(wǎng)格可以獲取服務(wù)間調(diào)用的性能指標。此外，在服務(wù)調(diào)用方應(yīng)用中只需加入需要轉(zhuǎn)發(fā)的消息 header，在服務(wù)網(wǎng)格上即可獲得完整的鏈路追蹤信息。這樣的方式極大簡化了可觀測性能力的建設(shè)，可以讓現(xiàn)有的應(yīng)用低成本融入云原生可觀測性體系中。
阿里云提供了豐富的可觀測性能力。XTrace 分布式追蹤提供了對 OpenTracing/OpenTelemetry 標準的支持。ARMS 提供了托管 Prometheus 服務(wù)，可以讓開發(fā)者無需關(guān)注系統(tǒng)的高可用和容量挑戰(zhàn)?？捎^測性是 AIOps 的基礎(chǔ)，在未來企業(yè)IT應(yīng)用架構(gòu)中將扮演更加重要的角色。
3.3 面向失敗的設(shè)計 - Design For Failure
根據(jù)”墨菲定律“ — “Anything that can go wrong will go wrong”。分布式系統(tǒng)可能受到硬件、軟件等因素、或者內(nèi)部和外部的人為破壞。云計算比自建數(shù)據(jù)中心提供了更高 SLA、更加安全的基礎(chǔ)設(shè)施，但是我們在應(yīng)用架構(gòu)設(shè)計時依然要時刻關(guān)注系統(tǒng)的可用性，關(guān)注潛在的”黑天鵝“風險。
系統(tǒng)化的穩(wěn)定性需要在軟件架構(gòu)，運維體系和組織保障等方面全局考慮。在架構(gòu)層面，阿里經(jīng)濟體有著非常豐富的經(jīng)驗，比如防御式設(shè)計、限流、降級、故障隔離等，而且也向社區(qū)貢獻了 Sentinel、ChaosBlade 等優(yōu)秀的開源項目。
本文，我們將會談?wù)剮讉€在云原生時代可以進一步思考的地方。個人的總結(jié)是 “Failures can and will happen, anytime, anywhere. Fail fast, fail small, fail often and recover quickly.”
首先是“Failures can and will happen”，我們需要提升服務(wù)器的可替換性。在業(yè)界有一個非常流行的隱喻：“Pets vs. Cattle”，寵物和家畜。我們面對一個架構(gòu)選擇：對于應(yīng)用所在服務(wù)器我們是需要精心伺候，防止系統(tǒng)宕機，出現(xiàn)問題后不惜一切代價搶救 （Pet）；還是傾向于出現(xiàn)問題后，可以通過簡單拋棄和替代進行恢復(fù)（Cattle）。
云原生架構(gòu)的建議是：允許失敗發(fā)生，確保每個服務(wù)器，每個組件都能夠在不影響系統(tǒng)的情況下發(fā)生故障并且具備自愈和可替代能力。這個設(shè)計原則的基礎(chǔ)是應(yīng)用配置和持久化狀態(tài)與具體運行環(huán)境的解耦。Kubernetes 的自動化運維體系讓服務(wù)器的可替換性變得更加簡單。
此外是 “Fail fast, fail small, recover quickly” 。立即失效（Fail fast）是一個非常反直覺的設(shè)計原則，它背后的哲學(xué)是既然故障無法避免，問題越及早暴露、應(yīng)用越容易恢復(fù)，進入生產(chǎn)環(huán)境的問題就越少。采用了 Fail-fast 策略以后，我們的關(guān)注點將從如何窮盡系統(tǒng)中的問題轉(zhuǎn)移到如何快速地發(fā)現(xiàn)和優(yōu)雅處理失敗。只要跑的夠快，故障就追不上我。:-)?
在研發(fā)流程上，通過集成測試盡可能在早期發(fā)現(xiàn)應(yīng)用存在的問題。在應(yīng)用級別，可以采用斷路器（Circuit Breaker）等模式防止一個依賴服務(wù)的局部故障引起全局問題；此外通過 K8s 的健康監(jiān)測、可觀測性可以實現(xiàn)對應(yīng)用故障的探知，通過服務(wù)網(wǎng)格的斷路器功能，可以將故障發(fā)現(xiàn)、流量切換和快速自愈這些能力外置到應(yīng)用實現(xiàn)之外，由系統(tǒng)能力保障。Fail small 的本質(zhì)在于控制故障的影響范圍——爆炸半徑。這個原則在架構(gòu)設(shè)計和服務(wù)設(shè)計上都需要我們持續(xù)關(guān)注。
最后是“Fail often”，混沌工程是一種在生產(chǎn)環(huán)境周期性引入故障變量，驗證系統(tǒng)對非預(yù)期故障防御的有效性的思想。Netflix 引入混沌工程概念解決微服務(wù)架構(gòu)的穩(wěn)定性挑戰(zhàn)，也得到了眾多互聯(lián)網(wǎng)公司的廣泛應(yīng)用。在云原生時代又有了更多新的手段，Kubernetes 讓我們可以輕松注入故障，殺死 pod，模擬應(yīng)用失效和自愈過程。利用服務(wù)網(wǎng)格我們可以對服務(wù)間流量進行更加復(fù)雜的故障注入，比如 Istio 可以模擬緩慢響應(yīng)、服務(wù)調(diào)用失敗等故障場景，幫助我們驗證服務(wù)間的耦合性，提升系統(tǒng)的穩(wěn)定性。
四、應(yīng)用基礎(chǔ)設(shè)施能力下沉
云原生軟件架構(gòu)的重要目標讓開發(fā)者關(guān)注業(yè)務(wù)邏輯，讓平臺去承載系統(tǒng)復(fù)雜性。云原生計算重新定義了應(yīng)用與應(yīng)用基礎(chǔ)設(shè)施的邊界，進一步提升了開發(fā)效率，降低了分布式應(yīng)用開發(fā)的復(fù)雜性。
4.1 服務(wù)治理能力與業(yè)務(wù)邏輯解耦
在微服務(wù)時代，以 Spring Cloud 與 Apache Dubbo 為代表的應(yīng)用框架取得了巨大的成功，它們通過代碼庫方式提供了服務(wù)通信、服務(wù)發(fā)現(xiàn)和服務(wù)治理能力（流量轉(zhuǎn)移、熔斷、限流、全鏈路追蹤等）。這些代碼庫被構(gòu)建在應(yīng)用程序本身中，隨著應(yīng)用一起發(fā)布和維護。這樣的架構(gòu)存在一些無法回避的挑戰(zhàn)：
侵入性：服務(wù)治理本質(zhì)是橫向的系統(tǒng)級關(guān)注，是與業(yè)務(wù)邏輯正交的。但在現(xiàn)有微服務(wù)框架中，其實現(xiàn)方式和生命周期與業(yè)務(wù)邏輯耦合在一起的。服務(wù)治理能力的增強需要微服務(wù)框架的升級，會導(dǎo)致整個系統(tǒng)所有組件的重新構(gòu)建和部署，導(dǎo)致升級和維護成本提升。 實現(xiàn)綁定：由于微服務(wù)框架代碼庫通常由特定語言實現(xiàn)，難以支持多語言（polyglot）實現(xiàn)。隨著業(yè)務(wù)的快速發(fā)展，異構(gòu)系統(tǒng)之間的集成逐漸成為挑戰(zhàn)。
為了解決上述挑戰(zhàn)，社區(qū)提出了 Service Mesh（服務(wù)網(wǎng)格）架構(gòu)，它將業(yè)務(wù)邏輯與服務(wù)治理能力解耦。下沉到基礎(chǔ)設(shè)施，在服務(wù)的消費者和提供者兩側(cè)以獨立進程的方式部署。這樣既達到了去中心化的目的，保障了系統(tǒng)的可伸縮性；也實現(xiàn)了服務(wù)治理和業(yè)務(wù)邏輯的解耦，二者可以獨立演進不相互干擾，提升了整體架構(gòu)演進的靈活性；同時服務(wù)網(wǎng)格架構(gòu)減少了對業(yè)務(wù)邏輯的侵入性，降低了多語言支持的復(fù)雜性。
Google、IBM、Lyft 主導(dǎo)發(fā)起的 Istio 項目就是服務(wù)網(wǎng)格架構(gòu)的一個典型的實現(xiàn)，也成為了新的現(xiàn)象級“網(wǎng)紅”項目。
上圖是 Istio 的架構(gòu)，邏輯上分為數(shù)據(jù)平面和控制平面。數(shù)據(jù)平面負責服務(wù)之間的數(shù)據(jù)通信。應(yīng)用和以 sidecar 方式部署的智能代理 Envoy 成對出現(xiàn)。其中由 Envoy 負責截獲和轉(zhuǎn)發(fā)應(yīng)用網(wǎng)絡(luò)流量，收集遙測數(shù)據(jù)并且執(zhí)行服務(wù)治理策略。在最新的架構(gòu)中， istiod 作為控制平面中負責配置的管理、下發(fā)、證書管理等。Istio 提供了一系列通用服務(wù)治理能力，比如：服務(wù)發(fā)現(xiàn)和負載均衡、漸進式交付(灰度發(fā)布)、混沌注入與分析、全鏈路追蹤和零信任網(wǎng)絡(luò)安全等?？梢怨┥蠈訕I(yè)務(wù)系統(tǒng)將其編排到自己的 IT 架構(gòu)和發(fā)布系統(tǒng)之中。
服務(wù)網(wǎng)格在架構(gòu)上實現(xiàn)了數(shù)據(jù)平面與控制平面的分離，這是一個非常優(yōu)雅的架構(gòu)選擇。企業(yè)客戶對數(shù)據(jù)平面有著多樣化的需求，比如支持等多樣化協(xié)議（如 Dubbo），需要定制化的安全策略和可觀測性接入等。服務(wù)控制平面的能力也是快速變化的，比如從基礎(chǔ)的服務(wù)治理到可觀測性，再到安全體系、穩(wěn)定性保障等等。但是控制平面與數(shù)據(jù)平面之間的 API 是相對穩(wěn)定的。
CNCF 建立了通用數(shù)據(jù)平面 API 工作組（Universal Data Plane API Working Group / UDPA-WG)，以制定數(shù)據(jù)平面的標準 API。通用數(shù)據(jù)平面 API（UDPA）的目標是：為 L4/L7 數(shù)據(jù)平面配置提供實現(xiàn)無關(guān)的標準化 API，類似于 OpenFlow 在 SDN 中對 L2/L3/L4 所扮演的角色。UDPA API 涵蓋服務(wù)發(fā)現(xiàn)、負載均衡、路由發(fā)現(xiàn)、監(jiān)聽器配置、安全發(fā)現(xiàn)、負載報告、運行狀況檢查委托等。
UDPA API 基于現(xiàn)有的 Envoy xDS API 逐步演進，目前除支持 Envoy 之外，將支持客戶端負載均衡實現(xiàn) (比如 gRPC-LB)，更多數(shù)據(jù)平面代理，硬件負載均衡和移動客戶端等等。
我們知道 Service Mesh 不是銀彈，其架構(gòu)選擇是通過增加一個服務(wù)代理來換取架構(gòu)的靈活性和系統(tǒng)的可演化性，但是也增加了部署復(fù)雜性（sidecar 管理）和性能損失（增加兩跳）。UDPA 的標準化和發(fā)展將給服務(wù)網(wǎng)格架構(gòu)帶來的新一次變化。
gRPC 在最新版本中提供了對 UDPA 負載均衡的初步支持。
“proxyless” 服務(wù)網(wǎng)格概念浮出水面，一個概念示意圖如下：
gRPC 應(yīng)用直接從控制平面獲取服務(wù)治理的策略， gPRC 應(yīng)用之間直接通信無需額外代理。這個可以看到開放的服務(wù)網(wǎng)格技術(shù)的雄心，進化成為一套跨語言的服務(wù)治理框架，可以兼顧標準化、靈活性與運行效率。Google 的托管服務(wù)網(wǎng)格產(chǎn)品已經(jīng)率先提供了對 “proxyless” gRPC 應(yīng)用的支持。
4.2 新一代分布式應(yīng)用運行時
對于分布式應(yīng)用，Bilgin Ibryam 在Multi-Runtime Microservices Architecture。
文中分析并總結(jié)了典型的四大類需求：
生命周期（Lifecycle） 網(wǎng)絡(luò)（Networking） 狀態(tài)（State） 捆綁（Binding）
熟悉傳統(tǒng)企業(yè)架構(gòu)的同學(xué)可能發(fā)現(xiàn)，傳統(tǒng)的 Java EE (現(xiàn)在改名為 Jakarta EE )應(yīng)用服務(wù)器的目標也是解決類似的問題。一個典型 Java EE 應(yīng)用服務(wù)器的架構(gòu)如下圖所示：應(yīng)用生命周期由各種應(yīng)用容器管理，如 Web 容器、EJB 容器等。應(yīng)用的安全管理、事務(wù)管理、連接池管理都是交給應(yīng)用服務(wù)器完成。應(yīng)用可以通過 JDBC 、JMS 等標準 API 接口訪問外部的企業(yè)中間件，如數(shù)據(jù)庫、消息隊列等。
不同的外部中間件通過 Java Connector Architecture 規(guī)范實現(xiàn)與應(yīng)用服務(wù)器的插拔。應(yīng)用通過 JNDI 在運行時實現(xiàn)與具體資源的動態(tài)綁定。Java EE 將系統(tǒng)的 cross-cutting concern下沉到應(yīng)用服務(wù)器來解決，讓開發(fā)者只關(guān)注應(yīng)用的業(yè)務(wù)邏輯，開發(fā)效率有了較好的提升；同時減輕應(yīng)用對環(huán)境和中間件實現(xiàn)的依賴，比如可以在開發(fā)環(huán)境中用 ActiveMQ ，在生產(chǎn)環(huán)境中使用 IBM MQ 替換，而無需修改應(yīng)用邏輯。
在架構(gòu)上，Java EE 是一個大的單體應(yīng)用平臺，拖慢了自身架構(gòu)迭代的速度，跟不上時代的變化。由于 Java EE 過于復(fù)雜、沉重，在微服務(wù)興起之后已經(jīng)被大多數(shù)開發(fā)者所遺忘。
五、在云原生的時代，我們到底需要什么樣的應(yīng)用運行時？
Dapr 是微軟給出的答案。Dapr 是一個事件驅(qū)動的，可移植的，構(gòu)建微服務(wù)應(yīng)用的運行時環(huán)境。支持應(yīng)用在云或邊緣部署，支持語言與框架的多樣性。Dapr 利用 Sidecar 的模式，把應(yīng)用邏輯中的一些橫切關(guān)注點需求（Cross-cutting）分離和抽象出來，從而達到應(yīng)用與運行環(huán)境的解耦以及對外部依賴（包括服務(wù)之間）的解耦。
Dapr 的功能和定位如上圖所示：
最底下基礎(chǔ)設(shè)施是各種云平臺或者邊緣環(huán)境。 其上是 Dapr 運行時和“building block” (構(gòu)件)。Dapr 構(gòu)件解耦了外部服務(wù)和服務(wù)的消費者，可以按需加載。構(gòu)件以統(tǒng)一的 HTTP/gPRC API 為應(yīng)用層提供服務(wù)訪問。我們可以將外部服務(wù)從 Amazon DyanamoDB 切換為 Azure ComosDB，上層應(yīng)用無需修改任何代碼。Dapr 運行時作為一個獨立的 sidecar 進程，獨立于應(yīng)用邏輯。 應(yīng)用通過輕量化的 SDK 來簡化對構(gòu)件 API 的調(diào)用，基于 gRPC/HTTP 開放協(xié)議可以輕松支持多語言。
盡管 Dapr 和 Service Mesh 在架構(gòu)上有些類似，服務(wù)治理功能有所重疊，但兩者在本質(zhì)上卻大有不同。服務(wù)網(wǎng)格對應(yīng)用是透明的基礎(chǔ)設(shè)施；而 Dapr 為狀態(tài)管理，服務(wù)調(diào)用和故障處理，資源綁定，發(fā)布/訂閱，分布式跟蹤等提供抽象，需要應(yīng)用程序通過 SDK/HTTP/gRPC 顯式調(diào)用 Dapr 能力，它是面向開發(fā)人員的開發(fā)框架。
Dapr 還非常年輕，還在快速迭代中，距離被廣大開發(fā)者和三方廠商所支持還有很長的路要走。但是 Dapr 給我們揭示出一個新的方向：通過關(guān)注點分離，讓開發(fā)者只需關(guān)注業(yè)務(wù)邏輯自身，而分布式架構(gòu)的系統(tǒng)關(guān)注下沉到基礎(chǔ)設(shè)施中實現(xiàn)；讓業(yè)務(wù)邏輯與外部服務(wù)解耦，避免廠商綁定；同時應(yīng)用和應(yīng)用運行時是兩個獨立的進程，通過標準化 API 進行交互、生命周期解耦，便于升級和迭代。
5.1 Serverless 的機遇與挑戰(zhàn)
在上一篇文章中，我們已經(jīng)對 Serverless 應(yīng)用基礎(chǔ)設(shè)施，如函數(shù)即服務(wù)（FaaS）， Serverless 容器做了介紹。本文談?wù)労瘮?shù)即服務(wù) FaaS 應(yīng)用在架構(gòu)方面的一些思考。
FaaS 的核心思維是：開發(fā)者不必關(guān)心基礎(chǔ)設(shè)施運維、容量規(guī)劃或者擴容縮容，只需為使用的云資源和服務(wù)付費既可。這個思考的背后是：讓開發(fā)者避免投入基礎(chǔ)設(shè)施的運維，盡可能復(fù)用現(xiàn)有的云服務(wù)能力，讓開發(fā)時間重新分配到對用戶有更有直接影響和價值的事情上，比如健壯的業(yè)務(wù)邏輯、能吸引用戶的界面及快速響應(yīng)、可靠的 API 上。
在軟件架構(gòu)層面中， FaaS 將復(fù)雜的業(yè)務(wù)邏輯拆解成一系列細粒度的函數(shù)，并通過事件驅(qū)動的方式觸發(fā)調(diào)用。函數(shù)之間是松耦合的，可以通過如下兩種典型的模式進行協(xié)同、組合：
Workflow Orchestration 工作流編排：以阿里云 Serverless 工作流為例，可以通過一個聲明式的業(yè)務(wù)流程來編排任務(wù)。這種方式簡化了開發(fā)和運行業(yè)務(wù)流程所需要的任務(wù)協(xié)調(diào)、狀態(tài)管理以及錯誤處理等繁瑣工作，讓開發(fā)者聚焦于業(yè)務(wù)邏輯開發(fā)。
Event Choreography 事件協(xié)調(diào)：函數(shù)服務(wù)之間通過事件交換消息，由事件總線等消息中間件來進行事件的轉(zhuǎn)發(fā)，并觸發(fā)其他函數(shù)執(zhí)行。下面是一個示例應(yīng)用場景，通過 EventBridge，將訂單，用戶通知、商家通知、接單、結(jié)單等基于函數(shù)實現(xiàn)的業(yè)務(wù)邏輯串聯(lián)在一起。這種方式更加靈活，系統(tǒng)的健壯性也更好。但是缺點是缺乏顯式的建模，開發(fā)和維護相對較復(fù)雜。
Serverless 具備很多優(yōu)勢, 比如：降低運維成本，提升系統(tǒng)安全性，提升研發(fā)效率，加速業(yè)務(wù)交付等等。然而 Serverless 還有一些不能回避的問題需要我們來做判斷：
成本管理：對于“Pay as you go”的收費模式的一個弱點是：無法準確預(yù)測具體會產(chǎn)生多少費用，這與許多組織預(yù)算管理的方式不同。 廠商鎖定：即使 Serverless 應(yīng)用基于開放的語言和框架，但是多數(shù)Serverless應(yīng)用還依賴一些非標準化的 BaaS（Backend as a Service）服務(wù)，如對象儲存、Key- Value 數(shù)據(jù)庫、認證、日志、和監(jiān)控等。 調(diào)試和監(jiān)控：與傳統(tǒng)應(yīng)用開發(fā)相比， Serverless 應(yīng)用的調(diào)試與監(jiān)控工具能力還不完善。良好的可觀測性是將 Serverless 計算的重要助力。 架構(gòu)復(fù)雜性：Serverless 開發(fā)者無需關(guān)注底層基礎(chǔ)設(shè)施的復(fù)雜性，但是應(yīng)用架構(gòu)的復(fù)雜性需要格外關(guān)注。事件驅(qū)動架構(gòu)和細粒度函數(shù)微服務(wù)，與傳統(tǒng)開發(fā)模式非常不同。大家需要根據(jù)業(yè)務(wù)需求和自己的技術(shù)能力，在合適的場景應(yīng)用，然后逐漸擴大應(yīng)用范圍。
關(guān)于典型的 Serverless 應(yīng)用架構(gòu)，大家可以參考《What a typical 100% Serverless Architecture looks like in AWS ! 》。
《Cloud Programming Simplified: A Berkeley View on Serverless Computing》也是深入了解 Serverless 計算的一個好的參考。
六、應(yīng)用運行時的敏捷進化
更快、更輕、更敏捷的應(yīng)用運行時技術(shù)是云原生計算的持續(xù)追求。
體積更小 - 對于微服務(wù)分布式架構(gòu)而言，更小的體積意味著更少的下載帶寬，更快的分發(fā)下載速度。 啟動速度更快 - 對于傳統(tǒng)單體應(yīng)用，啟動速度與運行效率相比不是一個關(guān)鍵的指標。原因是，這些應(yīng)用重啟和發(fā)布頻率相對較低。然而對于需要快速迭代、水平擴展的微服務(wù)應(yīng)用而言，更快的的啟動速度就意味著更高的交付效率，和更加快速的回滾，以及更快的故障恢復(fù)速度。 占用資源更少 - 運行時更低的資源占用，意味著更高的部署密度和更低的計算成本。
正因為此，Golang、Node.js、Python 等語言開發(fā)者在持續(xù)攀升，有幾個值得大家關(guān)注的技術(shù)：
在 Java 領(lǐng)域，GraalVM 已經(jīng)逐漸成熟。它是基于 HotSpot 上增強的一個跨語言的全棧虛擬機，支持眾多語言的運行平臺（包括 Java、Scala、Groovy、Kotlin、JavaScript、Ruby、Python、C、C++ 等）。GraalVM 允許您將程序提前編譯為本地可執(zhí)行文件。
與經(jīng)典 Java VM 相比，生成的程序具有更快的啟動時間和更低的運行時內(nèi)存開銷。Quarkus /Micronaut 等作為云原生定制的新一代 Java 框架，可以實現(xiàn)驚艷的啟動時間和資源開銷。更多分析可以參考 Java 的云原生進化。
WebAssembly 則是另外一個令人激動的技術(shù)。WebAssembly 作為一個面向現(xiàn)代 CPU 體系架構(gòu)設(shè)計的，安全的、可移植、高效率的虛擬機沙箱，可以在任何地方（服務(wù)器、瀏覽器、IoT 等等）、任何平臺（不同操作系統(tǒng)，不同 CPU 體系架構(gòu)下）安全運行應(yīng)用。WebAssembly System Interface（WASI）是來標準化 WebAssembly 應(yīng)用與系統(tǒng)資源的交互抽象，比如文件系統(tǒng)訪問，內(nèi)存管理，網(wǎng)絡(luò)連接等，提供類似 POSIX 這樣的標準 API 。
平臺開發(fā)商可以針對具體的操作系統(tǒng)和運行環(huán)境提供 WASI 接口不同的實現(xiàn)，可以在不同設(shè)備和操作系統(tǒng)上運行跨平臺的 WebAssembly 應(yīng)用。這可以讓應(yīng)用執(zhí)行與具體平臺環(huán)境實現(xiàn)解耦，使得應(yīng)用“Build Once, Run Anywhere”的理想逐漸形成現(xiàn)實。雖然目前 WebAssembly 已經(jīng)超越了瀏覽器的領(lǐng)域，但是其發(fā)展還在非常初期，期待社區(qū)共同推動。有興趣的同學(xué)可以看看WebAssembly 與 Kubernetes 雙劍合璧。
七、趨勢總結(jié)
云原生軟件架構(gòu)還在快速發(fā)展中，涉及的內(nèi)容也非常廣泛。上述內(nèi)容更多是個人總結(jié)、理解和判斷，期待與大家的交流和深入探討。
更多參考：
《Software Architecture Guide》：https://martinfowler.com/architecture/
《7 Missing Factors from 12-Factor Applications》：https://www.ibm.com/cloud/blog/7-missing-factors-from-12-factor-applications
《Principles for Microservice Design: Think IDEALS, Rather than SOLID》：https://www.infoq.com/articles/microservices-design-ideals/
《Software Architecture and Design InfoQ Trends Report—April 2020》：https://www.infoq.com/articles/architecture-trends-2020/
《Choreography vs Orchestration in the land of serverless》：https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/
掃描下方??海報中二維碼，輸入關(guān)鍵詞：job
請發(fā)送您的簡歷至：[email protected]