字體：小 中 大 |
|
|
|
| 2021/02/18 12:42:20瀏覽450｜回應0｜推薦2 | |
作筆記 對Service Mesh 很好的說明
摘自Whats a service mesh? (redhat.com) 服務格線（如開源專案Istio）是一種控制應用程式的不同部分彼此共享數據的一種方式。與其他用於管理此通信的系統不同，服務網格是直接內置到應用中的專用基礎結構層。此可見的基礎結構層可以記錄應用的不同部分的交互性（或其交互方式），因此隨著應用的增長，優化通信並避免停機變得更加容易。 應用的每個部分（稱為"服務"）都依賴於其他服務為使用者提供他們的需求。如果在線零售應用的使用者想要購買商品，他們需要知道商品是否庫存。因此，與公司庫存資料庫通訊的服務需要與產品網頁通信，而產品網頁本身需要與用戶的在線購物車進行通信。為了增加業務價值，此零售商最終可能會構建一個服務，為使用者提供應用內產品建議。此新服務將與產品標籤資料庫進行通信以提出建議，但它也需要與產品頁面所需的同一庫存資料庫進行通信，這是許多可重用的移動部件。 現代應用程式通常被這樣分解，作為一個服務網路，每個服務執行特定的業務功能。為了執行其功能，一個服務可能需要從其他幾個服務請求數據。但是，如果某些服務請求過多，如零售商的庫存資料庫，會怎麼樣？這就是服務網格的用武用—它將請求從一個服務路由到下一個服務，優化所有移動部件協同工作的流程。 微服務不是已經這樣做了嗎？微服務體系結構允許開發人員對應用的服務進行更改，而無需完全重新部署。與其他體系結構中的應用開發不同，單個微服務由小型團隊構建，可以靈活地選擇自己的工具和編碼語言。基本上，微服務是獨立構建的，彼此通信，並且可以單獨失敗，而不會升級為應用程序範圍的中斷。  服務到服務通訊是微服務成為可能的原因。管理通信的邏輯可以編碼到每個服務中，而無需服務網格層，但隨著通信變得越來越複雜，服務網格將變得更有價值。對於在微服務體系結構中構建的雲原生應用，服務網格是將大量離散服務組成函數應用程式的一種方式。 它是如何工作的？服務格線不會為應用的運行時環境引入新功能— 任何體系結構中的應用始終需要規則來指定請求從點 A 到 B 點的獲取方式。服務網格的不同是，它將管理服務到服務通信的邏輯從單個服務中抽象出來，並抽象到基礎結構層。 為此，服務網格作為網路代理陣列內置到應用中。代理是企業 IT 中一個熟悉的概念 — 如果您從工作電腦存取此網頁，您很有可能只是使用過一個：
 在服務網格中，請求通過自己的基礎結構層中的代理在微服務之間路由。因此，由服務網格的單個代理有時稱為「側車」，因為它們在每個服務旁邊運行，而不是在它們內部執行。綜合起來，這些"側車"代理（與每個服務分離）形成了一個網狀網路。  如果沒有服務網格，每個微服務都需要使用邏輯進行編碼，以控制服務到服務的通信，這意味著開發人員不太關注業務目標。這也意味著通信故障更難診斷，因為控制服務間通信的邏輯隱藏在每個服務中。 服務網格如何優化通信？添加到應用的每個新服務，或在容器中運行的現有服務的新實例，都會使通信環境複雜化，並引入新的可能失敗點。在複雜的微服務體系結構中，如果沒有服務網格，幾乎不可能找到問題發生的位置。 這是因為服務網格還捕獲服務到服務通信的各個方面作為性能指標。隨著時間的推移，服務網格顯示的數據可以應用於服務間通信的規則，從而產生更高效、更可靠的服務請求。 例如，如果給定服務失敗，服務網格可以收集重試成功之前需要多長時間的數據。作為給定服務聚合的故障時間數據，可以編寫規則以確定在重試該服務之前的最佳等待時間，確保系統不會因不必要的重試而負擔過重。 規劃未來如果您正在構建微服務，您可能預見到未來的某些需求，例如快速擴展和添加新功能以滿足業務需求。微服務體系結構與推出一年後可能大不相同。首先，在微服務中構建的庫可以處理服務到服務的通信，同時對操作的中斷最小。如果您要通過增加規模和功能來發揮微服務的潛力，那麼這不應該長期存在。隨著時間的推移，這可能會導致問題，因為服務被請求超載，開發人員會花越來越多的時間為每個服務編寫請求邏輯。 使用服務格線：
開始規劃未來 — 在紅帽、OpenShift ®上®服務網格。體驗連接、管理和觀察基於微服務的應用程式的統一方式，對服務網格中的網路微服務的行為洞察和控制。紅帽開放移位服務網（免費）可用 |
|
| ( 不分類｜不分類 ) |
