《云計算與虛擬化技術叢書 Service Mesh實戰》—1Service Mesh簡介

第1章

Service Mesh簡介

在正式介紹Linkerd之前，我們將通過一章的內容了解一下Service Mesh的基本概念：它是如何產生的？能幫助解決微服務架構中什么樣的問題？業界已經提供哪些Service Mesh產品？基于本章的介紹，有助于讀者理解后續章節內容。

1.1　微服務架構面臨的一些挑戰

近年來，微服務架構隨著云計算技術的快速發展成為許多IT公司開發人員非常追捧和認可的一種架構設計，最主要的原因是微服務架構解決或避免了傳統單體架構所面臨的一些問題，例如下面這些。

單體應用代碼庫龐大，不易于理解和修改，尤其是對新人顯得更加明顯。

持續部署困難，由于單體應用各組件間依賴性強，只要其中任何一個組件發生更改，將重新部署整個應用，而頻繁的部署將增加服務宕機的風險，因此頻繁地進行部署幾乎不可能。

擴展應用困難，單體應用只能從一個維度進行擴展，即很容易通過增加實例副本提供處理能力。另一方面，單體應用各個組件對資源的使用情況需求不同，一些是CPU密集型，另一些是內存密集型，但是不能獨立地擴展單個組件。

阻礙快速開發，隨著公司業務的發展，單體服務框架變得更加龐大，更多的部門將會參與系統的開發，但是各個部門又不能獨立開發、維護相應的模塊，即使其中一個部門完成相應的更新，仍然不能上線，因此需要花費更多時間在部門間協調和統一。還有，需要增加新的功能時，單體應用最初的設計限制開發人員靈活選擇開發語言、工具等，導致新功能上線慢。

迫使開發人員長期專注于一種技術棧，由于單體應用本身設計的原因，后期引入新的技術棧需要遵循最開始的設計，因此存在非常大的局限性、挑戰性，否則可能需要重寫整個框架。

隨著業務的發展，傳統單體應用的問題越來越嚴重，解決和避免這些問題非常必要，而微服務架構正好可以很好地解決或避免部分問題，因此，開發人員也非常樂于擁抱微服務框架，逐漸將傳統的單體應用拆分成幾十或者幾百，甚至更多的微服務，如圖1-1所示。還有，云計算技術的快速發展比如容器技術使得開發和落地微服務更加便捷，也使得微服務框架成為業界非常熱門的開發框架。

圖1-1　單體應用和微服務

我們暫且不管拆分過程的復雜性及長期性，而重點考慮拆分后由多個微服務構建的復雜系統，系統中各個微服務之間彼此通過網絡進行通信，很好地解決了上述問題。但是，微服務是一枚萬能銀彈嗎？拆分成微服務后就萬事大吉了嗎？很顯然，這是不可能的。可以這么說，微服務架構一方面收之桑榆，另一方面又失之東隅，優點與缺點、得與失總是伴隨而生。其中最大的挑戰便是如何以標準化的方式管理微服務以及如何保證復雜網絡環境中微服務間的可靠通信，確保整個系統的最大可用性，提供盡可能高的SLA。其實業界已有很多關于如何在產線運行微服務的經驗分享，各家可能大同小異，相差不會太大。下面我們看Uber公司以什么樣的方式管理運行在產線上處理成千上萬請求的微服務，關于Uber的微服務管理經驗，Susan J. Fowler在他的著作《Microservices in Production》中有詳細的描述，我們將其總結為七點原則。

穩定性（Stability）：

穩定的部署周期

穩定的部署流程

穩定的引入和下架應用流程

可靠性（Reliability）：

部署過程可靠

盡可能規劃、減緩及保護依賴關系的失敗

可靠的服務路由和發現機制

擴展性（Scalability）：

盡可能地量化系統各種運行時的指標

確定系統資源瓶頸和需求

精心規劃系統的容量計劃

可擴展的流量處理

依賴組件擴展管理

可擴展的后端數據存儲

容錯及災難預防（Fault Tolerance and Catastrophe Preparedness）：

