猜想將來微服務架構

微服務架構

微服務的概念在2014年3月由Martin Fowler首次提出。

微服務架構解決的核心問題及其相應的開源組件以下所示：

• RPC框架 (Service-to-service calls)
  • Spring Boot/Spring MVC
  • Dubbo
  • gRPC
  • thrift
• 服務註冊和發現 (Service registration and discovery)
  • 註冊中心
    • Eureka: 在 Netflix 通過大規模生產驗證，支持跨數據中心。
    • Consul: 自然支持跨數據中心，還支持 KV 模型存儲和靈活健康檢查能力
    • ZooKeeper
    • Redis
    • Nacos
• 負載均衡 (Load balancing)
  • Ribbon/Feign
  • Nginx
  • HAProxy
  • RPC client
• 容錯限流 (Circuit Breakers)
  • Hystrix
  • Nginx/Kong + RateLimit
  • Sentinel
• 認證受權 (Security)
  • Spring Security/Spring Cloud Security
  • OAuth
  • OpenID connect
• 服務網關和路由 (Routing)
  • Zuul: 在 Netflix 通過大規模生產驗證，支持靈活的動態過濾器腳本機制，異步性能不足（基於 Netty 的異步 Zuul 遲遲未能推出正式版）
  • Kong: Nginx/OpenResty 的 API 網關。
• 配置中心 (Distributed/versioned configuration)
  • Spring Cloud Config
  • Apollo@攜程
  • Nacos
• 監控告警
  • 日誌監控 (Logging)
    • ELK
  • 調用鏈監控 (Tracing)
    • CAT@點評
    • Zipkin@Twitter
    • Pinpoint@Naver
  • Metrics 監控 (stats, metrics)
    • 存儲 (TSDB)
      • OpenTSDB(HBase) + Argus，KariosDB(Cassandra) + ZMon
      • InfluxDB
      • Prometheus
    • 告警
      • Argus 是 Salesforce 開源的基於 OpenTSDB 的統一監控告警平臺，支持豐富的告警函數和靈活的告警配置。
      • ZMon 後臺採用 KairosDB 存儲，若是企業已經採用 KariosDB 做爲時間序列數據庫
    • 報表
      • Grafana 是 Metrics 報表展現的社區標配
  • 健康檢查
  • 告警通知
    • Elastalert 是 Yelp 開源的針對 ELK 的告警通知模塊
• 任務調度
  • Quartz、elastic-job、xxl-job
  • oozie : Hadoop Job Scheduling
  • Azkaban@Linkedin : Hadoop Job Scheduling
  • luigi@Spotify : One major difference is that Luigi is not just built specifically for Hadoop, and it’s easy to extend it with other kinds of tasks.
  • Airflow@Airbnb、Maat@阿里巴巴 惋惜沒有開源 : General Purpose Batch Processing
  • Conductor@Netflix : Microservice orchestration
  • argo : Open source Kubernetes native workflows, events, CI and CD.
• 事件驅動
  • Spring Cloud Stream
• 其它
  • Global locks
  • Leadership election and cluster state
• 部署微服務 (CICD & CNCF)
  • CICD
  • A/B rollout
  • dark launches
  • auto scale
  • docker
  • Cloud Foundry
  • Kubernetes
  • Mesos

業界主流微服務解決方案

一、Netflix

• Eureka for service discovery
• Archaius for distributed configuration
• Ribbon for resilient and intelligent inter-process and service communication
• Hystrix for latency and fault tolerance at run-time
• Prana as a sidecar for non-JVM based services.
• Zuul (which integrates Hystrix, Eureka, and Ribbon as part of its IPC capabilities) provides dyamically scriptable proxying at the edge of the cloud deployment.
• Fenzo as a scheduler Java library for Apache Mesos frameworks that supports plugins for scheduling optimizations and facilitates cluster autoscaling.

二、Spring Cloud: Tools for building common patterns in distributed systems with Spring.

Spring Cloud爲開發者提供了快速構建分佈式系統的通用模型的工具（包括配置管理、服務發現、熔斷器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領導選舉、分佈式會話、集羣狀態等）。 主要項目包括：

