服務網格（Service Mesh）是致力于解決服務間通訊的基礎設施層，它負責在現代云原生應用程式的復雜服務拓撲來可靠地傳遞請求，實際上，Service Mesh 通常是通過一組輕量級網路代理（Sidecar proxy），與應用程式代碼部署在一起來實作，而無需感知應用程式本身，
資料面
- Service discovery: What are all of the upstream/backend service instances that are available?
- Health checking: Are the upstream service instances returned by service discovery healthy and ready to accept network traffic? This may include both active (e.g., out-of-band pings to a
/healthcheckendpoint) and passive (e.g., using 3 consecutive 5xx as an indication of an unhealthy state) health checking. - Routing: Given a REST request for
/foofrom the local service instance, to which upstream service cluster should the request be sent? - Load balancing: Once an upstream service cluster has been selected during routing, to which upstream service instance should the request be sent? With what timeout? With what circuit breaking settings? If the request fails should it be retried?
- Authentication and authorization: For incoming requests, can the caller be cryptographically attested using mTLS or some other mechanism? If attested, is the caller allowed to invoke the requested endpoint or should an unauthenticated response be returned?
- Observability: For each request, detailed statistics, logging, and distributed tracing data should be generated so that operators can understand distributed traffic flow and debug problems as they occur.
控制面
- The human: There is still a (hopefully less grumpy) human in the loop making high level decisions about the overall system.
- Control plane UI: The human interacts with some type of UI to control the system. This might be a web portal, a CLI, or some other interface. Through the UI, the operator has access to global system configuration settings such as deploy control (blue/green and/or traffic shifting), authentication and authorization settings, route table specification (e.g., when service A requests
/foowhat happens), and load balancer settings (e.g., timeouts, retries, circuit breakers, etc.). - Workload scheduler: Services are run on an infrastructure via some type of scheduling system (e.g., Kubernetes or Nomad). The scheduler is responsible for bootstrapping a service along with its sidecar proxy.
- Service discovery: As the scheduler starts and stops service instances it reports liveness state into a service discovery system.
- Sidecar proxy configuration APIs: The sidecar proxies dynamically fetch state from various system components in an eventually consistent way without operator involvement. The entire system composed of all currently running service instances and sidecar proxies eventually converge.
目前行業流行資料planes與控制planes:
- Data planes: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Control planes: Istio, Nelson, SmartStack
場景
另一案例是：
基于 Istio+Envoy 的方案：
- 資料面以 Envoy Proxy 作為代理組件
- 控制面以 Pilot 為核心組件
- 平臺開放與擴展主要通過 Kubernetes CRD與Mesh Configuration Protocol（簡稱為 MCP，一套標準 GRPC 協議）
- 高可用設計主要基于 Kubernetes 及 Istio 機制實作
今天先到這兒，希望對云原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理，團隊建設 有參考作用 , 您可能感興趣的文章:
領匯入怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下訊息佇列架構
互聯網高效研發團隊管理演進之一
訊息系統架構設計演進
互聯網電商搜索架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商云平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
Openshift與Kubernetes的區別
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：
![MegadotnetMicroMsg_thumb1_thumb1_thu[2]](https://img.uj5u.com/2020/11/07/1765440715232522.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[2]")
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
該文章也同時發布在我的獨立博客中-Petter Liu Blog，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/205596.html
標籤：其他
下一篇：git---下載和安裝