溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“Service Mesh模式是怎么來的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Service Mesh模式是怎么來的”吧!
分布式系統幫助我們解決了很多過去甚至無法思考的用例，但同時也帶來了諸多新的問題。
當系統規模較小、架構較簡單時，開發者通過減少遠程交互數量來降低額外的復雜性。像處理分發的最安全方法是盡可能避免它，即使這意味著產生跨系統的重復邏輯和數據。
但現實情況是，從開始的幾臺大型中央計算機，到如今成百上千個小型服務，行業反戰的需求要求我們不得不作出突破。我們需要走出困境，解決不斷涌現的新挑戰和懸而未決的問題，先采取個案處理的臨時解決辦法，再用更復雜的辦法來應對。但我們不斷的解決問題、設計出更好的解決方案，解決那些最常見需求的模式、庫和平臺隨之出現。
起初，人們想要實現兩臺或多臺電腦之間的交互：
為最終用戶完成某個目標的服務對話。這顯然是一個過于簡化的視圖，因為在代碼操作的字節和通過電線發送和接收的電信號之間轉換的許多層都丟失了。但是，抽象概念對于我們的討論是足夠的。讓我們通過將網絡堆棧顯示為一個不同的組件來添加更多的細節:
通過一個服務與另一個服務對話以實現最終用戶的某個目標，這里我們把網絡堆棧加入進來：
上述模型從20世紀50年代以來一直被反復使用。一開始，計算機很少見而且價格昂貴，因此兩個節點之間的每條連接都會被精心設計和維護。然而隨著計算機越來越便宜、越來越流行，連接數量和數據量急劇增加，當人們越來月以來網絡系統，開發就必須確保所構建軟件符合用戶的服務質量要求。
想要達到與其水平，就需要解決很多問題，例如讓機器找到彼此、在一條線上處理多個并發連接、允許機器在不直接連接的情況下相互通信、在網絡間路由包、加密通信等等。
以流控制（flow control）為例。流控制本身是一種機制，阻止一臺服務器發送比下游服務器處理上限更多數據包。在網絡系統中，我們至少有兩臺獨立的計算機，它們彼此不太“了解”，因此流控制是必要的。計算機A以給定速率向計算機B發送字節，不能保證B將以足夠快、一致的的速度處理收到的字節。例如，計算機B可能正忙于并行運行其他任務，或者包可能會無序到達，而計算機B被阻塞等待應該首先到達的數據包。換句話說，計算機A不僅不具備計算機B所期望的性能，而且很可能會讓事情變得更糟，可能會使計算機B過載，而計算機B不得不排隊等待所有進入的數據包以進行處理。
曾經有一段時間，人們期望構建網絡服務和應用的人能夠處理他們編寫代碼中提出的上述挑戰。在我們的流控制示例中，意味著應用本身必須包含所需邏輯，以確保我們沒有用數據包重載服務。這種大量使用網絡的邏輯與業務邏輯并行。抽象圖如下所示：
幸運的是，隨著技術快速發展，出現了很多標準（如TCP/IP）可以將流控制或其他問題的解決方案集成到網絡堆棧中——代碼仍然存在，但已經從應用轉移到了操作系統提供的底層網絡層中。
但考慮到高性能和可靠性，很少有組織能說自己只使用商用操作系統附帶的TCP/IP堆棧來推動業務發展。
到如今，計算機已經無處不在，上述網絡堆棧也已經證明了自己是可靠連接系統的“事實上的”工具集。由于有了更多的節點和穩定的連接，業界開始使用各種類型的網絡系統，從細粒度的分布式代理和對象，到由更大但仍然重度分布的組件組成的面向服務的架構。
這種極端的分布帶來了許多有趣的高級用例和好處，但也帶來了一些挑戰。有些挑戰是全新的，而有些挑戰只是我們在討論原始網絡時討論過的高級版本。
在90年代，Peter Deutsch和他在Sun Microsystems的同事們編輯了“分布式計算的8個謬誤”，其中列出了人們在使用分布式系統時傾向于做出的一些假設。Peter的觀點是，這些在更原始的網絡架構或理論模型中可能是正確的，但在現代世界中并不正確:
網絡是可靠的（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）
將上述清單斥為“謬論”，意味著開發者不能忽視這些問題，必須明確地解決它們。
更復雜的是，轉向更加分布式的系統——我們通常稱之為微服務架構——在可操作性方面引入了新的需求。以下是我們必須處理的一些問題:
快速提供計算資源（Rapid provisioning of compute resources）
基本的監視（Basic monitoring）
快速部署（Rapid deployment）
容易提供存儲（Easy to provision storage）
容易接近邊緣（Easy access to the edge）
身份驗證/授權（Authentication/Authorisation）
標準化的RPC（Standardised RPC）
因此，盡管幾十年前開發的TCP/IP棧和通用網絡模型仍然是使計算機相互通信的強大工具，但更復雜的體系結構引入了另一層需求，而在這些架構中工作的開發者必須再次滿足這些需求。
例如，考慮服務發現和斷路器，這兩種技術用于解決上面列出的部分彈性和分布式挑戰。
歷史往往會重演，第一批基于微服務構建系統的組織遵循的策略與前幾代網絡計算機的策略非常相似，這意味著處理上述要求的責任放在了編寫服務的開發者身上。
服務發現是自動查找哪些服務實例滿足給定查詢的過程，例如名為Teams的服務需要查找名為Players的服務實例，并將屬性環境設置為production。我們將調用一些服務發現過程，該過程將返回合適服務器的列表。對于大多數一體化架構，這是一個簡單的任務，通常使用DNS、負載平衡器和一些端口號約定（例如所有服務將其HTTP服務器綁定到端口8080）。在分布式環境中，任務開始變得更加復雜，以前信任DNS查找依賴關系的服務現在必須處理諸如客戶端負載平衡、多個不同環境、地理位置分散的服務器等等問題。之前我們需要一行代碼解析主機名，而現在，我們的服務需要許多行樣板文件來處理更高版本引入的各種情況。
斷路器是邁克爾·尼加德提出的一種模式，Martin Fowler把該模式總結為：
斷路器背后的邏輯很簡單，在斷路器對象中包裝一個用于監視故障的受保護的函數調用。一旦故障達到某個閾值，斷路器就會跳閘，并且所有對斷路器的進一步調用都會返回錯誤，不會進行任何保護調用。通常情況下，我們還會需要一些對斷路器的檢測警報。
這樣簡單的設備可以為服務之間的交互增加更多可靠性。然而同樣的，隨著分布水平提高，它們往往會變得非常復雜，系統出現問題的可能性也隨之水漲船高，即使是“斷路器跳閘就會發出某種監控警報”這種小事也不簡單了。過去只需幾行代碼的東西現在需要大量的樣板來處理。
但坦白說，上面列出的這兩個例子很難正確地實現，這也是為什么像Twitter的Finagle和Facebook的Proxygen這樣復雜的大型庫會變得流行，用來避免在每個服務中重寫相同的邏輯。
上面所描述的模型被大多數開創性的微服務架構企業所采納，如Netflix、Twitter和SoundCloud，而隨著系統中的服務數量的增加，他們還偶然發現了這種方法的各種缺陷。
即使使用Finagle這樣的庫，企業仍然需要從其工程團隊中投入時間來構建連接庫和其他生態系統的“粘合劑”。按照SoundCloud和DigitalOcean的經驗，在一個100-250人的工程師組織中，遵循以上策略，需要將1/10的員工用于構建工具。當開發者被分配給專門負責構建工具的團隊時，這種成本是很明顯的，但更常見的情況是，一些不可見的隱性成本和時間成本。
第二個問題是，上述方法限制了微服務可以使用的工具、運行時和語言。微服務的庫通常是為特定平臺編寫的，無論是編程語言還是JVM之類的運行時。如果一個企業使用的平臺不是庫支持的平臺，那么它通常需要將代碼移植到新的平臺本身。開發者必須再次構建工具和基礎設施，而不是把精力放在核心業務和產品上。這就是為什么像SoundCloud和DigitalOcean這樣的中型組織決定只支持一個用于內部服務的平臺——scala和Go。
最后一個值得討論的問題是治理。庫模型可以抽象實現處理微服務架構需求所需的特性，但它本身仍然是一個需要維護的組件。確保數千個服務實例使用相同或至少兼容的庫版本并非易事，每一次更新都意味著集成、測試和重新部署所有服務——即使服務本身沒有任何變化。
與我們在網絡堆棧中看到的類似，將大規模分布式服務所需的特性提取到底層平臺是非常可取的。
人們使用更高級別的協議(如HTTP)編寫非常復雜的應用程序和服務，甚至不考慮TCP如何控制網絡上的數據包。這種情況正是微服務所需要的，在這種情況下，從事服務的開發者可以專注于他們的業務邏輯，避免在編寫自己的服務基礎架構代碼或管理整個團隊的庫和框架上浪費時間。
把這個想法和我們的圖表結合起來，我們可以得出如下結論:
不幸的是，更改網絡堆棧以添加這個層并不是一項可行的任務。許多從業者發現的解決方案是將其作為一組代理實現。這里的想法是，服務不會直接連接到它的下游依賴項，而是所有的流量都將通過一個小軟件來透明地添加所需的特性。
這種思想下的第一個有記錄的開發利用了“sidecars”概念。sidecar是一種輔助進程，在應用旁執行，并提供額外的特性。2013年，Airbnb寫了關于Synapse和Nerve的文章，一種sidecar的開源實現。一年后，Netflix引入了Prana，這是一種致力于允許非jvm應用程序從他們的NetflixOSS生態系統中獲益的sidecar。SoundCloud也構建了sidecars，讓Ruby legacy能夠使用為JVM微服務構建的基礎設施。
雖然有幾個這樣的開源代理實現，但它們往往被設計成與特定的基礎設施組件一起工作。例如，當談到服務發現Airbnb的神經和突觸時，我們假設服務是在Zookeeper中注冊的，而對于Prana，我們應該使用Netflix自己的Eureka服務注冊。
隨著微服務架構的日益流行，出現了一種新的代理，它們足夠靈活，可以適應不同的基礎設施組件和首選項。第一個廣為人知的系統是Linkerd，基于他們在Twitter微服務平臺上的工作而創建。很快，Lyft的工程團隊也宣布了遵循類似原則的項目——Envoy。
在這種模型中，我們的每個服務都將有一個附屬的代理sidecar。考慮到服務之間僅通過sidecar代理進行通信，我們最終的部署類似于下面的圖:
Buoyant首席執行官威廉·摩根觀察到代理之間的互連形成了一個網狀網絡，于是在2017年初，為這個平臺寫了一個定義，并稱之為Service Mesh（服務網格）:
Service Mesh是處理服務間通信的基礎設施層，負責實現請求的可靠傳遞。在實踐中，Service Mesh通常實現為輕量級網絡代理，與應用部署在一起，但是對應用透明。
該定義最有意義的地方在于，它不再將代理視為獨立的組件，而是承認它們形成的網絡本身是有價值的。
隨著企業將其微服務部署移動到更復雜的運行時，如Kubernetes和Mesos，人們和企業已經開始使用這些平臺提供的工具來正確地實現網格網絡的想法。它們正在從一組獨立的代理轉向一個適當的、某種程度上集中的控制平面。
在鳥瞰圖，我們能看到實際的服務流量仍然從代理直接流向代理，但是控制平面知道每個代理實例。控制平面使代理能夠實現訪問控制和度量收集等功能:
要完全理解大型系統中Service Mesh的影響還為時過早。這種方法的兩個好處在我看來已經很明顯了。首先，不需要編寫定制軟件來處理微服務架構最終代碼，這將允許許多較小的組織享受以前只有大型企業才能使用的功能，從而創建各種有趣的用例。第二，這種體系結構可能讓我們最終實現使用最佳工具/語言完成工作的夢想，而不必擔心每個平臺的庫和模式的可用性。
到此，相信大家對“Service Mesh模式是怎么來的”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