• Spring Cloud Config：由Git存儲庫支持的集中式外部配置管理。配置資源直接映射到Spring Environment，可是若是須要能夠被非Spring應用程序使用。
• Spring Cloud Netflix：與各類Netflix OSS組件（Eureka，Hystrix，Zuul，Archaius等）集成。
• Spring Cloud Bus：用於將服務和服務實例與分佈式消息傳遞聯繫起來的事件總線。用於在集羣中傳播狀態更改（例如配置更改事件）。
• Spring Cloud for Cloudfoundry：將您的應用程序與Pivotal Cloudfoundry集成。提供服務發現實現，還能夠輕鬆實現經過 SSO 和 OAuth 2 保護資源，還能夠建立Cloudfoundry服務代理。
• Spring Cloud - Cloud Foundry Service Broker：提供構建管理一個Cloud Foundry中服務的服務代理的起點。
• Spring Cloud Cluster：領導選舉和通用狀態模型（基於ZooKeeper，Redis，Hazelcast，Consul的抽象和實現）。
• Spring Cloud Consul：結合Hashicorp Consul的服務發現和配置管理
• Spring Cloud Security：在Zuul代理中爲負載平衡的OAuth 2休眠客戶端和認證頭中繼提供支持。
• Spring Cloud Sleuth：適用於Spring Cloud應用程序的分佈式跟蹤，與Zipkin，HTrace和基於日誌（例如ELK）跟蹤兼容。
• Spring Cloud Data Flow：針對現代運行時的可組合微服務應用程序的雲本地編排服務。易於使用的DSL，拖放式GUI和REST-API一塊兒簡化了基於微服務的數據管道的總體編排。
• Spring Cloud Stream：輕量級事件驅動的微服務框架，可快速構建可鏈接到外部系統的應用程序。使用Apache Kafka或RabbitMQ在Spring Boot應用程序之間發送和接收消息的簡單聲明式模型。
• Spring Cloud Stream Application Starters：Spring Cloud任務應用程序啓動器是Spring Boot應用程序，多是任何進程，包括不會永遠運行的Spring Batch做業，而且它們在有限時間的數據處理以後結束/中止。
• Spring Cloud ZooKeeper：ZooKeeper的服務發現和配置管理。
• Spring Cloud for Amazon Web Services：輕鬆集成託管的Amazon的Web Services服務。它經過使用Spring的idioms和APIs便捷集成AWS服務，例如緩存或消息API。開發人員能夠圍繞託管服務，沒必要關心基礎架構來構建應用。
• Spring Cloud Connectors：使PaaS應用程序在各類平臺上輕鬆鏈接到後端服務，如數據庫和消息代理（之前稱爲「Spring Cloud」的項目）。
• Spring Cloud Starters：做爲基於Spring Boot的啓動項目，下降依賴管理（在Angel.SR2後，不在做爲獨立項目）。
• Spring Cloud CLI：插件支持基於Groovy預言快速建立Spring Cloud的組件應用。

三、spring cloud alibaba: Spring Cloud Alibaba provides a one-stop solution for application development for the distributed solutions of Alibaba middleware.

Spring Cloud for Alibaba，它是由一些阿里巴巴的開源組件和雲產品組成的。這個項目的目的是爲了讓你們所熟知的 Spring 框架，其優秀的設計模式和抽象理念，以給使用阿里巴巴產品的 Java 開發者帶來使用 Spring Boot 和 Spring Cloud 的更多便利。

其中阿里巴巴開源組件的命名前綴爲spring-cloud-alibaba，提供了以下特性：

• 服務註冊與發現 : 適配 Spring Cloud 服務註冊與發現標準，默認集成了 Ribbon 的支持。
• 分佈式配置管理：支持分佈式系統中的外部化配置，配置更改時自動刷新。
• 消息驅動能力：基於 Spring Cloud Stream 爲微服務應用構建消息驅動能力。
• 服務限流降級 : 默認支持 Servlet、Feign、RestTemplate、Dubbo 和 RocketMQ 限流降級功能的接入，能夠在運行時經過控制檯實時修改限流降級規則，還支持查看限流降級 Metrics 監控。

