我對雲原生軟件架構的觀察與思考

做者 | 易立  阿里雲資深技術專家

本系列文章：

• 第一篇 - 雲原生基礎設施 
• 第二篇 - 雲原生軟件架構
• 第三篇 - 雲原生應用交付與運維體系

前言

在《解讀雲原生基礎設施》一文中，咱們談到了雲原生計算包含三個維度的內容：雲原生基礎設施，軟件架構和交付與運維體系，本文將聚焦於軟件架構層面。

「Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. 」  - 維基百科

我的理解，軟件架構主要目標是解決下列挑戰：

• 控制複雜性：因爲業務的複雜性，須要咱們用更好的手段幫助研發組織克服認知障礙，更好的分工協做。分而治之，關注點分離等手段皆是如此。

• 應對不肯定性：業務在快速發展，需求在不斷變化。即便再完美的軟件架構，然而隨着時間的推移，團隊的變化，軟件架構的調整不可避免。讀《設計模式》，《微服務設計》等書字裏行間寫的都是「解耦」兩字，讓咱們關注架構中肯定性和不肯定性的分離，提高架構的穩定性和應變能力。

• 管理系統性風險：管理系統中的肯定性以及不肯定性風險，規避已知陷阱，對未知的風險作好準備。

雲原生應用架構的目標是構建鬆耦合、具有彈性、韌性的分佈式應用軟件架構，能夠更好地應對業務需求的變化和發展，保障系統穩定性，本文將分享一下在這個領域的觀察和思考。

緣起 - 12 要素應用

2012 年，Heroku 創始人 Adam Wiggins 發佈十二要素應用宣言。它爲構建一個優雅的互聯網應用，定義了須要遵循的一些基本原則和方法論，也普遍影響了衆多的微服務應用架構。十二要素重點關注：應用程序的健康成長，開發者之間的有效的協做，以及避免軟件架構腐化的影響。其內容在今天也值得每一個同窗認真體會。

圖片來源：https://12factor.net/zh_cn/

12 要素應用爲咱們提供了很好的架構指導，幫助咱們：

• 構建水平伸縮的彈性應用架構，更好支撐互聯網規模應用。

• 提高研發流程的標準化、自動化水平，提高研發效率。

• 減小開發環境和生產環境的差別，並使用持續交付實施敏捷開發。

• 提高應用的可移植性，適合雲化部署，下降資源成本和管理複雜性。

鬆耦合架構設計

微服務的核心理念是，系統中的各個服務可被獨立開發、獨立部署，獨立升級，各個服務之間是鬆耦合的。雲原生應用架構理念是進一步強調架構的鬆耦合，下降服務之間相互依賴的程度。

1. API 優先的應用架構設計

在面向對象的軟件架構中，最重要的是定義對象以及對象的接口契約。SOLID 原則是最被人廣爲熟知的設計原則：

• Single responsibility principle - 單一職責原則

• Open/closed principle - 開放/封閉原則

• Liskov substitution principle - 里氏替換原則

• Interface segregation principle - 接口隔離原則

• Dependency inversion principle - 依賴翻轉原則

將以上五個原則的英文首字母拼在一塊兒就是 SOLID 原則，這也是幫助咱們構建高內聚，低耦合、具有柔性的應用架構。在分佈式微服務應用架構中，API 優先是契約優先（Contract First）的天然拓展。

API 應該是被優先設計的：咱們知道用戶需求是複雜多變的，好比從桌面到移動端，應用的展示方式和操做流程都有可能不一樣；然而業務邏輯的概念模型和服務交互是相對穩定的。相對而言，API 的接口是更加穩定的，而具體的實現是能夠迭代實現和持續變化的。定義良好的 API 能夠更好保障應用系統的質量。

API 應該是聲明式，可描述/自描述的：經過規範化的描述，API 易於溝通、易於理解、易於驗證，簡化開發協同。支持服務的消費者和提供者並行開發，加速開發週期。支持不一樣的技術棧的實現，好比對於同一個 API 接口，其服務實現採用 Java 。前端應用可使用 JavaScript ，而服務器端應用可使用 Golang 進行服務調用等等。這樣可讓開發組織能夠根據本身的技能棧和系統要求靈活選擇合適的技術。

