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