阿里雲的產品組件的命名前綴爲 spring-cloud-alicloud ，提供了以下特性：

• 應用配置管理 : 阿里雲配置管理服務ACM，增強了安全的配置管理，而且還包含了完整的推送軌跡查詢。
• 對象存儲服務 : 阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。支持在任何應用、任什麼時候間、任何地點存儲和訪問任意類型的數據。
• 分佈式任務調度 : 提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。同時提供分佈式的任務執行模型，如網格任務。網格任務支持海量子任務均勻分配到全部 Worker（schedulerx-client）上執行。

下面是使用到的一些組件:

• Sentinel : 把流量做爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
• Nacos : 一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
• RocketMQ : 一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。
• Alibaba Cloud ACM : 一款在分佈式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。
• Alibaba Cloud OSS : 阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。您能夠在任何應用、任什麼時候間、任何地點存儲和訪問任意類型的數據。
• Alibaba Cloud SchedulerX : 阿里中間件團隊開發的一款分佈式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。

可是顯然，這個並非一個徹底的開源項目，由於阿里雲的服務是要收費的。

四、Service Mesh

微服務的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念則是在2016年左右提出，Service Mesh至今也經歷了第二代的發展。

Service Mesh又譯做「服務網格」，做爲服務間通訊的基礎設施層。若是用一句話來解釋什麼是Service Mesh，能夠將它比做是應用程序或者說微服務間的TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對於編寫應用程序來講通常無須關心TCP/IP這一層（好比經過 HTTP 協議的 RESTful 應用），一樣使用Service Mesh也就無須關係服務之間的那些原來是經過應用程序或者其餘框架實現的事情，好比Spring Cloud、OSS，如今只要交給Service Mesh就能夠了。

Service Mesh有以下幾個特色：

• 應用程序間通信的中間層
• 輕量級網絡代理
• 應用程序無感知
• 解耦應用程序的重試/超時、監控、追蹤和服務發現

Service Mesh的架構以下圖所示：

Service Mesh做爲Sidebar運行，對應用程序來講是透明，全部應用程序間的流量都會經過它，因此對應用程序流量的控制均可以在Service Mesh中實現。

目前流行的開源 Service Mesh 框架有：

• Linkerd
• Envoy
• Istio
• Conduit

一、Linkerd 1.x

Linkerd 1.x 基於Twitter的Fingle，使用Scala編寫，是業界第一個開源的Service Mesh方案，在長期的實際生產環境中得到驗證。

它的主要特性有：

• 負載均衡：Linkerd提供了多種負載均衡算法，它們使用實時性能指標來分配負載並減小整個應用程序的尾部延遲。
• 熔斷：Linkerd包含自動熔斷，將中止將流量發送到被認爲不健康的實例，從而使他們有機會恢復並避免連鎖反應故障。
• 服務發現：Linkerd 與各類服務發現後端集成，經過刪除特定的(ad-hoc)服務發現實現來幫助您下降代碼的複雜性。
• 動態請求路由：Linkerd 啓用動態請求路由和從新路由，容許您使用最少許的配置來設置分段服務（staging service），金絲雀（canaries），藍綠部署（blue-green deploy），跨DC故障切換和黑暗流量（dark traffic）。
• 重試次數和截止日期：Linkerd能夠在某些故障時自動重試請求，而且能夠在指定的時間段以後讓請求超時。
• TLS：Linkerd能夠配置爲使用TLS發送和接收請求，您可使用它來加密跨主機邊界的通訊，而不用修改現有的應用程序代碼。
• HTTP代理集成：Linkerd能夠做爲HTTP代理，幾乎全部現代HTTP客戶端都普遍支持，使其易於集成到現有應用程序中。
• 透明代理：您能夠在主機上使用iptables規則，設置經過Linkerd的透明代理。
• gRPC：Linkerd支持HTTP/2和TLS，容許它路由gRPC請求，支持高級RPC機制，如雙向流，流程控制和結構化數據負載。
• 分佈式跟蹤：Linkerd支持分佈式跟蹤和度量儀器，能夠提供跨越全部服務的統一的可觀察性。
• 儀器儀表：Linkerd支持分佈式跟蹤和度量儀器，能夠提供跨越全部服務的統一的可觀察性。