API 應該具有 SLA：API 做爲服務間的集成界面，與系統的穩定性息息相關。SLA 應該做爲 API 設計的一部分，而不是部署後再考慮。在分佈式系統中，穩定性風險無處不在，經過 API 優先的設計模式，咱們對獨立的服務進行穩定性架構設計、容量規劃；咱們還能夠對獨立的 API 進行故障注入、穩定性演練，來消除系統性的穩定性風險。

在 API 領域，最重要的趨勢是標準化技術的崛起。gRPC 是 Google 開源的的高性能、通用的、平臺無關的 RPC 框架。它採用分層設計，其數據交換格式基於 Protobuf  (Protocol Buffers) 協議開發，具有優秀的序列化/反序列化效率，也支持衆多開發語言。在傳輸層協議， gRPC 選擇了 HTTP/2，相較於 HTTP/1.1，其傳輸效率有了很大提高。此外 HTTP/2 做爲一個成熟的開放標準，具有豐富的安全、流控等能力，同時擁有良好的互操做性。gRPC 不只能夠用於 Server 端服務調用，也能夠支持瀏覽器、移動 App 和 IoT 設備與後端服務的交互。gRPC 在功能上已經具有完整的 RPC 能力，也提供了擴展機制來支持新的功能。

在 Cloud Native 的潮流下，跨平臺、跨廠商、跨環境的系統間互操做性的需求必然會催生基於開放標準的 RPC 技術，而 gRPC 順應了歷史趨勢，獲得了愈來愈普遍地應用。在微服務領域， Dubbo 3.0 宣佈了對 gRPC 協議的支持，將來咱們也會看到更多的微服務架構基於 gRPC 協議開發，並提供良好的多語言支持。此外，在數據服務領域，gPRC 也成爲一個優秀的選擇，你們能夠參考 Alluxio 的文章。

此外在 API 領域 Swagger (OpenAPI 規範)，GraphQL 都是你們值得關注的開放標準。你們根據本身的業務訴求靈活選用，本文再也不贅述。

2. Event Driven Architecture 的崛起

談事件驅動架構 （EDA - Event Driven Architecture），咱們首先來解釋一下什麼是事件。事件是指對已經發生的事情、狀態變化等的記錄。它們是不可變的（沒法更改或刪除），而且按其建立順序排序。相關各方能夠經過訂閱已發佈的事件來獲取有關這些狀態變化的通知，而後使用所選擇的業務邏輯根據這些信息採起操做。

事件驅動架構是一種構建鬆耦合的微服務系統的架構方式，微服務之間經過異步事件通訊來進行交互。

事件驅動架構實現了事件的生產者和消費者的完全解耦。生產者無需關注事件如何被消費，同時消費者無需關注事件的生產方式；咱們能夠動態添加更多消費者而不影響生產者，能夠增長消息中間件對事件進行動態路由和轉換。這還意味着事件的生產者和消費者沒有時序上的依賴，即便因爲應用宕機沒法及時處理消息，在從新恢復後，程序能夠繼續從消息隊列中獲取這些事件繼續執行。這樣的鬆耦合架構，爲軟件架構提供更高的敏捷性、靈活性和健壯性。

事件驅動架構的另外一個重要優勢是提高了系統的可伸縮性。事件生產者在等待事件消費時不會被阻塞，而且能夠採用 Pub/Sub 方式，讓多個消費者並行處理事件。

事件驅動架構還能夠完美地與 Function as a Service (FaaS) 相整合。事件觸發函數執行業務邏輯，在函數中也能夠編寫集成多個服務的「膠水代碼」，簡單、高效地構建事件驅動架構的應用。

可是 EDA 架構依然存在不少挑戰：

• 分佈式的鬆耦合架構大大增長了應用基礎設施的複雜性。基於雲的部署交付方式和雲服務（消息隊列、函數計算服務等）可使得該架構的穩定性，性能和成本效益進一步提升。

• 與傳統同步處理方式相比，異步事件處理存在與事件排序、冪等性、回調和異常處理相關的要求，總體設計難度更大一些。

• 在大多數狀況下，因爲缺少跨多個系統的分佈式事務支持，維護數據一致性是很是具備挑戰性的。開發者可能須要權衡可用性和一致性之間的關係。好比經過 Event Sourcing（事件溯源）實現最終一致性，查看詳情。

