![1.png](https://ucc.alicdn.com/pic/developer-ecology/eefe3dac4b7945e7955704a4d0d085ec.png)

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

本系列文章：

- [第一篇 - 雲原生基礎設施 ](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495567&idx=1&sn=3a467fdbd9e5a9a578c0249d43dffc61&chksm=fae6e440cd916d56317a62d69b034f3061d56b204b1168540bd3b68dc579e99734e76efd1a25&scene=21#wechat_redirect)
- 第二篇 - 雲原生軟體架構
- 第三篇 - 雲原生應用交付與運維體系

# 前言

在[《解讀雲原生基礎設施》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495567&idx=1&sn=3a467fdbd9e5a9a578c0249d43dffc61&chksm=fae6e440cd916d56317a62d69b034f3061d56b204b1168540bd3b68dc579e99734e76efd1a25&scene=21#wechat_redirect)一文中，我們談到了雲原生計算包含三個維度的內容：雲原生基礎設施，軟體架構和交付與運維體系，本文將聚焦於軟體架構層面。

> “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 釋出十二要素應用宣言。它為構建一個優雅的網際網路應用，定義了需要遵循的一些基本原則和方法論，也廣泛影響了眾多的微服務應用架構。十二要素重點關注：應用程式的健康成長，開發者之間的有效的協作，以及避免軟體架構腐化的影響。其內容在今天也值得每個同學認真體會。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/473c135644b7471a80989e645ad39643.png)
圖片來源：[https://12factor.net/zh_cn/](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 作為服務間的整合介面，與系統的穩定性1息息相關。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 的文章](https://www.alluxio.io/blog/moving-from-apache-thrift-to-grpc-a-perspective-from-alluxio/)。

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

## 2. Event Driven Architecture 的崛起

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

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

事件驅動架構實現了事件的生產者和消費者的徹底解耦。生產者無需關注事件如何被消費，同時消費者無需關注事件的生產方式；我們可以動態新增更多消費者而不影響生產者，可以增加訊息中介軟體對事件進行動態路由和轉換。這還意味著事件的生產者和消費者沒有時序上的依賴，即使由於應用當機無法及時處理訊息，在重新恢復後，程式可以繼續從訊息佇列中獲取這些事件繼續執行。這樣的松耦合架構，為軟體架構提供更高的敏捷性、靈活性和健壯性。

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

事件驅動架構還可以完美地與 Function as a Service (FaaS) 相整合。事件觸發函式執行業務邏輯，在函式中也可以編寫整合多個服務的“膠水程式碼”，簡單、高效地構建事件驅動架構的應用。

但是 EDA 架構依然存在很多挑戰：

- 分散式的松耦合架構大大增加了應用基礎設施的複雜性。基於雲的部署交付方式和雲服務（訊息佇列、函式計算服務等）可以使得該架構的穩定性，效能和成本效益進一步提高。

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

- 在大多數情況下，由於缺乏跨多個系統的分散式事務支援，維護資料一致性是非常具有挑戰性的。開發者可能需要權衡可用性和一致性之間的關係。比如透過 Event Sourcing（事件溯源）實現最終一致性，[檢視詳情](https://martinfowler.com/eaaDev/EventSourcing.html)。

- 互操作性。在現實世界中，事件無處不在，然而不同生產者對事件的描述卻不盡相同。開發者希望無論事件是從哪裡發出，都能夠以一致的方式構建事件驅動的應用程式。[CloudEvents](https://cloudevents.io/) 是一種以通用、一致的方式描述事件資料的規範，由 CNCF Severless 工作組提出，提升了事件驅動應用的可移植性。目前，阿里雲 EventBridge、Azure Event Grid 等事件處理中介軟體，以及 Knative Eventing，阿里雲函式計算等 FaaS 技術已經提供了對 CloudEnvents 的支援。

由於 EDA 自身架構的優點，在網際網路應用架構，業務資料化和智慧化、IoT 等場景有非常廣闊的前景。關於 EDA 的架構討論，不在此繼續展開。

# 面向交付的應用架構

在雲原生軟體架構中，我們在設計階段不只是關注軟體如何被構建，也需要以終為始。關注如何合理設計和實現軟體，才可以被更好地交付和運維。

## 1. 應用和執行環境解耦

在 12 要素應用中，應用和執行環境解耦就已經被提出。而 Docker 容器的出現則進一步加強了這個理念。容器是一種輕量化的應用虛擬化技術，容器之間共享作業系統核心，支援秒級啟動，Docker 容器映象是一個自包含的應用打包格式，將應用和其依賴（如系統庫、配置檔案）等打包在一起，在不同環境保持部署一致性。

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

![3.gif](https://ucc.alicdn.com/pic/developer-ecology/734717f0e9f94bac94e00e7b226c9b8b.gif)

**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 之間，則認為該容器不健康，會殺死該容器重建新的容器。

![4.gif](https://ucc.alicdn.com/pic/developer-ecology/8e3d8ebe215b440590e731df288a2626.gif)

對於啟動緩慢的應用，為了避免在應用啟動完成之前將流量匯入。Kubernetes 支援業務容器提供一個 readiness 探針，對於 HTTP 型別探針，Kubernetes 會定時訪問該地址，如果該地址的返回碼不在 200 到 400 之間，則認為該容器無法對外提供服務，不會把請求排程到該容器。

![5.gif](https://ucc.alicdn.com/pic/developer-ecology/24eb19451dda4187a3a13f249c704c3d.gif)

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

[參考更多資訊](https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot)

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

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/36c28369a2ab4055829ac76253807f0a.jpg)

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

- **Metrics – 監控指標**：通常是固定型別的時序資料，包括 Counter、Gauge、Histogram 等，是可聚合的資料。系統的監控能力是多層次的，既包含計算、儲存，網路等基礎設施服務層次的監控指標，也應該包含業務應用的效能監控和業務指標監控。

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

在分散式系統中，穩定性、效能、安全等問題可能發生在任何地方，需要全鏈路可觀測效能力保障，需要覆蓋基礎設施層、 PaaS 層，應用等不同層次，並且可以在不同系統間實現可觀測性資料的關聯、聚合、查詢和分析。

軟體架構的可觀測領域具備廣闊的前景，也湧現出眾多的技術創新。2020 年 9 月 CNCF 釋出了[雲原生可觀測性的技術雷達](https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/)。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/2e802ee8d364446685993816715c76f2.png)

其中，Prometheus 已成為企業首選的雲原生應用程式的開源監控工具之一。Prometheus 培養了一個活躍的開發者和使用者社群。在 Spring Boot 應用架構中，透過引入 micrometer-registry-prometheus 的依賴，既可以讓應用的監控指標被 Prometheus 服務所採集。更多資訊可以參考[文件](https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html)。

在分散式追蹤領域，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）實現。隨著業務的快速發展，異構系統之間的整合逐漸成為挑戰。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/c0568f491b58401ebb4922900a16291b.jpg)
[圖片出處](https://philcalcado.com/2017/08/03/pattern_service_mesh.html)

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

Google、IBM、Lyft 主導發起的 Istio 專案就是服務網格架構的一個典型的實現，也成為了新的現象級“網紅”專案。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/5d5151826b9341aea428c31c8ddb13ed.png)

上圖是 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 負載均衡的[初步支援](https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md)。

“proxyless” 服務網格概念浮出水面，一個概念示意圖如下：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/6a019e62e9934161829f11969ef3509f.png)

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

## 2. 新一代分散式應用執行時

對於分散式應用，Bilgin Ibryam 在 [Multi-Runtime Microservices Architecture。](https://www.infoq.com/articles/multi-runtime-microservice-architecture/)

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

- 生命週期（Lifecycle）

- 網路（Networking）

- 狀態（State）

- 捆綁（Binding）

![11.png](https://ucc.alicdn.com/pic/developer-ecology/397342c541f74707967a5562391725dc.png)

熟悉傳統企業架構的同學可能發現，傳統的 Java EE (現在改名為 Jakarta EE )應用伺服器的目標也是解決類似的問題。一個典型 Java EE 應用伺服器的架構如下圖所示：應用生命週期由各種應用容器管理，如 Web 容器、EJB 容器等。應用的安全管理、事務管理、連線池管理都是交給應用伺服器完成。應用可以透過 JDBC 、JMS 等標準 API 介面訪問外部的企業中介軟體，如資料庫、訊息佇列等。

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

![12.png](https://ucc.alicdn.com/pic/developer-ecology/31960e1bb16b43b48ded8fb35a683567.png)

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

# 在雲原生的時代，我們到底需要什麼樣的應用執行時？

[Dapr](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496168&idx=1&sn=eff1f7277ab66cedb04e86da938ec582&chksm=fae6fa27cd917331b9cd3dee41958f3d29774d5209d27922955a1246123aff6e408e8c44920f&token=166883895&lang=zh_CN) 是微軟給出的答案。Dapr 是一個事件驅動的，可移植的，構建微服務應用的執行時環境。支援應用在雲或邊緣部署，支援語言與框架的多樣性。Dapr 利用 Sidecar 的模式，把應用邏輯中的一些橫切關注點需求（Cross-cutting）分離和抽象出來，從而達到應用與執行環境的解耦以及對外部依賴（包括服務之間）的解耦。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/8af2f3cebfb74758b0bea77971a4c8a8.png)

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 工作流為例，可以透過一個宣告式的業務流程來編排任務。這種方式簡化了開發和執行業務流程所需要的任務協調、狀態管理以及錯誤處理等繁瑣工作，讓開發者聚焦於業務邏輯開發。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/72e5148951b74b1b9299a119e85cd317.png)

- **Event Choreography 事件協調**：函式服務之間透過事件交換訊息，由事件匯流排等訊息中介軟體來進行事件的轉發，並觸發其他函式執行。下面是一個示例應用場景，透過 EventBridge，將訂單，使用者通知、商家通知、接單、結單等基於函式實現的業務邏輯串聯在一起。這種方式更加靈活，系統的健壯性也更好。但是缺點是缺乏顯式的建模，開發和維護相對較複雜。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/9db20228c9c94688912c8c7575de35c6.png)

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 ! 》。](https://medium.com/serverless-transformation/what-a-typical-100-serverless-architecture-looks-like-in-aws-40f252cd0ecb)

[《Cloud Programming Simplified: A Berkeley View on Serverless Computing》](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf)也是深入瞭解 Serverless 計算的一個好的參考。

# 應用執行時的敏捷進化

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

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

- 啟動速度更快 - 對於傳統單體應用，啟動速度與執行效率相比不是一個關鍵的指標。原因是，這些應用重啟和釋出頻率相對較低。然而對於需要快速迭代、水平擴充套件的微服務應用而言，更快的的啟動速度就意味著更高的交付效率，和更加快速的回滾，以及更快的故障恢復速度。

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

正因為此，Golang、Node.js、Python 等語言開發者在持續攀升，有幾個值得大家關注的技術：

在 Java 領域，[GraalVM](https://www.graalvm.org/) 已經逐漸成熟。它是基於 HotSpot 上增強的一個跨語言的全棧虛擬機器，支援眾多語言的執行平臺（包括 Java、Scala、Groovy、Kotlin、JavaScript、Ruby、Python、C、C++ 等）。GraalVM 允許您將程式提前編譯為本地可執行檔案。

與經典 Java VM 相比，生成的程式具有更快的啟動時間和更低的執行時記憶體開銷。[Quarkus](https://quarkus.io) /[Micronaut](https://micronaut.io/) 等作為雲原生定製的新一代 Java 框架，可以實現驚豔的啟動時間和資源開銷。更多分析可以參考 [Java 的雲原生進化](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486426&idx=1&sn=53fa57ced46da72d8235fbbcc1944183&scene=21#wechat_redirect)。

WebAssembly 則是另外一個令人激動的技術。WebAssembly 作為一個面向現代 CPU 體系架構設計的，安全的、可移植、高效率的虛擬機器沙箱，可以在任何地方（伺服器、瀏覽器、IoT 等等）、任何平臺（不同作業系統，不同 CPU 體系架構下）安全執行應用。WebAssembly System Interface（WASI）是來標準化 WebAssembly 應用與系統資源的互動抽象，比如檔案系統訪問，記憶體管理，網路連線等，提供類似 POSIX 這樣的標準 API 。

平臺開發商可以針對具體的作業系統和執行環境提供 WASI 介面不同的實現，可以在不同裝置和作業系統上執行跨平臺的 WebAssembly 應用。這可以讓應用執行與具體平臺環境實現解耦，使得應用“Build Once, Run Anywhere”的理想逐漸形成現實。雖然目前 WebAssembly 已經超越了瀏覽器的領域，但是其發展還在非常初期，期待社群共同推動。有興趣的同學可以看看 [WebAssembly 與 Kubernetes 雙劍合璧](https://www.infoq.cn/article/rEcOgQiurqaTyY7dJ6hA)。

# 趨勢總結

![16.png](https://ucc.alicdn.com/pic/developer-ecology/2f29f8906a954c9db0b546ff9e884905.png)

雲原生軟體架構還在快速發展中，涉及的內容也非常廣泛。上述內容更多是個人總結、理解和判斷，期待與大家的交流和深入探討。

**更多參考**：

- **《Software Architecture Guide》**：[https://martinfowler.com/architecture/](https://martinfowler.com/architecture/)

- **《7 Missing Factors from 12-Factor Applications》**：[https://www.ibm.com/cloud/blog/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/](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/](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/](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](https://www.aliyun.com/product/kubernetes)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496168&idx=1&sn=eff1f7277ab66cedb04e86da938ec582&chksm=fae6fa27cd917331b9cd3dee41958f3d29774d5209d27922955a1246123aff6e408e8c44920f&token=166883895&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

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

相關文章