ServiceMesh案例

      服務網格（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 /healthcheck endpoint) and passive (e.g., using 3 consecutive 5xx as an indication of an unhealthy state) health checking.
• Routing: Given a REST request for /foo from 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 /foo what 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,企業信息化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 該文章也同時發布在我的獨立博客中-Petter Liu Blog。