• 互操做性。在現實世界中，事件無處不在，然而不一樣生產者對事件的描述卻不盡相同。開發者但願不管事件是從哪裏發出，都可以以一致的方式構建事件驅動的應用程序。CloudEvents 是一種以通用、一致的方式描述事件數據的規範，由 CNCF Severless 工做組提出，提高了事件驅動應用的可移植性。目前，阿里雲 EventBridge、Azure Event Grid 等事件處理中間件，以及 Knative Eventing，阿里雲函數計算等 FaaS 技術已經提供了對 CloudEnvents 的支持。

因爲 EDA 自身架構的優勢，在互聯網應用架構，業務數據化和智能化、IoT 等場景有很是廣闊的前景。關於 EDA 的架構討論，不在此繼續展開。

面向交付的應用架構

在雲原生軟件架構中，咱們在設計階段不僅是關注軟件如何被構建，也須要以終爲始。關注如何合理設計和實現軟件，才能夠被更好地交付和運維。

1. 應用和運行環境解耦

在 12 要素應用中，應用和運行環境解耦就已經被提出。而 Docker 容器的出現則進一步增強了這個理念。容器是一種輕量化的應用虛擬化技術，容器之間共享操做系統內核，支持秒級啓動，Docker 容器鏡像是一個自包含的應用打包格式，將應用和其依賴（如系統庫、配置文件）等打包在一塊兒，在不一樣環境保持部署一致性。

容器能夠做爲 Immutable Infrastructure （不可變基礎設施）的基礎，提高應用交付的穩定性。不可變基礎設施是由 Chad Fowler 於 2013 年提出的構想：在這種模式中，任何基礎設施的實例（包括服務器、容器等各類軟硬件）一旦建立以後便成爲一種只讀狀態，不可對其進行任何更改。若是須要修改或升級某些實例，就是建立一批新的實例進行替換。這種模式的能夠減小了配置管理工做的負擔，保障系統配置變動和升級能夠可靠地重複執行，避免使人頭疼的配置漂移問題；易於解決部署環境間的差別，讓持續集成與持續部署過程變得更流暢；支持更好的版本管理，在部署出錯時可進行快速回滾。

Kubernetes 做爲容器的分佈式編排調度系統，進一步提高了容器應用的可移植性。K8s 經過一系列抽象如 Loadbalance Service / Ingress / CNI / CSI，幫助業務應用能夠屏蔽底層基礎設施的實現差別，靈活遷移。經過這樣的能力，咱們能夠實現工做負載在數據中心、邊緣計算和雲環境的動態遷移。

在應用架構中，咱們須要避免將靜態環境信息，好比 IP / mac 地址等與應用邏輯耦合。在微服務架構中，能夠利用 Zookeeper/Nacos 等實現服務的註冊發現；在 Kubernetes 中，咱們能夠經過 Service / Service Mesh 減小對服務端點 IP 的依賴。此外，對應用狀態的持久化也儘量經過分佈式存儲或者雲服務等實現，這樣能夠大大提高應用架構可伸縮性和自愈能力。

2. 自包含可觀測性

分佈式系統所面對的最大挑戰之一就是可觀測性。可觀測性能夠幫助咱們解系統當前的狀態，並做爲應用自愈，彈性伸縮和智能運維的基礎。

在雲原生架構中，微服務應用是自包含的，應該本身具有可觀測性，能夠方便地被系統進行管理和探查。首先是，應用應該具有自身健康狀態的可視化能力。

在 Kubernetes 中，業務應用能夠提供一個 liveness 探針，能夠經過 TCP、HTTP 或者命令行方式對應用就緒進行檢測。對於 HTTP 類型探針，Kubernetes 會定時訪問該地址，若是該地址的返回碼不在 200 到 400 之間，則認爲該容器不健康，會殺死該容器重建新的容器。

對於啓動緩慢的應用，爲了不在應用啓動完成以前將流量導入。Kubernetes 支持業務容器提供一個 readiness 探針，對於 HTTP 類型探針，Kubernetes 會定時訪問該地址，若是該地址的返回碼不在 200 到 400 之間，則認爲該容器沒法對外提供服務，不會把請求調度到該容器。