說明：Conduit 後面合併到 Linkerd 2.0，所以本質上 Linkerd 2.0 = Conduit。

二、Envoy

Envoy底層基於C++，性能上優於使用Scala的Linkerd。同時，Envoy社區成熟度較高，商用穩定版本面世時間也較長。

Envoy是一個面向服務架構的L7代理和通訊總線而設計的，這個項目誕生是出於如下目標：

對於應用程序而言，網絡應該是透明的，當發生網絡和應用程序故障時，可以很容易定位出問題的根源。

Envoy可提供如下特性：

• 外置進程架構：可與任何語言開發的應用一塊兒工做；可快速升級。
• 基於新C++11編碼：可以提供高效的性能。
• L3/L4過濾器：核心是一個L3/L4網絡代理，可以做爲一個可編程過濾器實現不一樣TCP代理任務，插入到主服務當中。經過編寫過濾器來支持各類任務，如原始TCP代理、HTTP代理、TLS客戶端證書身份驗證等。
• HTTP L7過濾器：支持一個額外的HTTP L7過濾層。HTTP過濾器做爲一個插件，插入到HTTP連接管理子系統中，從而執行不一樣的任務，如緩衝，速率限制，路由/轉發，嗅探Amazon的DynamoDB等等。
• 支持HTTP/2：在HTTP模式下，支持HTTP/1.一、HTTP/2，而且支持HTTP/1.一、HTTP/2雙向代理。這意味着HTTP/1.1和HTTP/2，在客戶機和目標服務器的任何組合均可以橋接。
• HTTP L7路由：在HTTP模式下運行時，支持根據content type、runtime values等，基於path的路由和重定向。可用於服務的前端／邊緣代理。
• 支持gRPC：gRPC是一個來自谷歌的RPC框架，使用HTTP/2做爲底層的多路傳輸。HTTP/2承載的gRPC請求和應答，均可以使用Envoy的路由和LB能力。
• 支持MongoDB L7：支持獲取統計和鏈接記錄等信息。
• 支持DynamoDB L7：支持獲取統計和鏈接等信息。
• 服務發現：支持多種服務發現方法，包括異步DNS解析和經過REST請求服務發現服務。
• 健康檢查：含有一個健康檢查子系統，能夠對上游服務集羣進行主動的健康檢查。也支持被動健康檢查。
• 高級LB：包括自動重試、斷路器，全侷限速，阻隔請求，異常檢測。將來還計劃支持請求速率控制。
• 前端代理：可做爲前端代理，包括TLS、HTTP/1.一、HTTP/2，以及HTTP L7路由。
• 極好的可觀察性：對全部子系統，提供了可靠的統計能力。目前支持statsd以及兼容的統計庫。還能夠經過管理端口查看統計信息，還支持 第三方的分佈式跟蹤機制。
• 動態配置：提供分層的動態配置API，用戶可使用這些API構建複雜的集中管理部署。

三、Istio

Istio是Google、IBM和Lyft合做的開源項目，是目前最主流的Service Mesh方案，也是事實上的第二代Service Mesh標準。在Istio中，直接把Envoy做爲Sidecar。除了Sidecar，Istio中的控制面組件都是使用Go語言編寫。

Istio在服務網絡中主要提供瞭如下關鍵功能：

• 流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，並使網絡在惡劣狀況下更加健壯。
• 可觀察性：瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。
• 策略執行：將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是經過配置網格而不是修改應用程序代碼。
• 服務身份和安全：爲網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其能夠在不一樣可信度的網絡上流轉。
• 平臺支持：Istio旨在在各類環境中運行，包括跨雲、Kubernetes、Mesos等。最初專一於Kubernetes，但很快將支持其餘環境。
• 集成和定製：策略執行組件能夠擴展和定製，以便與現有的ACL、日誌、監控、配額、審覈等解決方案集成。

Istio服務網格邏輯上分爲數據面板和控制面板：

