Service Mesh所應對的8項挑戰

Lori Macvittie

微服務架構是把雙刃劍，我們享受它帶來的開發速度（development velocity），卻也不得不面對服務間通訊帶來的複雜性問題。

目前大多數擴展容器化微服務的架構多是基於proxy-based複雜均衡器實現的。在這些架構的問題在於，容器環境內部伸縮往往依賴於IP tables，並受制於傳統網路層。

所有這些代理提供相同的核心功能：擴展容器環境中的分散式服務。這些服務是一種短暫的構建（ephemeral constructs），實際上並不存在——除了在定義它們的資源（配置）文件中。基於IP tables的擴展解決方案的問題是，這些服務是7層(HTTP)構造，通常充當單個API調用的「後端」，而非整個應用程序。

正如我們所知道的，從客戶端顯示為單個、整體構造的應用，實際上由許多不同的(和分散式的)微服務組成。有些服務是純內部的，供其他服務使用，這意味著要在容器環境中進行大量的service-to-service通信。

在這些環境中，一切都是HTTP/HTTP2之上的api，因此我們需要L7(HTTP)路由。我們還需要一致的安全、身份驗證和策略執行。所有這些都是基於IP tables的方法無法實現的。

針對種種微服務架構服務間通訊的問題和難點，目前出現的一些Service Mesh相關開源項目已經開始著手解決這些挑戰，核心集中於以下8個方面：

• 構建 - 除了將策略與CI/CD工具鏈集成並確保配置的聲明性模型，以便將service mesh視為一層基礎設施之外，構建並不是Service Mesh的「強項」
• 測試和集成 – Service Mesh可以幫助確保開發、測試、生產之間一致的策略。分階段部署這種方法在過去運作良好，但它是將延遲插入部署過程的障礙之一。企業正在尋找一種將服務直接部署到生產的方法，並採用流量控制和回滾機制來處理故障。
• 版本控制 - 服務網格可以作為基本API網關，根據API版本等變數路由流量，甚至可以翻譯版本，以便在API版本過渡期間提供幫助。客戶端升級並不總是強制的，這意味著會存在多個版本。Service Mesh可以將對舊API版本的請求轉換為最新版本，以幫助降低維護同一API的多個版本的成本和負擔。
• 部署 - 得益於HTTP能力，Service Mesh是實現藍/綠部署，金絲雀測試和流量控制的好方法。
• 日誌記錄 - 分散式日誌記錄始終是一個問題，而且在實例生存時變化很大的環境中，它會更加麻煩。Service Mesh提供了一個通用的集中位置來實現日誌記錄以及執行請求跟蹤等功能的能力。
• 監控 - 監控是應用擴展的核心之一。雖然應用可以通過實現某些功能（重試、斷路等）來處理服務不可避免的故障，但會給應用帶來不必要的負擔。Service Mesh承擔了service-to-service通信的負擔，並提供監控，其目標是在生產中專註於MTTD和MTTR，因為在生產中運行很困難，故障是不可避免的。
• 調試 - 系統越複雜，調試就越困難。Service Mesh可以幫助進行根本原因分析，使用分析和遙測提供統計數據和故障前通知，並隔離容器（而不是殺死容器），以便對其進行徹底檢查。這在由於內存泄漏緩慢導致故障的情況下特別有用。
• 網路 - 網路仍然是容器的關鍵，可能比在不太複雜的環境中更為重要。從該網路中抽象服務的願望意味著您不希望在每個服務中實現許多移動部件：服務發現、SSL和證書管理、斷路器、重試、健康監控等。引入需要包含與網路相關的功能會增加微服務，並引入額外的架構和技術債務。服務網格承擔了這些功能，並提供了所需的規模和安全性，而不影響開發。

Service mesh是一個令人興奮的演變，它結合了雲和容器的現代原則和堅實的規模基礎。隨著2018年以來容器技術的普以及對企業級應用擴展和支持的需求，Service Mesh的未來值得期待。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！