同時在新的微服務架構中已經內置了可觀測探針，好比在 SpringBoot 的 2.3 發佈了兩個新的 actuator 地址：/actuator/health/liveness 和 /actuator/health/readiness ，前者用做存活探針，後者用做就緒探針。業務應用能夠經過Spring系統事件機制來讀取、訂閱、修改 Liveness State 和 Readiness State ，這樣可讓 Kubernetes 平臺能夠作更加準確的自愈和流量管理。

參考更多信息

此外，應用可觀測性包含三個關鍵能力：日誌、監控與鏈路追蹤。

• Logging – 日誌（事件流）：用於記錄離散的事件，包含程序執行到某一點或某一階段的詳細信息。不但包括應用、 OS 執行過程的日誌，還應包含運維過程當中的日誌信息，如操做審計等。

• Metrics – 監控指標：一般是固定類型的時序數據，包括 Counter、Gauge、Histogram 等，是可聚合的數據。系統的監控能力是多層次的，既包含計算、存儲，網絡等基礎設施服務層次的監控指標，也應該包含業務應用的性能監控和業務指標監控。

• Tracing – 鏈路追蹤 - 記錄單個請求的完整處理流程，能夠爲分佈式應用的開發者提供了完整的調用鏈路還原、調用請求量統計、應用依賴分析等能力，可以幫助開發者快速分析和診斷分佈式應用架構下的性能和穩定性瓶頸。

在分佈式系統中，穩定性、性能、安全等問題可能發生在任何地方，須要全鏈路可觀測性能力保障，須要覆蓋基礎設施層、 PaaS 層，應用等不一樣層次，而且能夠在不一樣系統間實現可觀測性數據的關聯、聚合、查詢和分析。

軟件架構的可觀測領域具有廣闊的前景，也涌現出衆多的技術創新。2020 年 9 月 CNCF 發佈了雲原生可觀測性的技術雷達。

其中，Prometheus 已成爲企業首選的雲原生應用程序的開源監控工具之一。Prometheus 培養了一個活躍的開發者和用戶社區。在 Spring Boot 應用架構中，經過引入 micrometer-registry-prometheus 的依賴，既可讓應用的監控指標被 Prometheus 服務所採集。更多信息能夠參考文檔。

在分佈式追蹤領域，OpenTracing 是 CNCF 下屬的開源項目。它是一個技術中立的分佈式追蹤的規範，提供統一接口，可方便開發者在本身的服務中集成一種或多種分佈式追蹤的實現。Jaeger 是Uber 開源的分佈式追蹤系統，兼容 OpenTracing 標準，已經成功在 CNCF 畢業。此外OpenTelemetry是一個潛在的標準，它試圖在融合 OpenTracing 和 OpenCensus 這兩個項目，造成統一的技術標準。

對於不少遺留的業務系統，現有應用並不具有完備的可觀測性能力。新興的服務網格技術能夠成爲提高系統可觀測性的新方式。經過數據平面代理的請求攔截，網格能夠獲取服務間調用的性能指標。此外，在服務調用方應用中只需加入須要轉發的消息 header，在服務網格上便可得到完整的鏈路追蹤信息。這樣的方式極大簡化了可觀測性能力的建設，可讓現有的應用低成本融入雲原生可觀測性體系中。

阿里雲提供了豐富的可觀測性能力。XTrace 分佈式追蹤提供了對  OpenTracing/OpenTelemetry 標準的支持。ARMS 提供了託管 Prometheus 服務，可讓開發者無需關注系統的高可用和容量挑戰。可觀測性是 AIOps 的基礎，在將來企業IT應用架構中將扮演更加劇要的角色。

3. 面向失敗的設計 - Design For Failure

根據」墨菲定律「 — 「Anything that can go wrong will go wrong」。分佈式系統可能受到硬件、軟件等因素、或者內部和外部的人爲破壞。雲計算比自建數據中心提供了更高 SLA、更加安全的基礎設施，可是咱們在應用架構設計時依然要時刻關注系統的可用性，關注潛在的」黑天鵝「風險。

系統化的穩定性須要在軟件架構，運維體系和組織保障等方面全局考慮。在架構層面，阿里經濟體有着很是豐富的經驗，好比防護式設計、限流、降級、故障隔離等，並且也向社區貢獻了 Sentinel、ChaosBlade 等優秀的開源項目。

本文，咱們將會談談幾個在雲原生時代能夠進一步思考的地方。我的的總結是 「Failures can and will happen, anytime, anywhere. Fail fast, fail small, fail often and recover quickly.」