• 數據面板由一組智能代理（Envoy）組成，代理部署爲邊車 (Sidecar)，調解和控制微服務之間全部的網絡通訊。
• 控制面板負責管理和配置代理來路由流量，以及在運行時執行策略。

下圖爲Istio的架構設計圖，主要包括了Envoy、Pilot、Mixer和Istio-Auth等。

• Envoy: 扮演Sidecar的功能，協調服務網格中全部服務的出入站流量，並提供服務發現、負載均衡、限流熔斷等能力，還能夠收集與流量相關的性能指標。
• Pilot: 負責部署在Service Mesh中的Envoy實例的生命週期管理。本質上是負責流量管理和控制，將流量和基礎設施擴展解耦，這是Istio的核心。能夠把Pilot看作是管理Sidecar的Sidecar, 可是這個特殊的Sidacar並不承載任何業務流量。Pilot讓運維人員經過Pilot指定它們但願流量遵循什麼規則，而不是哪些特定的pod/VM應該接收流量。有了Pilot這個組件，咱們能夠很是容易的實現 A/B 測試和金絲雀Canary測試。
• Mixer: Mixer在應用程序代碼和基礎架構後端之間提供通用中介層。它的設計將策略決策移出應用層，用運維人員可以控制的配置取而代之。應用程序代碼再也不將應用程序代碼與特定後端集成在一塊兒，而是與Mixer進行至關簡單的集成，而後Mixer負責與後端系統鏈接。Mixer能夠認爲是其餘後端基礎設施（如數據庫、監控、日誌、配額等）的Sidecar Proxy。
• Istio-Auth: 提供強大的服務間認證和終端用戶認證，使用交互TLS，內置身份和證書管理。能夠升級服務網格中的未加密流量，併爲運維人員提供基於服務身份而不是網絡控制來執行策略的能力。Istio的將來版本將增長細粒度的訪問控制和審計，以使用各類訪問控制機制（包括基於屬性和角色的訪問控制以及受權鉤子）來控制和監視訪問服務、API或資源的訪問者。

四、Conduit

Conduit 是開源 Linkerd 的公司 Buoyant 基於 Kubernetes 設計的一個超輕型服務網格服務。它可透明地管理在Kubernetes上運行的服務的運行時通訊，使得它們更安全可靠。Conduit提供了可見性、可靠性和安全性的功能，而無需更改代碼。

Conduit各方面的設計理念與Istio很是相似，做者使用Rust語言從新編寫了Sidecar, 叫作Conduit Data Plane, 控制面則由Go語言編寫的Conduit Control Plane接管。從Conduit的架構看，做者號稱Conduit吸收了不少Linkerd的教訓，比Linkerd更快、更輕、更簡單，控制面功能更強。與Istio比較，Conduit的架構一方面比較簡單，另外一方面對於要解決的問題足夠聚焦。

Conduit service mesh也是由數據面板和控制面板組成。數據面板承載應用實際的網絡流量。控制面板驅動數據面板，並對外提供北向接口。

其中控制面板 (control plane) 主要由下面四個組件構成:

• Controller : The controller deployment consists of multiple containers (public-api, proxy-api, destination, tap) that provide the bulk of the control plane’s functionality.
• Web : The web deployment provides the Linkerd dashboard.
• Prometheus : All of the metrics exposed by Linkerd are scraped via Prometheus and stored here. This is an instance of Prometheus that has been configured to work specifically with the data that Linkerd generates. There are instructions if you would like to integrate this with an existing Prometheus installation.
• Grafana : Linkerd comes with many dashboards out of the box. The Grafana component is used to render and display these dashboards. You can reach these dashboards via links in the Linkerd dashboard itself.

而數據面板 (Data Plane) 則是簡單的包括你的 application 和透明的 sidecar proxy (默認是用 Rust 語言編寫的 linkerd-proxy)。

最後，Conduit 還提供了一個本地命令行工具 (CLI)，用於跟控制面板和數據面板交互。和一個 Dashboard，用於服務監控和治理。能夠經過 linkerd dashboard 命令啓動。

說明：Conduit 後面合併到 Linkerd 2.0，所以本質上 Linkerd 2.0 = Conduit。

對比

