Service Mesh所應對的8項挑戰

時間 2019-11-06

標籤 service mesh 應對挑戰简体版

原文原文鏈接

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

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

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

正如咱們所知道的，從客戶端顯示爲單個、總體構造的應用，實際上由許多不一樣的(和分佈式的)微服務組成。有些服務是純內部的，供其餘服務使用，這意味着要在容器環境中進行大量的service-to-service通訊。api

在這些環境中，一切都是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的將來值得期待。網絡

END -

關於Rainbond

Rainbond是一款以應用爲中心的開源PaaS，由好雨基於Docker、Kubernetes等容器技術自主研發，可做爲公有云或私有云環境下的應用交付平臺、DevOps平臺、自動化運維平臺和行業雲平臺，或做爲企業級的混合雲多雲管理工具、Kubernetes容器管理工具或Service Mesh微服務架構治理工具。架構