首先是「Failures can and will happen」，咱們須要提高服務器的可替換性。在業界有一個很是流行的隱喻：「Pets vs. Cattle」，寵物和家畜。咱們面對一個架構選擇：對於應用所在服務器咱們是須要精心伺候，防止系統宕機，出現問題後不惜一切代價搶救 （Pet）；仍是傾向於出現問題後，能夠經過簡單拋棄和替代進行恢復（Cattle）。雲原生架構的建議是：容許失敗發生，確保每一個服務器，每一個組件都可以在不影響系統的狀況下發生故障而且具有自愈和可替代能力。這個設計原則的基礎是應用配置和持久化狀態與具體運行環境的解耦。Kubernetes 的自動化運維體系讓服務器的可替換性變得更加簡單。

**此外是 「Fail fast, fail small, recover quickly」 **。當即失效（Fail fast）是一個很是反直覺的設計原則，它背後的哲學是既然故障沒法避免，問題越及早暴露、應用越容易恢復，進入生產環境的問題就越少。採用了 Fail-fast 策略之後，咱們的關注點將從如何窮盡系統中的問題轉移到如何快速地發現和優雅處理失敗。只要跑的夠快，故障就追不上我。:-) 在研發流程上，經過集成測試儘量在早期發現應用存在的問題。在應用級別，能夠採用斷路器（Circuit Breaker）等模式防止一個依賴服務的局部故障引發全局問題；此外經過 K8s 的健康監測、可觀測性能夠實現對應用故障的探知，經過服務網格的斷路器功能，能夠將故障發現、流量切換和快速自愈這些能力外置到應用實現以外，由系統能力保障。Fail small 的本質在於控制故障的影響範圍——爆炸半徑。這個原則在架構設計和服務設計上都須要咱們持續關注。

最後是「Fail often」，混沌工程是一種在生產環境週期性引入故障變量，驗證系統對非預期故障防護的有效性的思想。Netflix 引入混沌工程概念解決微服務架構的穩定性挑戰，也獲得了衆多互聯網公司的普遍應用。在雲原生時代又有了更多新的手段，Kubernetes 讓咱們能夠輕鬆注入故障，殺死 pod，模擬應用失效和自愈過程。利用服務網格咱們能夠對服務間流量進行更加複雜的故障注入，好比 Istio 能夠模擬緩慢響應、服務調用失敗等故障場景，幫助咱們驗證服務間的耦合性，提高系統的穩定性。

更多關於交付和運維架構的更多穩定性思考，咱們會在下一篇文章中和你們分享。

應用基礎設施能力下沉

雲原生軟件架構的重要目標讓開發者關注業務邏輯，讓平臺去承載系統複雜性。雲原生計算從新定義了應用與應用基礎設施的邊界，進一步提高了開發效率，下降了分佈式應用開發的複雜性。

1. 服務治理能力與業務邏輯解耦

在微服務時代，以 Spring Cloud 與 Apache Dubbo 爲表明的應用框架取得了巨大的成功，它們經過代碼庫方式提供了服務通訊、服務發現和服務治理能力（流量轉移、熔斷、限流、全鏈路追蹤等）。這些代碼庫被構建在應用程序自己中，隨着應用一塊兒發佈和維護。這樣的架構存在一些沒法迴避的挑戰：

• 侵入性：服務治理本質是橫向的系統級關注，是與業務邏輯正交的。但在現有微服務框架中，其實現方式和生命週期與業務邏輯耦合在一塊兒的。服務治理能力的加強須要微服務框架的升級，會致使整個系統全部組件的從新構建和部署，致使升級和維護成本提高。

• 實現綁定：因爲微服務框架代碼庫一般由特定語言實現，難以支持多語言（polyglot）實現。隨着業務的快速發展，異構系統之間的集成逐漸成爲挑戰。

圖片出處

爲了解決上述挑戰，社區提出了 Service Mesh（服務網格）架構，它將業務邏輯與服務治理能力解耦。下沉到基礎設施，在服務的消費者和提供者兩側以獨立進程的方式部署。這樣既達到了去中心化的目的，保障了系統的可伸縮性；也實現了服務治理和業務邏輯的解耦，兩者能夠獨立演進不相互干擾，提高了總體架構演進的靈活性；同時服務網格架構減小了對業務邏輯的侵入性，下降了多語言支持的複雜性。

