點擊上方“JavaEdge”，關注公衆號
微服務架構的缺陷
網絡通信
分佈式計算的8個謬論
Fallacies of Distributed Computing Explained：
網絡是可靠的
網絡延遲是0
帶寬是無限的
網絡是安全的
網絡拓撲從不改變
只有一個管理員
傳輸成本是0
網絡是同構的
爲啥會有這些明顯不符合現實的悖論呢？因爲我們開發人員就是這樣，很少考慮網絡問題，這都是我們開發時對網絡現狀的極度幻想！
管控服務間的通信
服務註冊、發現
路由，流量轉移
彈性能力（熔斷、超時、重試）
安全
可監控
Service Mesh演進史
遠古 - 控制邏輯和業務邏輯耦合
人們沒有形成對網絡控制邏輯的完整思路，導致總是在業務邏輯中添加一些網絡控制邏輯，導致邏輯耦合，代碼難以維護！
服務發現（Service discovery ）是自動找到滿足給定查詢請求的服務實例的過程。例如名爲Teams的服務需要查找將屬性環境設置爲生產的名爲Players的服務的實例。您將調用一些服務發現過程，該過程將返回合適的服務器列表。對於更多的整體架構，這是一個簡單的任務，通常使用DNS，負載均衡器以及一些關於端口號的約定來實現（例如，所有服務將其HTTP服務器綁定到端口8080）。
在更加分散的環境中，任務開始變得越來越複雜，以前可以盲目地依靠其DNS查找來找到依賴關係的服務現在必須處理諸如客戶端負載平衡，多個不同環境（例如，登臺與生產） ），地理位置分散的服務器等。如果之前只需要一行代碼來解析主機名，那麼現在您的服務就需要很多樣板代碼來處理更高版本所帶來的各種情況。
斷路器是Michael Nygard在他的書Release It中分類的一種模式。Martin Fowler對該模式的總結：
斷路器的基本原理非常簡單。將受保護的方法調用包裝在斷路器對象，該對象將監視故障。一旦故障達到閾值，斷路器將跳閘，並且所有對該斷路器的進一步調用都會返回錯誤，而根本不會進行受保護的調用。通常，如果斷路器跳閘，您還需要某種監視器警報。
這些非常簡單的設備可爲你的服務之間的交互增加更多的可靠性。但隨分佈水平提高，它們往往會變得更加複雜。系統中出現問題的可能性隨着分佈的增加而呈指數級增長，因此，即使諸如“斷路器跳閘時出現某種監視器警報”之類的簡單事情也不一定變得簡單明瞭。一個組件中的一個故障會在許多客戶端和客戶端的客戶端之間造成一連串的影響，從而觸發數千個電路同時跳閘。過去僅需幾行代碼，現在又需要樣板代碼來處理僅在這個新世界中存在的情況。
實際上，上面列出的兩個示例很難正確實現，以至於大型，複雜的庫（如Twitter的Finagle和Facebook的Proxygen）非常受歡迎，因爲它避免在每個服務中重寫相同邏輯。
公共庫
公共庫把這些網絡管控的功能整合成一個個單獨的工具包，獨立部署，解決了耦合。
該模型被大多數開創了微服務架構的組織所採用，例如Netflix，Twitter和SoundCloud。
好處
解耦
消除重複
但隨着系統中服務數量的增加，發現了此模型的
缺點
組織仍需要花費其工程團隊的時間來建立將庫與其他生態系統聯繫起來的粘合劑。有時，這筆費用是明確的，因爲工程師被分配到了專門負責構建工具的團隊中，但是價格標籤通常是不可見的，因爲隨着您花費時間在產品上工作，價格標籤會逐漸顯現出來
限制了可用於微服務的工具，運行時和語言。微服務庫通常是爲特定平臺編寫的，無論是編程語言還是運行時（如JVM）。如果組織使用的平臺不是庫支持的平臺，則通常需要將代碼移植到新平臺本身。這浪費了寶貴的工程時間。工程師不必再致力於核心業務和產品，而必須再次構建工具和基礎架構。這就是爲什麼諸如SoundCloud和DigitalOcean之類的中型組織決定僅支持其內部服務的一個平臺的原因，分別是Scala和Go
治理。庫模型可以抽象化解決微服務體系結構需求所需的功能的實現，但是它本身仍然是需要維護的組件。確保成千上萬的服務實例使用相同或至少兼容的庫版本並非易事，並且每次更新都意味着集成，測試和重新部署所有服務-即使該服務本身未遭受任何損害更改。
下一代架構
與我們在網絡棧中看到的類似，非常需要將大規模分佈式服務所需的功能提取到基礎平臺中。
人們使用HTTP等高級協議編寫應用程序和服務，而無需考慮TCP如何控制其網絡上的數據包。這種情況正是微服務所需要的，工程師可以專注業務邏輯，避免浪費時間編寫自己的服務基礎結構代碼或管理整個團隊中的庫和框架。
不幸的是，更改網絡棧以添加此層並不可行。
許多從業人員發現的解決方案是將其作爲一組代理來實現。即服務不會直接連接到其下游依賴，而是所有流量都將通過一小段軟件透明地添加所需的功能。
在該領域中最早記錄在案的發展使用了sidecar的概念。sidecar是在你的應用旁邊運行併爲其提供附加功能的輔助進程。2013年，Airbnb撰寫了有關Synapse和Nerve的開源文件，其中包括Sidecar的開源實現。一年後，Netflix推出了Prana，這是一種輔助工具，致力於允許非JVM應用程序從其NetflixOSS生態系統中受益。
sidecar
其實這種模式很早就出現了，比如 k8s 的 pod部署多個容器，其一就是處理日誌的filebeat，其本質就是個 sidecar，只不過我們一般都是部署一個處理網絡請求的 sidecar。
至此，已經很接近 service mesh 了。
儘管有許多此類開源代理實現，但它們往往旨在與特定的基礎結構組件一起使用。例如服務發現，Airbnb的Nerve＆Synapse假定服務已在Zookeeper中註冊，而對於Prana，則應使用Netflix自己的Eureka服務註冊表。
隨着微服務架構的日益普及，我們最近看到了新一輪的代理浪潮，這些代理足夠靈活以適應不同的基礎架構組件和偏好。這個領域的第一個廣爲人知的系統是Linkerd，它是由Buoyant根據工程師在Twitter微服務平臺上的先前工作創建的。很快，Lyft的工程團隊發佈了Envoy，它遵循類似的原則。
戰至終章 - Service Mesh
在這種模型中，你的每個服務都將有一個伴隨代理服務。鑑於服務僅通過Sidecar代理相互通信，因此我們最終得到了類似於下圖的部署，可以說就是 sidecar 的網絡拓撲組合。
Buoyant的首席執行官威廉·摩根（William Morgan）指出，代理之間的互連形成了網狀網絡（mesh network）。
2017年初，William爲該平臺編寫了一個定義，並將其稱爲Service Mesh：
服務網格是用於處理服務到服務通信的專用基礎結構層。它負責通過構成現代雲原生應用程序的複雜服務拓撲可靠地傳遞請求。實際上，服務網格通常被實現爲輕量級網絡代理的陣列，這些輕量級網絡代理與應用程序代碼一起部署，而無需瞭解應用程序。
他的定義中最有力的方面可能是，它擺脫了將代理視爲獨立組件的想法，並認識到它們形成的網絡本身就是有價值的東西。
你以爲結束了?其實才剛開始-Service Mesh V2
隨着組織將其微服務部署移至更復雜的運行時（如Kubernetes和Mesos），人們已開始使用這些平臺提供的工具來正確實現網狀網絡的想法。他們正從一組獨立工作的獨立代理轉移到一個適當的，有點集中的控制平面。
縱觀我們的鳥瞰圖，我們看到實際的服務流量仍然直接從代理流向代理，但是控制平面知道每個代理實例。控制平面使代理可以實現訪問控制和指標收集之類的事情，這需要合作：
最近開源的Istio項目是此類系統的最突出示例。
總結
全面理解ServiceMesh在大規模系統中的影響還爲時過早。總之這種方法有兩個好處
不必編寫定製軟件來處理微服務體系結構的最終商品代碼，這將使許多小型組織可以享受以前僅大型企業才能使用的功能，從而創建各種有趣的用例
這種體系結構可能使我們最終實現使用最佳工具/語言完成工作的夢想，而不必擔心每個平臺的庫和模式的可用性
參考
https://philcalcado.com/2017/08/03/pattern_service_mesh.html
https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
https://netflixtechblog.com/prana-a-sidecar-for-your-netflix-paas-based-applications-and-services-258a5790a015
https://buoyant.io/2020/10/12/what-is-a-service-mesh/
往期推薦
目前交流羣已有 800+人，旨在促進技術交流，可關注公衆號添加筆者微信邀請進羣
喜歡文章，點個“在看、點贊、分享”素質三連支持一下~
本文分享自微信公衆號 - JavaEdge（Java-Edge）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。