近幾年，微服務技術得以迅猛普及，而以 Spring Cloud、Dubbo 為代表較為成熟的微服務開發框架，占據著市場的主流地位，它們甚至一度成為微服務的代名詞。

什么是微服務

首先微服務并沒有一個官方的定義，想要直接描述微服務比較困難，我們可以通過對比傳統 Web 應用，來理解什么是微服務。

傳統的 Web 應用核心分為業務邏輯、適配器以及 API 或通過 UI 訪問的 Web 界面。業務邏輯定義業務流程、業務規則以及領域實體。適配器包括數據庫訪問組件、消息組件以及訪問接口等。

一個打車軟件的架構圖如下：

盡管也是遵循模塊化開發，但最終它們會打包并部署為單體式應用。例如 Java 應用程序會被打包成 WAR，部署在 Tomcat 或者 Jetty 上。

這種單體應用比較適合于小項目，優點是：

• 開發簡單直接，集中式管理
• 基本不會重復開發
• 功能都在本地，沒有分布式的管理開銷和調用開銷

當然它的缺點也十分明顯，特別對于互聯網公司來說：

• 開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷。
• 代碼維護難：代碼功能耦合在一起，新人不知道從何下手。
• 部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長。
• 穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉。
• 擴展性不夠：無法滿足高并發情況下的業務需求。

所以，現在主流的設計一般會采用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連接的微服務。

一個微服務完成某個特定功能，比如乘客管理和下單管理等。每個微服務都有自己的業務邏輯和適配器。一些微服務還會提供 API 接口給其他微服務和應用客戶端使用。

比如，前面描述的系統可被分解為：

每個業務邏輯都被分解為一個微服務，微服務之間通過 REST API 通信。一些微服務也會向終端用戶或客戶端開發 API 接口。

但通常情況下，這些客戶端并不能直接訪問后臺微服務，而是通過 API Gateway 來傳遞請求。API Gateway 一般負責服務路由、負載均衡、緩存、訪問控制和鑒權等任務。

微服務架構的優點

微服務架構有很多重要的優點。首先，它解決了復雜性問題。它將單體應用分解為一組服務。

雖然功能總量不變，但應用程序已被分解為可管理的模塊或服務。這些服務定義了明確的 RPC 或消息驅動的 API 邊界。

微服務架構強化了應用模塊化的水平，而這通過單體代碼庫很難實現。因此，微服務開發的速度要快很多，更容易理解和維護。

其次，這種體系結構使得每個服務都可以由專注于此服務的團隊獨立開發。只要符合服務 API 契約，開發人員可以自由選擇開發技術。

這就意味著開發人員可以采用新技術編寫或重構服務，由于服務相對較小，所以這并不會對整體應用造成太大影響。

第三，微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過后立即部署。所以微服務架構也使得 CI／CD 成為可能。

最后，微服務架構使得每個服務都可獨立擴展。我們只需定義滿足服務部署要求的配置、容量、實例數量等約束條件即可。

比如我們可以在 EC2 計算優化實例上部署 CPU 密集型服務，在 EC2 內存優化實例上部署內存數據庫服務。

微服務架構的缺點和挑戰

實際上并不存在 silver bullets，微服務架構也會給我們帶來新的問題和挑戰。其中一個就和它的名字類似，微服務強調了服務大小，但實際上這并沒有一個統一的標準。

業務邏輯應該按照什么規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張 10-100 行代碼就應該建立一個微服務。

雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發和持續集成部署。

微服務的另一個主要缺點是微服務的分布式特點帶來的復雜性。開發人員需要基于 RPC 或者消息實現微服務之間的調用和通信，而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的相當棘手。

微服務的另一個挑戰是分區的數據庫體系和分布式事務。更新多個業務實體的業務交易相當普遍。這些類型的事務在單體應用中實現非常簡單，因為單體應用往往只存在一個數據庫。

但在微服務架構下，不同服務可能擁有不同的數據庫。CAP 原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。

微服務架構對測試也帶來了很大的挑戰。傳統的單體 Web 應用只需測試單一的 REST API 即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種復雜性不可低估。

微服務的另一大挑戰是跨多個服務的更改。比如在傳統單體應用中，若有 A、B、C 三個服務需要更改，A 依賴 B，B 依賴 C。我們只需更改相應的模塊，然后一次性部署即可。

但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C，然后更新 B，最后更新 A。

部署基于微服務的應用也要復雜得多。單體應用可以簡單的部署在一組相同的服務器上，然后前端使用負載均衡即可。

每個應用都有相同的基礎服務地址，例如數據庫和消息隊列。而微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用實例數量以及基礎服務地址。這里就需要不同的配置、部署、擴展和監控組件。

此外，我們還需要服務發現機制，以便服務可以發現與其通信的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。

以上問題和挑戰可大體概括為：

• API Gateway
• 服務間調用
• 服務發現
• 服務容錯
• 服務部署
• 數據調用

幸運的是，出現了很多微服務框架，可以解決以上問題。

第一代微服務框架

Spring Cloud

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

Dubbo

Dubbo 是一個阿里巴巴開源出來的一個分布式服務框架，致力于提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案。