Google、IBM、Lyft 主導發起的 Istio 項目就是服務網格架構的一個典型的實現，也成爲了新的現象級「網紅」項目。

上圖是 Istio 的架構，邏輯上分爲數據平面和控制平面。數據平面負責服務之間的數據通訊。應用和以 sidecar 方式部署的智能代理 Envoy 成對出現。其中由 Envoy 負責截獲和轉發應用網絡流量，收集遙測數據而且執行服務治理策略。在最新的架構中， istiod 做爲控制平面中負責配置的管理、下發、證書管理等。Istio 提供了一系列通用服務治理能力，好比：服務發現和負載均衡、漸進式交付(灰度發佈)、混沌注入與分析、全鏈路追蹤和零信任網絡安全等。能夠供上層業務系統將其編排到本身的 IT 架構和發佈系統之中。

服務網格在架構上實現了數據平面與控制平面的分離，這是一個很是優雅的架構選擇。企業客戶對數據平面有着多樣化的需求，好比支持等多樣化協議（如 Dubbo），須要定製化的安全策略和可觀測性接入等。服務控制平面的能力也是快速變化的，好比從基礎的服務治理到可觀測性，再到安全體系、穩定性保障等等。可是控制平面與數據平面之間的 API 是相對穩定的。

CNCF 創建了通用數據平面 API 工做組（Universal Data Plane API Working Group / UDPA-WG)，以制定數據平面的標準 API。通用數據平面 API（UDPA）的目標是：爲 L4/L7 數據平面配置提供實現無關的標準化 API，相似於 OpenFlow 在 SDN 中對 L2/L3/L4 所扮演的角色。UDPA API 涵蓋服務發現、負載均衡、路由發現、監聽器配置、安全發現、負載報告、運行情況檢查委託等。

UDPA API 基於現有的 Envoy xDS API 逐步演進，目前除支持 Envoy 以外，將支持客戶端負載均衡實現 (好比 gRPC-LB)，更多數據平面代理，硬件負載均衡和移動客戶端等等。

咱們知道 Service Mesh 不是銀彈，其架構選擇是經過增長一個服務代理來換取架構的靈活性和系統的可演化性，可是也增長了部署複雜性（sidecar 管理）和性能損失（增長兩跳）。UDPA 的標準化和發展將給服務網格架構帶來的新一次變化。

gRPC 在最新版本中提供了對 UDPA 負載均衡的初步支持。

「proxyless」 服務網格概念浮出水面，一個概念示意圖以下：

gRPC 應用直接從控制平面獲取服務治理的策略， gPRC 應用之間直接通訊無需額外代理。這個能夠看到開放的服務網格技術的雄心，進化成爲一套跨語言的服務治理框架，能夠兼顧標準化、靈活性與運行效率。Google 的託管服務網格產品已經率先提供了對 「proxyless」 gRPC 應用的支持。

2. 新一代分佈式應用運行時

對於分佈式應用，Bilgin Ibryam 在 Multi-Runtime Microservices Architecture。

文中分析並總結了典型的四大類需求：

• 生命週期（Lifecycle）

• 網絡（Networking）

• 狀態（State）

• 捆綁（Binding）

熟悉傳統企業架構的同窗可能發現，傳統的 Java EE (如今更名爲 Jakarta EE )應用服務器的目標也是解決相似的問題。一個典型 Java EE 應用服務器的架構以下圖所示：應用生命週期由各類應用容器管理，如 Web 容器、EJB 容器等。應用的安全管理、事務管理、鏈接池管理都是交給應用服務器完成。應用能夠經過 JDBC 、JMS 等標準 API 接口訪問外部的企業中間件，如數據庫、消息隊列等。

不一樣的外部中間件經過 Java Connector Architecture 規範實現與應用服務器的插拔。應用經過 JNDI 在運行時實現與具體資源的動態綁定。Java EE 將系統的 cross-cutting concern下沉到應用服務器來解決，讓開發者只關注應用的業務邏輯，開發效率有了較好的提高；同時減輕應用對環境和中間件實現的依賴，好比能夠在開發環境中用 ActiveMQ ，在生產環境中使用 IBM MQ 替換，而無需修改應用邏輯。

