問：什麼是服務網格？
服務網格是軟體層，可以處理應用程式之間的所有通訊。此層是由容器化微型服務組成。隨著應用程式擴展和微型服務數量的增加，監控服務的效能變得極具挑戰性。為了管理服務之間的連線，服務網格提供了監控、記錄、追蹤和流量控制等新功能。這獨立於每個服務的程式碼之外，因此可以跨網路界限並在多個服務管理系統中運作。
為什麼需要服務網格？
在現代應用程式架構中，您可以將應用程式建置為小型、可獨立部署的微型服務集合。不同的團隊可能會建立個別微型服務，並選擇其編碼語言和工具。不過，微型服務必須通訊，應用程式的程式碼才能正常運作。
應用程式效能取決於服務之間通訊的速度和彈性。開發人員必須監控和優化跨服務的應用程式，但由於系統的分散式性質，很難獲得可視性。隨著應用程式的擴展，管理通訊變得更加複雜。
採用服務網格有兩個主要的驅動因素，我們接下來會詳細介紹。
服務層級可觀測性
隨著工作負載和服務的部署越來越多，開發人員發現了解所有這些如何一起運作極具挑戰性。例如，服務團隊想要知道其下游和上游相依項有哪些。他們想要更清楚地了解服務和工作負載在應用程式層的通訊方式。
服務層級控制
管理員想要控制哪些服務彼此通話，以及他們所執行的動作。他們想要對微型服務架構中服務的行為、政策和互動進行精細控制和控管。強制執行安全政策對於法規遵循至關重要。
服務網格有哪些優勢？
服務網格提供集中式的專用基礎設施層，可處理分散式應用程式中複雜的服務對服務通訊。接下來，我們將介紹服務網格的幾項優勢。
服務探索
服務網格提供自動化服務探索，可減少管理服務端點的操作負載。他們使用服務登錄檔，來動態探索並追蹤網格內的所有服務。無論服務的位置或基礎設施為何，服務都可順暢地尋找彼此並與之通訊。您可以視需要部署新服務來快速擴展。
負載平衡
服務網格會使用各種演算法 (例如輪詢、最少連線或加權負載平衡)，以智慧方式將請求分散到多個服務執行個體。負載平衡可改善資源使用率，並確保高可用性和可擴展性。您可以優化效能並防止網路通訊瓶頸。
流量管理
服務網格提供進階流量管理功能，可對請求路由和流量行為提供精細控制。以下是一些範例。
流量分割
您可以在不同的服務版本或組態之間分割傳入的流量。網格會將某些流量引導至更新版本，這可允許受控且逐步推出的變更。這樣可以提供平滑的轉換，並將變更的影響降至最低。
請求鏡像
您可以將流量複寫到測試或監控服務以進行分析，而不影響主要請求流程。當您鏡像處理請求時，您可以深入了解服務如何處理特定請求，而不影響生產流量。
金絲雀部署
您可以將使用者或流量的小子集引導至新的服務版本，而大多數使用者則繼續使用現有的穩定版本。在公開有限的情況下，您可以在真實環境中實驗新版本的行為和效能。
安全
服務網格提供安全的通訊功能，例如相互 TLS (mTLS) 加密、身分驗證和授權。相互 TLS 可在服務對服務通訊中進行身分驗證。它透過加密流量，來協助確保資料機密性和完整性。您還可以強制執行授權政策，以控制哪些服務存取特定端點或執行特定動作。
監控
服務網格提供全面的監控和可觀測性功能，以深入了解服務的運作狀況、效能和行為。監控還支援疑難排解和效能優化。以下是您可以使用的監控功能範例：
- 收集延遲、錯誤率和資源使用率等指標，以分析整體系統效能
- 執行分散式追蹤，以查看請求的完整路徑和跨多項服務計時
- 在日誌中擷取服務事件，用於稽核、偵錯和合規用途
服務網格如何運作？
服務網格會從個別服務中移除管控服務對服務通訊的邏輯，並將通訊抽象化到自己的基礎設施層。它使用多個網路代理，來路由和追蹤服務之間的通訊。
代理充當組織網路與微型服務之間的中介閘道。所有進出服務的流量都會透過代理伺服器進行路由。個別代理有時被稱為 Sidecar，因為它們單獨執行，但邏輯上是在每項服務旁邊。整合在一起，代理會形成服務網格層。
服務網格架構中有兩個主要元件：控制平面和資料平面。
資料平面
資料平面是服務網格的資料處理元件。它包括所有的 Sidecar 代理及其功能。當服務想要與其他服務通訊時，Sidecar 代理會採取下列動作：
- Sidecar 會攔截請求
- 它會封裝單獨網路連線中的請求
- 它還會在來源和目的地代理之間建立安全並加密的通路
Sidecar 代理會處理服務之間的低級別訊息傳遞。此外，他們還會實作斷路和請求重試等功能，以增強彈性並防止服務降級。服務網格功能 (例如負載平衡、服務探索和流量路由) 會在資料平面中實作。
控制平面
控制平面充當服務網格的中央管理和組態層。
使用控制平面，管理員可在網格中定義和設定服務。例如，他們可指定服務端點、路由規則、負載平衡政策和安全設定等參數。定義組態之後，控制平面會將必要的資訊分配至服務網格的資料平面。
代理使用組態資訊來決定如何處理傳入的請求。他們還可接收組態變更並動態調整其行為。您可以對服務網格組態進行即時變更，而不會重新啟動服務或中斷。
服務網格實作通常包括控制平面中的下列功能：
- 追蹤網格內所有服務的服務登錄檔
- 自動探索新服務並移除非作用中服務
- 收集並彙總遙測資料，例如指標、日誌和分散式追蹤資訊
什麼是 Istio？
Istio 是一個開放原始碼服務網格專案，主要用於與 Kubernetes 搭配使用。Kubernetes 是一種開放原始碼容器協同運作平台，用於大規模部署和管理容器化應用程式。
Istio 的控制平面元件本身會以 Kubernetes 工作負載的形式執行。它使用 Kubernetes Pod (緊密耦合的容器集，共用一個 IP 地址)，做為 Sidecar 代理設計的基礎。
Istio 的第 7 層代理做為另一個容器，在與主要服務相同的網路內容中執行。從該位置，它可以攔截、檢查和操縱通過 Pod 的所有網路流量。然而，無需更改主要容器，甚至不需要知道這種情況正在發生。
開放原始碼服務網格實作有哪些挑戰？
以下是與開放原始碼平台 (例如 Istio、Linkerd 和 Consul) 關聯的一些常見服務網格挑戰。
複雜性
服務網格涉及額外的基礎設施元件、組態需求和部署考量。它們具有陡峭的學習曲線，這需要開發人員和操作人員在使用特定服務網格實作方面獲得專業知識。對團隊進行培訓需要時間和資源。組織必須確保團隊擁有必要的知識，以了解服務網格架構的複雜性，並有效地對其進行設定。
營運開銷
服務網格涉及部署、管理和監控資料平面代理和控制平面元件的額外開銷。例如，您必須執行下列操作：
- 確保服務網格基礎設施的高可用性和可擴展性
- 監控代理的運作狀態和效能
- 處理升級和相容性問題
精心設計和設定服務網格，對於將整體系統的任何效能影響降到最低至關重要。
整合挑戰
服務網格必須與現有基礎設施無縫整合，才能執行其所需的功能。這包括容器協同運作平台、網路解決方案，以及技術堆疊中的其他工具。
在複雜且多樣化的環境中，確保相容性並順暢地整合其他元件可能極具挑戰性。需要持續的規劃和測試，才能變更您的 API、組態格式和相依項。如果您需要在堆棧中的任何位置升級至新版本也是如此。
AWS 如何支援您的服務網格需求？
AWS App Mesh 是 Amazon Web Service (AWS) 的一個全受管和高可用性服務網格。App Mesh 可輕鬆監控、控制和偵錯服務之間的通訊。
App Mesh 使用 Envoy，這是與您的微型服務容器一起部署的開放原始碼服務網格代理。您可以將其與 Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Fargate 和 Kubernetes on AWS 管理的微型服務容器搭配使用。您還可以將其與 Amazon Elastic Compute Cloud (Amazon EC2) 上的服務搭配使用。
立即建立帳戶，開始使用 AWS 上的服務網格。