Linkerd 1.x 和 Envoy 比較類似，都是一種面向服務通訊的網絡代理，都可實現諸如服務發現、請求路由、負載均衡等功能。它們的設計目標就是爲了解決服務之間的通訊問題，使得應用對服務通訊無感知，這也是Service Mesh的核心理念。

Linkerd 1.x和 Envoy 像是分佈式的 Sidebar，多個相似 Linkerd 1.x 和 Envoy 的 proxy 互相鏈接，就組成了 service mesh。

而 Istio 和 Conduit (Linkerd 2.x) 則是站在了一個更高的角度，它將Service Mesh分爲了Data Plane和Control Plane。Data Plane負責微服務間的全部網絡通訊，而Control Plane負責管理Data Plane Proxy:

並且Istio和Conduit引入了Kubernetes，這也彌合了應用調度框架與Service Mesh之間的空隙。

五、Serverless

Serverless被翻譯爲『無服務器架構』，這個概念在2012年時便已經存在，比微服務和Service Mesh的概念出現都要早，可是直到微服務概念大紅大紫以後，Serverless才從新又被人們所關注。

Serverless 的意思並非無服務器，而是去除有關對服務器運行狀態的關心和擔憂，代碼在哪裏運行，須要多少容量，它們是否在工做，應用是否跑起來正常運行。

「Write your code, tell the system when to run it and you’re done.」

全部服務器的管理和擴縮容對開發者是透明的，開發者只須要關心業務邏輯的開發，其餘的一切交給雲服務提供者，好比Amazon Web Services (AWS Lambda), Google Cloud (Google Cloud Functions) 或者 Microsoft Azure (Azure Functions) 。

In this model, organizations only pay for the resources they use — actual consumption — rather than pre-purchased services based on guesswork. The server management and capacity planning decisions are completely hidden from the developer, thus the term 「serverless.」 The servers are fully abstracted away. Instead, a cloud provider, like Amazon Web Services (AWS Lambda), Google Cloud (Google Cloud Functions) or Microsoft Azure (Azure Functions) dynamically manages the assignment and distribution of resources.

可是其實這塊強調的是雲平臺帶來的機器資源自由調度帶來的便利。跟 service mesh 2.0 其實沒有本質上的區別，從這個意義上來講，serverless 是目標，service mesh 是解決方案。因此基本上，目前開源的 serverless 框架，基本都是基於 k8s/mesos/docker compose這樣的容器編排和資源調度框架和 Service Mesh 框架實現。主要有以下這些：

1. Knative 谷歌開源的一個基於Kubernetes和Istio實現的構建、部署和管理的現代serverless workloads。
2. kubeless The Kubernetes Native Serverless Framework - Build advanced applications with FaaS on top of Kubernetes
3. Fission Fission is a framework for serverless functions on Kubernetes.
4. OpenWhisk Open Source Serverless Cloud Platform

最終的微服務解決方案 = Dev + Ops = Service Mesh + Kubernetes ？

這就是爲何有了 Linkerd 和 Envoy 以後，還會進一步進化出 Istio 和 Conduit。它們相對於老的 serive mesh 框架最大的特色就是基於 Kubernetes 設計，補足了Kubernetes在微服務間服務通信上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務框架，可是它們或多或少都會和具體語言或應用場景綁定，並只解決了微服務Dev層面的問題。若想解決Ops問題，它們還需和諸如Cloud Foundry、Mesos、或Kubernetes這類資源調度框架作結合：

Kubernetes自己就是一個和開發語言無關的、通用的容器管理平臺，它能夠支持運行雲原生和傳統的容器化應用。而且它覆蓋了微服務的Dev和Ops階段，結合Service Mesh，它能夠爲用戶提供完整端到端的微服務體驗。

所以咱們有理由推測，將來的微服務架構和技術棧多是以下形式:

雲平臺(或者自建機房) 爲微服務提供了資源能力（計算、存儲和網絡等），容器 做爲最小工做單元被 Kubernetes 調度和編排，Service Mesh 管理微服務的服務通訊，最後經過 API Gateway 向外暴露微服務的業務接口。

原文：http://arganzheng.life/microservice-architecture.html