在架構上，Java EE 是一個大的單體應用平臺，拖慢了自身架構迭代的速度，跟不上時代的變化。因爲 Java EE 過於複雜、沉重，在微服務興起以後已經被大多數開發者所遺忘。

在雲原生的時代，咱們到底須要什麼樣的應用運行時？

Dapr 是微軟給出的答案。Dapr 是一個事件驅動的，可移植的，構建微服務應用的運行時環境。支持應用在雲或邊緣部署，支持語言與框架的多樣性。Dapr 利用 Sidecar 的模式，把應用邏輯中的一些橫切關注點需求（Cross-cutting）分離和抽象出來，從而達到應用與運行環境的解耦以及對外部依賴（包括服務之間）的解耦。

Dapr 的功能和定位如上圖所示：

• 最底下基礎設施是各類雲平臺或者邊緣環境。

• 其上是 Dapr 運行時和「building block」 (構件)。Dapr 構件解耦了外部服務和服務的消費者，能夠按需加載。構件以統一的 HTTP/gPRC API 爲應用層提供服務訪問。咱們能夠將外部服務從 Amazon DyanamoDB 切換爲 Azure ComosDB，上層應用無需修改任何代碼。Dapr 運行時做爲一個獨立的 sidecar 進程，獨立於應用邏輯。

• 應用經過輕量化的 SDK 來簡化對構件 API 的調用，基於 gRPC/HTTP 開放協議能夠輕鬆支持多語言。

儘管 Dapr 和 Service Mesh 在架構上有些相似，服務治理功能有所重疊，但二者在本質上卻大有不一樣。服務網格對應用是透明的基礎設施；而 Dapr 爲狀態管理，服務調用和故障處理，資源綁定，發佈/訂閱，分佈式跟蹤等提供抽象，須要應用程序經過 SDK/HTTP/gRPC 顯式調用 Dapr 能力，它是面向開發人員的開發框架。

Dapr 還很是年輕，還在快速迭代中，距離被廣大開發者和三方廠商所支持還有很長的路要走。可是 Dapr 給咱們揭示出一個新的方向：經過關注點分離，讓開發者只需關注業務邏輯自身，而分佈式架構的系統關注下沉到基礎設施中實現；讓業務邏輯與外部服務解耦，避免廠商綁定；同時應用和應用運行時是兩個獨立的進程，經過標準化 API 進行交互、生命週期解耦，便於升級和迭代。

1. Serverless 的機遇與挑戰

在上一篇文章中，咱們已經對 Serverless 應用基礎設施，如函數即服務（FaaS）， Serverless 容器作了介紹。本文談談函數即服務 FaaS 應用在架構方面的一些思考。

FaaS 的核心思惟是：開發者沒必要關心基礎設施運維、容量規劃或者擴容縮容，只需爲使用的雲資源和服務付費既可。這個思考的背後是：讓開發者避免投入基礎設施的運維，儘量複用現有的雲服務能力，讓開發時間從新分配到對用戶有更有直接影響和價值的事情上，好比健壯的業務邏輯、能吸引用戶的界面及快速響應、可靠的 API 上。

在軟件架構層面中， FaaS 將複雜的業務邏輯拆解成一系列細粒度的函數，並經過事件驅動的方式觸發調用。函數之間是鬆耦合的，能夠經過以下兩種典型的模式進行協同、組合：

• Workflow Orchestration 工做流編排：以阿里雲 Serverless 工做流爲例，能夠經過一個聲明式的業務流程來編排任務。這種方式簡化了開發和運行業務流程所須要的任務協調、狀態管理以及錯誤處理等繁瑣工做，讓開發者聚焦於業務邏輯開發。

• Event Choreography 事件協調：函數服務之間經過事件交換消息，由事件總線等消息中間件來進行事件的轉發，並觸發其餘函數執行。下面是一個示例應用場景，經過 EventBridge，將訂單，用戶通知、商家通知、接單、結單等基於函數實現的業務邏輯串聯在一塊兒。這種方式更加靈活，系統的健壯性也更好。可是缺點是缺少顯式的建模，開發和維護相對較複雜。

Serverless 具有不少優點, 好比：下降運維成本，提高系統安全性，提高研發效率，加速業務交付等等。然而 Serverless 還有一些不能迴避的問題須要咱們來作判斷：

