對於大多數人來說，Service Mesh仍然是一個相當新的概念，所以此時已經開始談及其歷史可能會有一點好笑。 但就目前而言，Linkerd已經在全球各地公司的生產環境執行超過18個月，這在雲原生應用中是一個很漫長的時間， 我們可以追溯其概念到2010年初創的網路公司。 所以肯定有歷史需要探索和理解。
然而，在深入討論之前，我們立足當下一段時間：什麼是Service Mesh？為什麼它突然成為熱門話題了？
Service Mesh是一個軟體基礎設施層，用於控制和監控微服務應用中的內部服務到服務的流量。它通常採用與應用程式程式碼一起部署的網路代理的“data plane”的形式，以及與這些代理互動的“control plane”。在這個模型中，開發人員（“service owners”）不知道Service Mesh的存在，而操作員（“platform engineers”）獲得了一套新的工具，以確保可靠性，安全性和可見性。
為什麼Service Mesh突然變得如此有趣？ 簡言之，對於許多公司來說，像Docker和Kubernetes這樣的工具已經“解決部署”問題——至少在第一次接近的情況下。 但他們還沒有解決執行時的問題。 這也正是Service Mesh引入的原因。
“解決部署”是什麼意思？ 使用像Docker和Kubernetes這樣的東西可以大大降低部署的運營負擔。 使用這些工具，部署100個應用程式或服務不再是部署單個應用程式的100倍。 這是一個巨大的進步，對於許多公司來說，這會大大降低採用微服務的成本。 這可能不僅僅是因為Docker和Kubernetes在所有正確的級別提供了強大的抽象，而且是因為它們在整個組織中對打包和部署的樣式進行了標準化。
但是，一旦這些應用程式是正在執行狀態——然後呢？ 畢竟，部署並不是生產的最後一步；該應用程式仍然需要執行。 所以問題就變成了：我們能否像Docker和Kubernetes標準化部署操作一樣來標準化我們的應用程式的執行時操作呢？
為瞭解答這個問題，我們轉向Service Mesh。 就其核心而言，Service Mesh提供統一的全域性方法來控制和測量應用程式或服務之間的所有請求流量（資料中心的說法是“東-西”流量）。 對於採用微服務的公司，這種請求流量在執行時行為中起著至關重要的作用。 由於服務透過響應傳入請求和發出傳出請求來工作，因此請求流成為應用程式在執行時的行為的關鍵決定因素。 因此，標準化這種流量的管理成為標準化應用執行時的工具。
透過提供API來分析和操作這種流量，Service Mesh為整個組織的執行時操作提供了一種標準化機制——包括確保可靠性、安全性和可視性的方法。 就像任何良好的基礎設施層一樣，Service Mesh（理想情況下）獨立於服務的構建方式工作。
那麼Service Mesh是如何誕生的呢？ 透過做一些軟體考古學，我們發現Service Mesh提供的核心功能——例如請求級負載平衡、斷路、重試、儀器等——並不是基本的新功能。 相反，Service Mesh最終是重新打包的功能；轉變為在哪裡的問題，而非是什麼的問題。
Service Mesh起源始於2010年左右應用架構三層模型的興起——一種簡單的架構，曾一度為網路上的絕大多數應用提供動力。 在這個模型中，請求流量扮演一個角色（有兩跳！），但它本質上是非常專業化的。 應用程式流量首先由“Web層”處理，然後與“應用層”進行對話，然後與“資料庫層”進行對話。Web層中的Web伺服器旨在處理大量傳入請求 非常迅速地將它們交給相對緩慢的應用程式伺服器。 （Apache，NGINX和其他流行的Web伺服器都具有用於處理這種情況的非常複雜的邏輯）。同樣，應用層使用資料庫庫與快取進行通訊。 這些庫通常以針對此用例進行最佳化的方式處理快取、負載平衡、路由、流量控制等。
到目前為止執行良好，但是這種樣式在重負載下開始崩潰——特別是在應用層，隨著時間的推移可能會變得相當大。 谷歌、Facebook、Netflix和Twitter等早期的網路規模公司學會了將整體拆分成許多獨立執行的元件，從而促成了微服務的興起。 引入微服務的同時，也引入了東-西的流向。 在這個世界上，溝通不再是專門制定的，而是在每一項服務之間都存在。 當它出錯時，該網站就宕機了。
這些公司都以類似的方式回應 ：他們寫了“胖客戶端”庫來處理請求流量。 這些例如谷歌的Stubby，Netflix的Hysterix，Twitter的Finagle的庫——為所有服務提供了統一的執行時操作方式。 開發人員或服務所有者可以使用這些庫向其他服務發出請求，並且在這些庫下，這些庫可以執行負載平衡、路由、斷路、遙測。 透過在應用程式中的每個服務中提供統一的行為，可見性和控制點，這些庫形成了錶面上是第一個Service Mesh的東西——並沒有花哨的名稱。
快速進入現代雲原生世界。 當然，這些庫仍然存在。 但是考慮到行程外代理提供的操作便利性，使用庫的吸引力明顯下降——尤其是在容器和協調器出現可能導致部署複雜性急劇下降的情況下。
代理避開了庫的許多缺點。 例如，當一個庫發生變化時，這些變化必須在每個服務中進行部署，這個過程往往需要進行複雜的組織。 相反，代理可以無需重新編譯和重新部署每個應用程式升級。 同樣，代理允許多語言系統，其中應用程式由服務組成，用不同的語言編寫——這對庫而言過於昂貴。
也許對於大型組織來說，最重要的是在代理伺服器實現Service Mesh而不是在庫中，它將提供執行時操作所必需功能的責任，並由這些功能的終端使用者掌握——平臺工程團隊。提供者和消費者的這種一致允許這些團隊擁有自己的命運，並將dev和ops之間的複雜依賴關係解耦。
這些因素都促成了Service Mesh的興起，這是一種為執行時操作帶來健全的手段。透過部署一個分散式代理的“網”，可以維護作為底層基礎設施的一部分，而不是應用程式本身，並且透過提供集中的API來分析和操作這種流量，Service Mesh為執行時操作提供了標準化的機制， 組織——包括確保可靠性，安全性和可視性的方法。
那麼，Service Mesh的下一步是什麼？在這一點上，我們已經花了18個月的時間來幫助組織採用Linkerd，我們已經瞭解到執行關鍵任務的本地雲應用程式中哪些是正確的，哪些是錯誤的。在下一篇文章中，我將探討一些具體的例子，並描述是什麼導致了一個全新的Service Mesh專案Conduit的開發，該專案專門針對Kubernetes。
原文連結：https://thenewstack.io/history-service-mesh/
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球