adf 關聯 com 方式 相互 基礎 增長 然而 加解密

1 背景 1.1 多語言 微服務理念是提倡不同業務使用最適合它的語言開發，現實情況也確實如此，尤其是AI的興起，一般大型互聯網公司存在 C/C++、Java、Golang、PHP、Python、NodeJs 等語言的項目，這就意味著每種語言都需要實現了相同功能服務框架。然而，服務框架的 SDK 通常實現都比較重，需要實現服務註冊與發現、服務路由、負載均衡、服務鑒權、服務降級、服務限流、網絡傳輸等功能，所以這塊的成本不言而喻。 1.2 產品交付 在伴隨著服務組件的功能升級，bug 修復過程中，業務系統需要升級依賴的服務組件包，升級中還可能存在各種版本沖突，而且灰度驗證過程也可能存在 bug，業務升級版本痛苦不堪，往往一個組件包想要全覆蓋升級，需要耗費相當長的時間，交付效率極其低下。隨著業務的不斷發展，業務的規模和我們交付的效率已經成為主要的矛盾，所以組件團隊期望以更高的效率去研發基礎設施，而不希望基礎設施的叠代受制於這個組件的使用規模。 1.3 雲原生 在雲原生架構裏，單個應用程序可能由數百個服務組成; 每個服務可能有數千個實例; 而且這些實例中的每一個都可能處於不斷變化的狀態，因為它們是動態調度一個像 Kubernetes 一樣的編排器。服務間通信不僅異常復雜，而且也是運行時行為的基礎。管理好服務間通信對於保證端到端的性能和可靠性來說是非常重要的。因此，管理好服務間通信對於保證端到端的性能和可靠性來說是非常重要的。 基於以上背景，Service Mesh 產生了。 2 是什麽 在上述背景下業界也做了一些探索，比如唯品會在服務調用方增加了 Proxy 層，將服務組件公共的邏輯功能放在 Proxy 中實現，剩下與業務交互的 API 功能放在 Client 中實現，這樣來降低多語言的成本。另外，新浪微博也使用 Proxy 方案提供小眾語言的服務註冊和調用的支持。其實這種 Proxy 結構類似現在的 Service Mesh，只是當時還沒有 Service Mesh 這個名詞。 在 2016 年 Buoyant 的 CEO William 提出了 Service Mesh 的概念。Service Mesh 是一種基礎設施層，主要處理服務間的通信，在復雜的雲原生服務拓撲中，負責請求的可靠傳遞。一般實現為網絡代理，通常與業務服務部署在一起，業務服務不感知。 3 能做什麽 3.1 服務發現 以微服務模式運行的應用變更非常頻繁，應用實例的頻繁增加減少帶來的問題是如何精確地發現新增實例以及避免將請求發送給已不存在的實例變得更加復雜。Service Mesh 可以提供簡單、統一、平臺無關的多種服務發現機制，如基於 DNS，K/V 鍵值對存儲的服務發現機制。 3.2 動態路由 隨著服務提供商以提供高穩定性、高可用性以及高 SLA 服務為主要目標，為了實現所述目標，出現各種應用部署策略盡可能從技術手段達到無服務中斷部署，以此避免變更導致服務的中斷和穩定性降低，例如：Blue/Green 部署、Canary 部署，但是實現這些高級部署策略通常非常困難。如果可以輕松的將應用流量從一個版本切到另外一個版本，更或者從一個數據中心到另外一個數據中心進行動態切換，甚至可以通過一個中心控制層控制多少比例的流量被切換。那麽 Service Mesh 提供的動態路由機制和特定的部署策略如 Blue/Green 部署結合起來，實現上述目標更加容易。 3.3 負載均衡 運行環境中微服務實例通常處於動態變化狀態，而且經常可能出現個別實例不能正常提供服務、處理能力減弱、卡頓等現象。但由於所有請求對 Service Mesh 來說是可見的，因此可以通過提供高級負載均衡算法來實現更加智能、高效的流量分發，降低延時，提高可靠性。 3.4 請求熔斷 動態的環境中服務實例中斷或者不健康導致服務中斷可能會經常發生，這就要求應用或者其他工具具有快速監測並從負載均衡池中移除不提供服務實例的能力，這種能力也稱熔斷，以此使得應用無需消耗更多不必要的資源不斷地嘗試，而是快速失敗或者降級，甚至這樣可避免一些潛在的關聯性錯誤。而 Service Mesh 可以很容易實現基於請求和連接級別的熔斷機制。 3.5 安全通訊 無論何時，安全在整個公司、業務系統中都有著舉足輕重的位置，也是非常難以實現和控制的部分。而微服務環境中，不同的服務實例間通訊變得更加復雜，那麽如何保證這些通訊是在安全、授權情況下進行非常重要。通過將安全機制如 TLS 加解密和授權實現在 Service Mesh 上，不僅可以避免在不同應用的重復實現，而且很容易在整個基礎設施層更新安全機制，甚至無需對應用做任何操作。 3.6 多語言支持 由於 Service Mesh 作為獨立運行的透明代理，很容易支持多語言。 3.7 多協議支持 同多語言支持一樣，實現多協議支持也非常容易。 3.8 Metric和鏈路追蹤 Service Mesh 對整個基礎設施層的可見性使得它不僅可以暴露單個服務的運行數據，而且可以暴露整個集群的運行數據。 3.9 重試 Service Mesh 的重試功能避免將其嵌入到業務代碼，同時最後期限使得應用允許一個請求的最長生命周期，而不是無休止的重試。 4 如何實現 Service Mesh 最終實現是使用 Sidecar 邊車部署方式，將服務發現，服務路由，負載均衡等功能實現在 Sidecar 內，Sidecar 作為一個單獨的進程與業務服務部署在同一個機器上。 Sidecar 內部的具體實現稱為數據平面，而作為 Sidecar 的控制邏輯，稱之為控制平面。 如上圖中，應用作為服務的發起方，只需要用最簡單的方式將請求發送給本地的服務網格代理，然後網格代理 Sidecar 會進行後續的操作，如服務發現，負載均衡等，最後將請求轉發給目標服務。當有大量服務相互調用時，它們之間的服務調用關系就會形成一種類似網格的形式。 Service Mesh 給基礎組件帶來了新的方向，可以通過 Service Mesh 的 Sidecar，將基礎組件的功能下層到 Sidecar 內，對業務透明，方便升級維護，並且解決多語言的問題。 5 優勢 5.1 多語言 由於 Service Mesh 共享了大部分的組件功能，所以在多語言實現上，更加簡單，各自的語言只需實現一些簡單的邏輯，就能提供的服務組件所有功能，從而大大降低多語言服務組件的實現成本。 5.2 產品交付 組件的大部分功能移至 Service Mesh 中，與業務邏輯隔離，可單獨進行升級，運維，對業務透明，提升了組件的交付能力。超越 Spring Cloud 和 Dubbo 等傳統開發框架之處在於不僅僅帶來了遠超這些框架所能提供的功能，更重要的是不需要應用程序為此做大量的改動， 開發人員也不必為上面的功能實現進行大量的知識儲備，降低學習服務組件的使用成本。 5.3 雲原生 在復雜的雲原生架構中，Service Mesh 能更好的管理服務間通信對於保證端到端的性能和可靠性來說是非常重要的。 6 問題 6.1 性能 Service Mesh 方式的服務調用，相比服務框架的直接調用，增加了與 Service Mesh 中 Sidecar 的交互，必然會犧牲部分性能，但由於是本地網絡通信，不經過網絡層傳輸，其性能損耗應該在可控範圍內。 6.2 可用性 Service Mesh 方式是通過單獨的本地進程來提供為應用程序提供服務，也就在整個服務調用鏈上增加了故障點，勢必會導致可用性下降，這就對 Service Mesh 的整體設計提出了更高的要求，來保證服務的可用性。 7 展望 有文章提到 Service Mesh 將是下一代服務架構，我們也期待 Service Mesh 更好的發展，給業務提升更多的便利，降低開發成本，提供更好的技術服務。 喜歡本文的同學，可以關註滌生的博客 《Hystrix系列之入門》 《Hystrix系列之執行原理分析》 《一次 Redis 內存詭異增長的排查過程》 《Java中如何實現線程的超時中斷》 《性能優化之拋棄Calendar》 《一次驚險的跳槽經歷（阿裏/美團/頭條/有贊...)》 《金三銀四跳槽季，Java面試大綱》 《一次動態代理的填坑之旅》 《JVM知識點掃盲系列（1）》 《JVM知識點掃盲系列（2）》 《如何優雅的處理Java異常，可以參考這些建議》 《談談服務限流算法的幾種實現》 《這幾招，讓服務的可用性提升到5個9》 《剖析定位系統問題，性能優化指南》

五分鐘了解 Service Mesh