微服務架構

微服務的概念在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

業界主流微服務解決方案

1、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.

2、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的組件應用。

3、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 表達式）任務調度服務。

但是顯然，這個并不是一個完全的開源項目，因為阿里云的服務是要收費的。

4、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

1、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。

2、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.1、HTTP/2，并且支持HTTP/1.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.1、HTTP/2，以及HTTP L7路由。
• 極好的可觀察性：對所有子系統，提供了可靠的統計能力。目前支持statsd以及兼容的統計庫。還可以通過管理端口查看統計信息，還支持 第三方的分布式跟蹤機制。
• 動態配置：提供分層的動態配置API，用戶可以使用這些API構建復雜的集中管理部署。

3、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或資源的訪問者。

4、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之間的空隙。

5、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 框架實現。主要有如下這些：

Knative?谷歌開源的一個基于Kubernetes和Istio實現的構建、部署和管理的現代serverless workloads。

kubeless?The Kubernetes Native Serverless Framework - Build advanced applications with FaaS on top of Kubernetes

Fission?Fission is a framework for serverless functions on Kubernetes.

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

轉載于:https://www.cnblogs.com/boxy/p/11474839.html

總結

以上是生活随笔為你收集整理的猜测未来微服务架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。