清楚地確定和規劃系統潛在災難和故障場景

避免系統單點故障

完善的故障檢測及修復流程

通過盡可能多、全面的代碼測試、負載測試及混沌測試（Chaos Testing）確保服務具有極強的彈性能力

謹慎管理系統流量，以備故障發生

快速有效地處理線上故障及宕機事件

性能（Performance）：

針對可用性定義合適的SLA

服務能快速有效地處理各種任務

充分利用系統資源

監控（Monitoring）：

快速準確地記錄和跟蹤系統運行狀態

設計良好的儀表盤有助于理解系統運行狀態及更加準確地反映服務的健康狀態

配備有效的、完善的、可操作的運維手冊處理各種線上報警

實施和維護可執行的oncall輪換機制

文檔（Documentation）

維護完整、有效的文檔系統，不斷積累和更新知識庫

根據人員、部門組織文檔系統，易于查詢及理解

從上面內容可知，在管理產線環境運行成百上千的微服務時，主要利用兩種手段，其一是完善的、執行力高的流程，其二是技術手段。兩者之中，可能某些方面完善的流程勝于技術手段，為系統服務的高可用性保駕護航，提供堅強的后臺支持。關于流程建設，這里不作介紹，因為每個公司對流程的制定千差萬別，而技術可能更具有普適性，那么在通過技術手段確保微服務的高可用性時，又有哪些技術手段可以提高微服務的可用性呢？由于拆分后的單體應用變成成百上千的分布在不同計算節點，構成一個龐大的分布式系統，它們之間通過網絡進行數據通信。說到實現分布式系統的高可用性時，不得不說L Peter Deutsch在Sun Microsystems工作時提出的關于分布式系統的謬誤（https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing）：

網絡是可靠的

網絡零延遲

網絡帶寬是無限的

網絡是安全的

網絡拓撲一成不變

系統只有一個管理員

傳輸代價為零

網絡是同質的

因此，在構建分布式系統時，最好盡可能地避免這些對分布式系統的錯誤認識。雖然清楚地認識這些謬誤對構建分布式系統非常重要，但是，諸多原因使得構建一個高可用、彈性的分布式系統仍然非常困難，比如：網絡不可靠、不可避免的系統依賴組件失敗、用戶行為的不可預知等。當然，這并不意味著構建高可用、彈性的分布式系統是不可能的。事實上，業界多年的技術積累及經驗總結，已經提出很多有助于提高系統可用性和彈性的通用型技術指南，那就是模式。可以說，模式在軟件工程中無處不在。以下是一些在構建分布式軟件或者普通軟件時的常用模式。

超時（Timeout）：超時使得如果訪問下游服務緩慢或失敗時，上游服務應快速失敗而不是無限或者長時間等待，以此避免級聯故障，隔離故障范圍。

重試（Retry）：重試有效地解決訪問服務時發生的間隙性故障，有助于減少服務恢復時間。

熔斷（Circuit Breaker）：熔斷機制避免將請求繼續發送給已經失敗或者不健康的下游服務處理，而是等待它們恢復，避免級聯故障。

健壯性測試（Resiliency Testing）：健壯性測試通過人為的方式向系統注入各種可能的故障，模擬網絡故障、延遲、依賴組件故障等，以此提前獲得一些未知錯誤并制定相應的處理方案。

限速節流（Rate-limiting and Throttling）：限速節流限定服務在固定的時間內只處理一定數量的請求，確保系統有足夠的能力優雅地處理其他請求，可避免峰值流量導致系統崩潰，與第三方系統集成時可以提供安全保障。

除此以外，還有許多技術可幫助實現分布式系統的高可用性，例如：

動態服務發現

負載均衡

運行時動態路由

安全通信

運行時指標及分布式追蹤

最后，強烈推薦大家閱讀Susan J. Fowler的著作《Microservices in Production》，其中詳細介紹如何在產線運行微服務。

接下來我們來看實現分布式系統的高可用性技術實現是如何演進的。

微服務 云計算 虛擬化

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。