成本管理：對於「Pay as you go」的收費模式的一個弱點是：沒法準確預測具體會產生多少費用，這於許多組織預算管理的方式不一樣。

廠商鎖定：即便 Serverless 應用基於開放的語言和框架，可是多數Serverless應用還依賴一些非標準化的 BaaS（Backend as a Service）服務，如對象儲存、Key- Value 數據庫、認證、日誌、和監控等。

調試和監控：與傳統應用開發相比， Serverless 應用的調試與監控工具能力還不完善。良好的可觀測性是將 Serverless 計算的重要助力。

架構複雜性：Serverless 開發者無需關注底層基礎設施的複雜性，可是應用架構的複雜性須要格外關注。事件驅動架構和細粒度函數微服務，與傳統開發模式很是不一樣。你們須要根據業務需求和本身的技術能力，在合適的場景應用，而後逐漸擴大應用範圍。

關於典型的 Serverless 應用架構，你們能夠參考《What a typical 100% Serverless Architecture looks like in AWS ! 》。

《Cloud Programming Simplified: A Berkeley View on Serverless Computing》也是深刻了解 Serverless 計算的一個好的參考。

應用運行時的敏捷進化

更快、更輕、更敏捷的應用運行時技術是雲原生計算的持續追求。

• 體積更小 - 對於微服務分佈式架構而言，更小的體積意味着更少的下載帶寬，更快的分發下載速度。

• 啓動速度更快 - 對於傳統單體應用，啓動速度與運行效率相比不是一個關鍵的指標。緣由是，這些應用重啓和發佈頻率相對較低。然而對於須要快速迭代、水平擴展的微服務應用而言，更快的的啓動速度就意味着更高的交付效率，和更加快速的回滾，以及更快的故障恢復速度。

• 佔用資源更少 - 運行時更低的資源佔用，意味着更高的部署密度和更低的計算成本。

正由於此，Golang、Node.js、Python 等語言開發者在持續攀升，有幾個值得你們關注的技術：

在 Java 領域，GraalVM 已經逐漸成熟。它是基於 HotSpot 上加強的一個跨語言的全棧虛擬機，支持衆多語言的運行平臺（包括 Java、Scala、Groovy、Kotlin、JavaScript、Ruby、Python、C、C++ 等）。GraalVM 容許您將程序提早編譯爲本地可執行文件。

與經典 Java VM 相比，生成的程序具備更快的啓動時間和更低的運行時內存開銷。Quarkus /Micronaut 等做爲雲原生定製的新一代 Java 框架，能夠實現驚豔的啓動時間和資源開銷。更多分析能夠參考 Java 的雲原生進化。

WebAssembly 則是另一個使人激動的技術。WebAssembly 做爲一個面向現代 CPU 體系架構設計的，安全的、可移植、高效率的虛擬機沙箱，能夠在任何地方（服務器、瀏覽器、IoT 等等）、任何平臺（不一樣操做系統，不一樣 CPU 體系架構下）安全運行應用。WebAssembly System Interface（WASI）是來標準化 WebAssembly 應用與系統資源的交互抽象，好比文件系統訪問，內存管理，網絡鏈接等，提供相似 POSIX 這樣的標準 API 。

平臺開發商能夠針對具體的操做系統和運行環境提供 WASI 接口不一樣的實現，能夠在不一樣設備和操做系統上運行跨平臺的 WebAssembly 應用。這可讓應用執行與具體平臺環境實現解耦，使得應用「Build Once, Run Anywhere」的理想逐漸造成現實。雖然目前 WebAssembly 已經超越了瀏覽器的領域，可是其發展還在很是初期，期待社區共同推進。有興趣的同窗能夠看看 WebAssembly 與 Kubernetes 雙劍合璧。

趨勢總結

雲原生軟件架構還在快速發展中，涉及的內容也很是普遍。上述內容更可能是我的總結、理解和判斷，期待與你們的交流和深刻探討。

更多參考：

• 《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/

阿里雲容器平臺團隊求賢若渴！社招技術專家/高級技術專家，base 杭州/北京/深圳。歡迎發簡歷到：jiaxu.ljx@alibaba-inc.com。

點擊連接當即查看容器服務 ACK：https://www.aliyun.com/product/kubernetes

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」