george miranda
業務對於service mesh微服務架構的討論熱度居高不下，很多人認為service mesh將是雲原生應用基礎設施解決方案的must，它在構建健壯微服務架構應用時的能量令人印象深刻。不過在人氣飆公升的同時，人們對於落地service mesh的確切價值仍有困惑，因此有必要深入了解什麼是service mesh以及它解決了哪些問題，以便我們確定是否真的需要service mesh。
service mesh是乙個用於處理服務之間通訊的基礎結構層，其體系結構的具體細節在不同實現中略有差異。一般來說，每個service mesh都是作為乙個系列(或「mesh」)實現的，這些相互連線的網路**設計允許我們更優雅地管理服務流量（service traffic）。
該解決方案隨著微服務架構的廣泛接受而興起，它引入了一種全新的通訊流量（communication traffic）概念。但不幸的是，採用者往往沒有做太多的考慮。這有時被歸因為南北流量模式與東西流量模式的區別。簡單來說，南北流量是server-to-client流量，而東西流量則是server-to-server流量。以上命名**於「對映」網路流量的關係圖，圖中通常用垂直線表示server-client流量，水平線表示server-to-server流量。在server-to-server流量世界裡，除了對網路和傳輸層(l3/l4)考量，在會話層（session layer）中還有乙個重要的差異要考慮。
在這個新的世界中，service-to-service通訊成為了應用在應用時行為的基本決定因素。應用函式在本地作為相同執行時的一部分出現，而不是以在不可靠的網路上傳輸的遠端過程呼叫出現。這意味著，反映業務需求的複雜決策樹（decision tree）的成功或失敗，現在需要您考慮分布式系統程式設計的現實。對於大多數人來說，這是乙個新的專業領域，需要建立並在**中編寫大量定製的工具。而service mesh，減輕了應用開發人員的負擔，將工具與應用分離開來，並將這種「責任」推到了基礎架構層。
使用service mesh，每個應用的endpoint(無論是容器、pod還是主機，無論如何在部署中設定這些endpoint)都被配置為「將通訊路由到本地**」(例如以sidecar容器形式安裝)。本地**公開了可以用於管理諸如重試邏輯、加密機制、自定義路由規則、服務發現等內容的原語。這些**的集合構成了乙個「網格」服務，共享公共網路流量的管理屬性。這些**可以從乙個集中的控制平面進行控制，操作人員可以在該控制平面中對影響整個網格行為的策略加以組合。
由於service-to-service的通訊是基於微服務的應用執行時行為的基本決定因素，能夠從sercice mesh中獲取價值的最明顯的地方是管理用於遠端過程呼叫(或api呼叫)的訊息。對比service mesh和其他訊息管理解決方案，如面向訊息的中介軟體、企業服務匯流排(esb)、企業應用程式整合模式(eai)或api閘道器，service mesh可能與其中的一些功能有輕微重疊，但是作為乙個整體，它面對的是乙個更大的問題集。
service mesh是作為基礎設施實現的，位於應用之外，因此應用不需要修改任何**就可以使用service mesh。service mesh的價值起初是在檢查rpc(或訊息)管理時實現的，隨後擴充套件到了所有入站和出站流量的管理。與直接將遠端通訊管理編碼到應用中不同，service mesh允許您更容易地跨整個分布式基礎設施管理該邏輯。
service mesh的核心是解決管理分布式系統帶來的固有挑戰。這並不是一格新的問題，但在微服務數量激增的情況下，越來越多使用者開始面對這些問題。而關於分布式系統，存在著一下謬誤——
網路是可靠的（the network is reliable）
延遲為零（latency is zero）
頻寬是無限的（bandwidth is infinite）
網路是安全的（the network is secure）
拓撲不會改變（topology does not change）
有一名管理員（there is one administrator）
傳輸成本為零（transport cost is zero）
網路是同質的（the network is homogenous）
這些錯誤往往會在大規模執行時出現，往往在發現時已經太晚了，不過好在，經過這麼多年的實踐，已經有了不少經過驗證的解決方案。
過去，應用開發人員通過在應用中直接建立自定義工具來解決這些問題：開啟乙個socket、傳輸資料、在某個特定的時間段內重新嘗試，當事務不可避免地需要終止時關閉socket，等等。分布式應用的程式設計負擔直接落在了每個開發人員的肩上，因此這樣做的邏輯與每個分布式應用緊密耦合。
作為實現可重用解決方案的漸進步驟，出現了網路彈性庫(如netflix的hystrix或twitter的finagle)。在我們的應用**中包含這些庫，現在您已經準備好了一組預先開發的工具。雖然這些解決方案取得了令人難以置信的飛躍，但它們對多語言應用的價值有限。不同的程式語言需要不同的庫，然後我們會遇到管理兩者之間整合的挑戰。在這一模型中，不同應用endpoint之間的一致管理是乙個固有的挑戰。
對於service mesh，它旨在解決分布式系統程式設計的挑戰，這意味著我們需要首先搞明白乙個問題：我們應用基礎結構中，是否有許多服務彼此通訊？
當然，如果我們主要管理的是一體化架構應用，我們也可以從service mesh中獲得些許價值。
如果我們管理的是較小的服務，那麼處理分布式計算錯誤的工作不可避免。隨著微服務架構應用的發展，新特性通常作為附加的外部服務引入，我們對於service mesh的需求也將不斷增長。
service mesh的存在解決了可靠性(重試、超時、減輕級聯故障)、故障診斷(可觀察性、監視、跟蹤、診斷)、效能(吞吐量、延遲、負載平衡)、安全性(管理機密、確保加密)、動態拓撲(服務發現、自定義路由)以及在生產中管理微服務時常見的問題。
如果我們目前正在面臨這些問題，或者已經次啊用了雲原生和微服務架構，那麼我們應該研究一下service mesh工具，並確定它是否適用於我們的環境。想要避免被各種炒作迷亂了雙眼，我們應該量化service mesh的價值，而辦法就像我們剛才討論的那樣，關注這類工具的存在並探索它是否可以解決特定的問題。
rainbond是一款以應用為中心的開源paas，由好雨基於docker、kubernetes等容器技術自主研發，可作為公有雲或私有雲環境下的應用交付平台、devops平台、自動化運維平台和行業雲平台，或作為企業級的混合雲多雲管理工具、kubernetes容器管理工具或service mesh微服務架構治理工具。
github
碼雲文件
閱讀更多
我們真的需要服務描述嗎？
普遍認為，基於soap的web服務的主要複雜點之一是使用web服務描述語言 wsdl 進行服務介面的描述。william vambenepe指出wsdl的另一問題是，wsdl和隨之誕生的stub生成工具建立的分布式應用程式之間是緊密耦合的。人們開始意識到的是服務描述的問題，而不是如何改進它。u002...
蘋果手錶，我們真的需要你嗎？
一旦肯定了要 解救 的產物類別，蘋果就開端細心剖析它們的 死因 然後製造出有著完滿設計和完滿互動體驗的科技產物。蘋果的勝利之處在於它不只能使其所專注的產物類別復生，乃至還抹去了人們此前對該類別其他產物的記憶。蘋果總能製造出那些看似並不需求卻在人類生涯中發揚著巨集大感化的產物。就這一點而言，世界上沒有...
誰在吞我們的錢 我們真的需要信用卡嗎？
說實話，在中國的這麼多銀行的服務態度裡，我對招行還是比較滿意的，最起碼辦理業務不讓人窩火。但是服務歸服務，而商家的本質都是趨利的，這無可非議，但是你的盈利應該在公平合理的範圍之內，如果拋棄了這一原則，就是奸商！言歸正傳，相信各位裡用招行信用卡的不在少數，這和他們這幾年的營銷方式密不可分，幾乎在辦卡時...