其核心部分包含：

• 遠程通訊：提供對多種基于長連接的 NIO 框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
• 集群容錯：提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
• 自動發現：基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

但是顯而易見，無論是 Dubbo 還是 Spring Cloud 都只適用于特定的應用場景和開發環境，它們的設計目的并不是為了支持通用性和多語言性。

并且它們只是 Dev 層的框架，缺少 DevOps 的整體解決方案（這正是微服務架構需要關注的）。而隨之而來的便是 Service Mesh 的興起。

下一代微服務：Service Mesh？

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，而最近 Buoyant（開源 Linkerd 的公司）又發布了基于 Kubernetes 的 Service Mesh 開源項目 Conduit。

Linkerd

Linkerd 是開源網絡代理，設計為以服務網格部署：用于管理，控制和監控應用程序內的服務與服務間通訊的專用層。

Linkerd 旨在解決 Twitter、Yahoo、Google 和 Microsoft 等公司運營大型生產系統時發現的問題。

根據經驗，最復雜，令人驚奇和緊急行為的來源通常不是服務本身，而是服務之間的通訊。Linkerd 解決了這些問題，不僅僅是控制通訊機制，而是在其上提供一個抽象層。

它的主要特性有：

• 負載平衡：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 支持分布式跟蹤和度量儀器，可以提供跨越所有服務的統一的可觀察性。

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 構建復雜的集中管理部署。

Istio

Istio 是一個用來連接、管理和保護微服務的開放平臺。Istio 提供一種簡單的方式來建立已部署服務網絡，具備負載均衡、服務間認證、監控等功能，而不需要改動任何服務代碼。

想要為服務增加對 Istio 的支持，您只需要在環境中部署一個特殊的邊車（sidecar），使用 Istio 控制面板功能配置和管理代理，攔截微服務之間的所有網絡通信。

Istio 目前僅支持在 Kubernetes 上的服務部署，但未來版本中將支持其他環境。

Istio 提供了一個完整的解決方案，通過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程序的多樣化需求。

它在服務網絡中統一提供了許多關鍵功能：

• 流量管理：控制服務之間的流量和 API 調用的流向，使得調用更可靠，并使網絡在惡劣情況下更加健壯。
• 可觀察性：了解服務之間的依賴關系，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。
• 策略執行：將組織策略應用于服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是通過配置網格而不是修改應用程序代碼。
• 服務身份和安全：為網格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網絡上流轉。

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

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

下圖顯示了構成每個面板的不同組件： 

Conduit

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

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

對比

Linkerd 和 Envoy 比較相似，都是一種面向服務通信的網絡代理，均可實現諸如服務發現、請求路由、負載均衡等功能。

它們的設計目標就是為了解決服務之間的通信問題，使得應用對服務通信無感知，這也是 Service Mesh 的核心理念。

Linkerd 和 Envoy 像是分布式的 Sidebar，多個類似 Linkerd 和 Envoy 的 proxy 互相連接，就組成了 Service Mesh。

而 Istio 則是站在了一個更高的角度，它將 Service Mesh 分為了 Data Plane 和 Control Plane。

Data Plane 負責微服務間的所有網絡通信，而 Control Plane 負責管理 Data Plane Proxy：

并且 Istio 天生的支持 Kubernetes，這也彌合了應用調度框架與 Service Mesh 之間的空隙。

關于 Conduit 的資料較少，從官方介紹看它的定位和功能與 Istio 類似。

Kubernetes + Service Mesh = 完整的微服務框架

Kubernetes 已經成為了容器調度編排的事實標準，而容器正好可以作為微服務的最小工作單元，從而發揮微服務架構的最大優勢。

所以我認為未來微服務架構會圍繞 Kubernetes 展開。而 Istio 和 Conduit 這類 Service Mesh 天生就是為了 Kubernetes 設計，它們的出現補足了 Kubernetes 在微服務間服務通訊上的短板。

雖然 Dubbo、Spring Cloud 等都是成熟的微服務框架，但是它們或多或少都會和具體語言或應用場景綁定，并只解決了微服務 Dev 層面的問題。

若想解決 Ops 問題，它們還需和諸如 Cloud Foundry、Mesos、Docker Swarm 或 Kubernetes 這類資源調度框架做結合：

但是這種結合又由于初始設計和生態，有很多適用性問題需要解決。

Kubernetes 則不同，它本身就是一個和開發語言無關的、通用的容器管理平臺，它可以支持運行云原生和傳統的容器化應用。

并且它覆蓋了微服務的 Dev 和 Ops 階段，結合 Service Mesh，它可以為用戶提供完整端到端的微服務體驗。

所以我認為，未來的微服務架構和技術棧可能是如下形式：

多云平臺為微服務提供了資源能力（計算、存儲和網絡等），容器作為最小工作單元被 Kubernetes 調度和編排，Service Mesh 管理微服務的服務通信，最后通過 API Gateway 向外暴露微服務的業務接口。

我相信未來隨著以 Kubernetes 和 Service Mesh 為標準的微服務框架的盛行，將大大降低微服務實施的成本，最終為微服務落地以及大規模使用提供堅實的基礎和保障。