Istio 實踐手冊 ｜ 迎接新一代微服務架構

微服務是近些年來軟件架構中的熱名詞，也是一個很大的概念，不同人對它的理解都各不相同，甚至在早期微服務架構中出現了一批四不像的微服務架構產品，有人把單純引入 Spring Boot、Spring Cloud 等框架的應用服務也稱之爲微服務架構，但這卻只是將它作爲服務的 Web 容器而已。

隨着微服務的火熱，越來越多的團隊開始實踐，將微服務紛紛落地，並投入生產。但隨着微服務規模的不斷壯大，每增加一個微服務，就可能會增加一些依賴的基礎設施和第三方的配置，比如 Kafka 、Redis 實例等，相應 CI/CD 的配置也會增加或調整。同時隨着微服務數量增多、業務複雜性的提升及需求的多樣性等（如，對接第三方異構系統等），服務間通信的錯綜複雜，一步步地將微服務變得更加臃腫，服務治理也是難上加難，而這些問題在單體架構中是很容易解決的。爲此，有人開始懷疑當初微服務化是否是明智之選，甚至考慮迴歸到傳統單體應用。

正如下圖所示，PPT 中的微服務總是美好的，但現實中的微服務卻是一團糟糕，想甩甩不掉，越看越糟心。難道就沒有辦法了麼？

圖 2.1.1：現實中和 PPT 中的微服務對比

1、傳統微服務架構面臨的挑戰

面對上述暴露出的問題，並在傳統微服務架構下，經過實踐的不斷衝擊，面臨了更多新的挑戰，綜上所述，產生這些問題的原因有以下這幾點：

• 過於綁定特定技術棧。 當面對異構系統時，需要花費大量精力來進行代碼的改造，不同異構系統可能面臨不同的改造。

• 代碼侵入度過高。 開發者往往需要花費大量的精力來考慮如何與框架或 SDK 結合，並在業務中更好的深度融合，對於大部分開發者而言都是一個高曲線的學習過程。

• 多語言支持受限。 微服務提倡不同組件可以使用最適合它的語言開發，但是傳統微服務框架，如 Spring Cloud 則是 Java 的天下，多語言的支持難度很大。這也就導致在面對異構系統對接時的無奈，或選擇退而求其次的方案了。

• 老舊系統維護難。 面對老舊系統，很難做到統一維護、治理、監控等，在過度時期往往需要多個團隊分而管之，維護難度加大。

上述這些問題在傳統微服務架構中都是在所難免，我們都知道技術演進來源於實踐中不斷的摸索，將功能抽象、解耦、封裝、服務化。 隨着傳統微服務架構暴露出的這些問題，將迎來新的挑戰，讓大家紛紛尋找其他解決方案。

2、迎來新一代微服務架構

爲了解決傳統微服務面臨的問題，以應對全新的挑戰，微服務架構也進一步演化，最終催生了Service Mesh 的出現，迎來了新一代微服務架構，也被稱爲 “下一代微服務”。爲了更好地理解 Service Mesh 的概念和存在的意義，我們來回顧一下這一演進過程。

1.1 耦合階段

在微服務架構中，服務發現、負載均衡、熔斷等能力是微服務架構中重要的組成部分。微服務化之後，服務更加的分散，複雜度變得更高，起初開發者將諸如熔斷、超時等功能和業務代碼封裝在一起，使服務具備了網絡管控的能力，如下圖所示。

圖 2.1.2：耦合階段

這種方案雖然易於實現，但從設計角度來講卻存在一定的缺陷。

• 基礎設施功能（如，服務發現，負載均衡、熔斷等）和業務邏輯高度耦合。

• 每個微服務都重複實現了相同功能的代碼。

• 管理困難。如果某個服務的負載均衡發生變化，則調用它的相關服務都需要更新變化。

• 開發者不能集中精力只關注於業務邏輯開發。

1.2 公共庫 SDK

基於上面存在的問題，很容易會想到將基礎設施功能設計爲一個公共庫 SDK，讓服務的業務邏輯與這些公共功能降低耦合度，提高重複利用率，更重要的是開發者只需要關注公共庫 SDK 的依賴及使用，而不必關注實現這些公共功能，從而更加專注於業務邏輯的開發，比如 Spring Cloud 框架是類似的方式。如下圖所示：

圖 2.1.3：公共庫 SDK 階段

實際上即便如此，它仍然有一些不足之處。

• 這些公共庫 SDK 存在較爲陡峭的學習成本，需要耗費開發人員一定的時間和人力與現有系統集成，甚至需要考慮修改現有代碼進行整合。

• 這些公共庫 SDK 一般都是通過特定語言實現，缺乏多語言的支持，在對現有系統整合時有一定的侷限性。

• 公共庫 SDK 的管理和維護依然需要耗費開發者的大量精力，並需專門人員來進行管理維護。

1.3 Sidecar 模式

有了上面公共庫 SDK 的啓發，加上跨語言問題、更新後的發佈和維護等問題，人們發現更好的解決方案是把它作爲一個代理，服務通過這個透明的代理完成所有流量的控制。

這就是典型的 Sidecar 代理模式，也被翻譯爲 "邊車" 代理，它作爲與其他服務通信的橋樑，爲服務提供額外的網絡特性，並與服務獨立部署，對服務零侵入，更不會受限於服務的開發語言和技術棧，如下圖所示。

圖 2.1.4：Sidecar 模式階段

以 Sidecar 模式進行通信代理，實現了基礎實施層與業務邏輯的完全隔離，在部署、升級時帶來了便利，做到了真正的基礎設施層與業務邏輯層的徹底解耦。另一方面，Sidecar 可以更加快速地爲應用服務提供更靈活的擴展，而不需要應用服務的大量改造。Sidecar 可以實現以下主要功能：

• 服務註冊。 幫助服務註冊到相應的服務註冊中心，並對服務做相關的健康檢查。

• 服務路由。 當應用服務調用其它服務時，Sidecar 可以幫助從服務發現中找到相應的服務地址，完成服務路由功能。

• 服務治理。 Sidecar 可以完全攔截服務進出的流量，並對其進行相應的調用鏈跟蹤、熔斷、降級、日誌監控等操作，將服務治理功能集中在 Sidecar 中實現。

• 集中管控。 整個微服務架構體系下的所有服務完全可以通過 Sidecar 來進行集中管控，完成對服務的流控、下線等。

於是，應用服務終於可以做到跨語言開發、並更專注於業務邏輯的開發。

1.4 Service Mesh

把 Sidecar 模式充分應用於一個龐大的微服務架構系統，爲每個應用服務配套部署一個 Sidecar 代理，完成服務間複雜的通信，最終就會得到一個如下圖所示的網絡拓撲結構，這就是 Service Mesh，又稱之爲 “服務網格 “。

圖 2.1.5：Service Mesh 階段

至此，迎來了新一代微服務架構——Service Mesh，它將徹底解決了傳統微服務架構所面臨的問題。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/xsasCYzSY4hxXa3MQSuYbA