近幾年，微服務(wù)技術(shù)得以迅猛普及，而以 Spring Cloud、Dubbo 為代表較為成熟的微服務(wù)開(kāi)發(fā)框架，占據(jù)著市場(chǎng)的主流地位，它們甚至一度成為微服務(wù)的代名詞。

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供鳳城企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、html5、小程序制作等業(yè)務(wù)。10年已為鳳城眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

什么是微服務(wù)

首先微服務(wù)并沒(méi)有一個(gè)官方的定義，想要直接描述微服務(wù)比較困難，我們可以通過(guò)對(duì)比傳統(tǒng) Web 應(yīng)用，來(lái)理解什么是微服務(wù)。

傳統(tǒng)的 Web 應(yīng)用核心分為業(yè)務(wù)邏輯、適配器以及 API 或通過(guò) UI 訪問(wèn)的 Web 界面。業(yè)務(wù)邏輯定義業(yè)務(wù)流程、業(yè)務(wù)規(guī)則以及領(lǐng)域?qū)嶓w。適配器包括數(shù)據(jù)庫(kù)訪問(wèn)組件、消息組件以及訪問(wèn)接口等。

一個(gè)打車軟件的架構(gòu)圖如下：

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

這種單體應(yīng)用比較適合于小項(xiàng)目，優(yōu)點(diǎn)是：

• 開(kāi)發(fā)簡(jiǎn)單直接，集中式管理
• 基本不會(huì)重復(fù)開(kāi)發(fā)
• 功能都在本地，沒(méi)有分布式的管理開(kāi)銷和調(diào)用開(kāi)銷

當(dāng)然它的缺點(diǎn)也十分明顯，特別對(duì)于互聯(lián)網(wǎng)公司來(lái)說(shuō)：

• 開(kāi)發(fā)效率低：所有的開(kāi)發(fā)在一個(gè)項(xiàng)目改代碼，遞交代碼相互等待，代碼沖突不斷。
• 代碼維護(hù)難：代碼功能耦合在一起，新人不知道從何下手。
• 部署不靈活：構(gòu)建時(shí)間長(zhǎng)，任何小修改必須重新構(gòu)建整個(gè)項(xiàng)目，這個(gè)過(guò)程往往很長(zhǎng)。
• 穩(wěn)定性不高：一個(gè)微不足道的小問(wèn)題，可以導(dǎo)致整個(gè)應(yīng)用掛掉。
• 擴(kuò)展性不夠：無(wú)法滿足高并發(fā)情況下的業(yè)務(wù)需求。

所以，現(xiàn)在主流的設(shè)計(jì)一般會(huì)采用微服務(wù)架構(gòu)。其思路不是開(kāi)發(fā)一個(gè)巨大的單體式應(yīng)用，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。

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

比如，前面描述的系統(tǒng)可被分解為：

每個(gè)業(yè)務(wù)邏輯都被分解為一個(gè)微服務(wù)，微服務(wù)之間通過(guò) REST API 通信。一些微服務(wù)也會(huì)向終端用戶或客戶端開(kāi)發(fā) API 接口。

但通常情況下，這些客戶端并不能直接訪問(wèn)后臺(tái)微服務(wù)，而是通過(guò) API Gateway 來(lái)傳遞請(qǐng)求。API Gateway 一般負(fù)責(zé)服務(wù)路由、負(fù)載均衡、緩存、訪問(wèn)控制和鑒權(quán)等任務(wù)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)

微服務(wù)架構(gòu)有很多重要的優(yōu)點(diǎn)。首先，它解決了復(fù)雜性問(wèn)題。它將單體應(yīng)用分解為一組服務(wù)。

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

微服務(wù)架構(gòu)強(qiáng)化了應(yīng)用模塊化的水平，而這通過(guò)單體代碼庫(kù)很難實(shí)現(xiàn)。因此，微服務(wù)開(kāi)發(fā)的速度要快很多，更容易理解和維護(hù)。

其次，這種體系結(jié)構(gòu)使得每個(gè)服務(wù)都可以由專注于此服務(wù)的團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)。只要符合服務(wù) API 契約，開(kāi)發(fā)人員可以自由選擇開(kāi)發(fā)技術(shù)。

這就意味著開(kāi)發(fā)人員可以采用新技術(shù)編寫(xiě)或重構(gòu)服務(wù)，由于服務(wù)相對(duì)較小，所以這并不會(huì)對(duì)整體應(yīng)用造成太大影響。

第三，微服務(wù)架構(gòu)可以使每個(gè)微服務(wù)獨(dú)立部署。開(kāi)發(fā)人員無(wú)需協(xié)調(diào)對(duì)服務(wù)升級(jí)或更改的部署。這些更改可以在測(cè)試通過(guò)后立即部署。所以微服務(wù)架構(gòu)也使得 CI／CD 成為可能。

最后，微服務(wù)架構(gòu)使得每個(gè)服務(wù)都可獨(dú)立擴(kuò)展。我們只需定義滿足服務(wù)部署要求的配置、容量、實(shí)例數(shù)量等約束條件即可。

比如我們可以在 EC2 計(jì)算優(yōu)化實(shí)例上部署 CPU 密集型服務(wù)，在 EC2 內(nèi)存優(yōu)化實(shí)例上部署內(nèi)存數(shù)據(jù)庫(kù)服務(wù)。

微服務(wù)架構(gòu)的缺點(diǎn)和挑戰(zhàn)

實(shí)際上并不存在 silver bullets，微服務(wù)架構(gòu)也會(huì)給我們帶來(lái)新的問(wèn)題和挑戰(zhàn)。其中一個(gè)就和它的名字類似，微服務(wù)強(qiáng)調(diào)了服務(wù)大小，但實(shí)際上這并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。

業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)，這本身就是一個(gè)經(jīng)驗(yàn)工程。有些開(kāi)發(fā)者主張 10-100 行代碼就應(yīng)該建立一個(gè)微服務(wù)。

雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的，但要記住，微服務(wù)是達(dá)到目的的手段，而不是目標(biāo)。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以促進(jìn)敏捷開(kāi)發(fā)和持續(xù)集成部署。

微服務(wù)的另一個(gè)主要缺點(diǎn)是微服務(wù)的分布式特點(diǎn)帶來(lái)的復(fù)雜性。開(kāi)發(fā)人員需要基于 RPC 或者消息實(shí)現(xiàn)微服務(wù)之間的調(diào)用和通信，而這就使得服務(wù)之間的發(fā)現(xiàn)、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問(wèn)題變得的相當(dāng)棘手。

微服務(wù)的另一個(gè)挑戰(zhàn)是分區(qū)的數(shù)據(jù)庫(kù)體系和分布式事務(wù)。更新多個(gè)業(yè)務(wù)實(shí)體的業(yè)務(wù)交易相當(dāng)普遍。這些類型的事務(wù)在單體應(yīng)用中實(shí)現(xiàn)非常簡(jiǎn)單，因?yàn)閱误w應(yīng)用往往只存在一個(gè)數(shù)據(jù)庫(kù)。

但在微服務(wù)架構(gòu)下，不同服務(wù)可能擁有不同的數(shù)據(jù)庫(kù)。CAP 原理的約束，使得我們不得不放棄傳統(tǒng)的強(qiáng)一致性，而轉(zhuǎn)而追求最終一致性，這個(gè)對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是一個(gè)挑戰(zhàn)。

微服務(wù)架構(gòu)對(duì)測(cè)試也帶來(lái)了很大的挑戰(zhàn)。傳統(tǒng)的單體 Web 應(yīng)用只需測(cè)試單一的 REST API 即可，而對(duì)微服務(wù)進(jìn)行測(cè)試，需要啟動(dòng)它依賴的所有其他服務(wù)。這種復(fù)雜性不可低估。

微服務(wù)的另一大挑戰(zhàn)是跨多個(gè)服務(wù)的更改。比如在傳統(tǒng)單體應(yīng)用中，若有 A、B、C 三個(gè)服務(wù)需要更改，A 依賴 B，B 依賴 C。我們只需更改相應(yīng)的模塊，然后一次性部署即可。

但是在微服務(wù)架構(gòu)中，我們需要仔細(xì)規(guī)劃和協(xié)調(diào)每個(gè)服務(wù)的變更部署。我們需要先更新 C，然后更新 B，最后更新 A。

部署基于微服務(wù)的應(yīng)用也要復(fù)雜得多。單體應(yīng)用可以簡(jiǎn)單的部署在一組相同的服務(wù)器上，然后前端使用負(fù)載均衡即可。

每個(gè)應(yīng)用都有相同的基礎(chǔ)服務(wù)地址，例如數(shù)據(jù)庫(kù)和消息隊(duì)列。而微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置、應(yīng)用實(shí)例數(shù)量以及基礎(chǔ)服務(wù)地址。這里就需要不同的配置、部署、擴(kuò)展和監(jiān)控組件。

此外，我們還需要服務(wù)發(fā)現(xiàn)機(jī)制，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址。因此，成功部署微服務(wù)應(yīng)用需要開(kāi)發(fā)人員有更好地部署策略和高度自動(dòng)化的水平。

以上問(wèn)題和挑戰(zhàn)可大體概括為：

• API Gateway
• 服務(wù)間調(diào)用
• 服務(wù)發(fā)現(xiàn)
• 服務(wù)容錯(cuò)
• 服務(wù)部署
• 數(shù)據(jù)調(diào)用

幸運(yùn)的是，出現(xiàn)了很多微服務(wù)框架，可以解決以上問(wèn)題。

第一代微服務(wù)框架

Spring Cloud

Spring Cloud 為開(kāi)發(fā)者提供了快速構(gòu)建分布式系統(tǒng)的通用模型的工具（包括配置管理、服務(wù)發(fā)現(xiàn)、熔斷器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領(lǐng)導(dǎo)選舉、分布式會(huì)話、集群狀態(tài)等）。

主要項(xiàng)目包括：

• Spring Cloud Config：由 Git 存儲(chǔ)庫(kù)支持的集中式外部配置管理。配置資源直接映射到 Spring Environment，但是如果需要可以被非 Spring 應(yīng)用程序使用。
• Spring Cloud Netflix：與各種 Netflix OSS 組件（Eureka，Hystrix，Zuul，Archaius等）集成。
• Spring Cloud Bus：用于將服務(wù)和服務(wù)實(shí)例與分布式消息傳遞聯(lián)系起來(lái)的事件總線。用于在集群中傳播狀態(tài)更改（例如配置更改事件）。
• Spring Cloud for Cloudfoundry：將您的應(yīng)用程序與 Pivotal Cloudfoundry 集成。提供服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)，還可以輕松實(shí)現(xiàn)通過(guò) SSO 和 OAuth 2 保護(hù)資源，還可以創(chuàng)建 Cloudfoundry 服務(wù)代理。
• Spring Cloud - Cloud Foundry Service Broker：提供構(gòu)建管理一個(gè) Cloud Foundry 中服務(wù)的服務(wù)代理的起點(diǎn)。
• Spring Cloud Cluster：領(lǐng)導(dǎo)選舉和通用狀態(tài)模型（基于 ZooKeeper，Redis，Hazelcast，Consul 的抽象和實(shí)現(xiàn)）。
• Spring Cloud Consul：結(jié)合 Hashicorp Consul 的服務(wù)發(fā)現(xiàn)和配置管理。
• Spring Cloud Security：在 Zuul 代理中為負(fù)載平衡的 OAuth 2 休眠客戶端和認(rèn)證頭中繼提供支持。
• Spring Cloud Sleuth：適用于 Spring Cloud 應(yīng)用程序的分布式跟蹤，與 Zipkin，HTrace 和基于日志（例如 ELK）跟蹤兼容。
• Spring Cloud Data Flow：針對(duì)現(xiàn)代運(yùn)行時(shí)的可組合微服務(wù)應(yīng)用程序的云本地編排服務(wù)。易于使用的 DSL，拖放式 GUI 和 REST-API 一起簡(jiǎn)化了基于微服務(wù)的數(shù)據(jù)管道的整體編排。
• Spring Cloud Stream：輕量級(jí)事件驅(qū)動(dòng)的微服務(wù)框架，可快速構(gòu)建可連接到外部系統(tǒng)的應(yīng)用程序。使用 Apache Kafka 或 RabbitMQ 在 Spring Boot 應(yīng)用程序之間發(fā)送和接收消息的簡(jiǎn)單聲明式模型。
• Spring Cloud Stream Application Starters：Spring Cloud 任務(wù)應(yīng)用程序啟動(dòng)器是 Spring Boot 應(yīng)用程序，可能是任何進(jìn)程，包括不會(huì)永遠(yuǎn)運(yùn)行的 Spring Batch 作業(yè)，并且它們?cè)谟邢迺r(shí)間的數(shù)據(jù)處理之后結(jié)束/停止。
• Spring Cloud ZooKeeper：ZooKeeper 的服務(wù)發(fā)現(xiàn)和配置管理。
• Spring Cloud for Amazon Web Services：輕松集成托管的 Amazon 的 Web Services 服務(wù)。它通過(guò)使用 Spring 的 idioms 和 APIs 便捷集成 AWS 服務(wù)，例如緩存或消息 API。開(kāi)發(fā)人員可以圍繞托管服務(wù)，不必關(guān)心基礎(chǔ)架構(gòu)來(lái)構(gòu)建應(yīng)用。
• Spring Cloud Connectors：使 PaaS 應(yīng)用程序在各種平臺(tái)上輕松連接到后端服務(wù)，如數(shù)據(jù)庫(kù)和消息代理（以前稱為“Spring Cloud”的項(xiàng)目）。
• Spring Cloud Starters：作為基于 Spring Boot 的啟動(dòng)項(xiàng)目，降低依賴管理（在 Angel.SR2 后，不再作為獨(dú)立項(xiàng)目）。
• Spring Cloud CLI：插件支持基于 Groovy 預(yù)言快速創(chuàng)建 Spring Cloud 的組件應(yīng)用。

Dubbo

Dubbo 是一個(gè)阿里巴巴開(kāi)源出來(lái)的一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化的 RPC 遠(yuǎn)程服務(wù)調(diào)用方案，以及 SOA 服務(wù)治理方案。

其核心部分包含：

• 遠(yuǎn)程通訊：提供對(duì)多種基于長(zhǎng)連接的 NIO 框架抽象封裝，包括多種線程模型，序列化，以及“請(qǐng)求-響應(yīng)”模式的信息交換方式。
• 集群容錯(cuò)：提供基于接口方法的透明遠(yuǎn)程過(guò)程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。
• 自動(dòng)發(fā)現(xiàn)：基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

但是顯而易見(jiàn)，無(wú)論是 Dubbo 還是 Spring Cloud 都只適用于特定的應(yīng)用場(chǎng)景和開(kāi)發(fā)環(huán)境，它們的設(shè)計(jì)目的并不是為了支持通用性和多語(yǔ)言性。

并且它們只是 Dev 層的框架，缺少 DevOps 的整體解決方案（這正是微服務(wù)架構(gòu)需要關(guān)注的）。而隨之而來(lái)的便是 Service Mesh 的興起。

下一代微服務(wù)：Service Mesh？

Service Mesh

Service Mesh 又譯作“服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。如果用一句話來(lái)解釋什么是 Service Mesh，可以將它比作是應(yīng)用程序或者說(shuō)微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控。

對(duì)于編寫(xiě)應(yīng)用程序來(lái)說(shuō)一般無(wú)須關(guān)心 TCP/IP 這一層（比如通過(guò) HTTP 協(xié)議的 RESTful 應(yīng)用）。

同樣使用 Service Mesh 也就無(wú)須關(guān)系服務(wù)之間的那些原來(lái)是通過(guò)應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。

Service Mesh 有如下幾個(gè)特點(diǎn)：

• 應(yīng)用程序間通訊的中間層
• 輕量級(jí)網(wǎng)絡(luò)代理
• 應(yīng)用程序無(wú)感知
• 解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)

Service Mesh 的架構(gòu)如下圖所示：

Service Mesh 作為 Sidebar 運(yùn)行，對(duì)應(yīng)用程序來(lái)說(shuō)是透明，所有應(yīng)用程序間的流量都會(huì)通過(guò)它，所以對(duì)應(yīng)用程序流量的控制都可以在 Service Mesh 中實(shí)現(xiàn)。

目前流行的 Service Mesh 開(kāi)源軟件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（開(kāi)源 Linkerd 的公司）又發(fā)布了基于 Kubernetes 的 Service Mesh 開(kāi)源項(xiàng)目 Conduit。

Linkerd

Linkerd 是開(kāi)源網(wǎng)絡(luò)代理，設(shè)計(jì)為以服務(wù)網(wǎng)格部署：用于管理，控制和監(jiān)控應(yīng)用程序內(nèi)的服務(wù)與服務(wù)間通訊的專用層。

Linkerd 旨在解決 Twitter、Yahoo、Google 和 Microsoft 等公司運(yùn)營(yíng)大型生產(chǎn)系統(tǒng)時(shí)發(fā)現(xiàn)的問(wèn)題。

根據(jù)經(jīng)驗(yàn)，最復(fù)雜，令人驚奇和緊急行為的來(lái)源通常不是服務(wù)本身，而是服務(wù)之間的通訊。Linkerd 解決了這些問(wèn)題，不僅僅是控制通訊機(jī)制，而是在其上提供一個(gè)抽象層。

它的主要特性有：

• 負(fù)載平衡：Linkerd 提供了多種負(fù)載均衡算法，它們使用實(shí)時(shí)性能指標(biāo)來(lái)分配負(fù)載并減少整個(gè)應(yīng)用程序的尾部延遲。
• 熔斷：Linkerd 包含自動(dòng)熔斷，將停止將流量發(fā)送到被認(rèn)為不健康的實(shí)例，從而使他們有機(jī)會(huì)恢復(fù)并避免連鎖反應(yīng)故障。
• 服務(wù)發(fā)現(xiàn)：Linkerd 與各種服務(wù)發(fā)現(xiàn)后端集成，通過(guò)刪除特定的(ad-hoc)服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)來(lái)幫助您降低代碼的復(fù)雜性。
• 動(dòng)態(tài)請(qǐng)求路由：Linkerd 啟用動(dòng)態(tài)請(qǐng)求路由和重新路由，允許您使用最少量的配置來(lái)設(shè)置分段服務(wù)（staging service），金絲雀（canaries），藍(lán)綠部署（blue-green deploy），跨 DC 故障切換和黑暗流量（dark traffic）。
• 重試次數(shù)和截止日期：Linkerd 可以在某些故障時(shí)自動(dòng)重試請(qǐng)求，并且可以在指定的時(shí)間段之后讓請(qǐng)求超時(shí)。
• TLS：Linkerd 可以配置為使用 TLS 發(fā)送和接收請(qǐng)求，您可以使用它來(lái)加密跨主機(jī)邊界的通信，而不用修改現(xiàn)有的應(yīng)用程序代碼。
• HTTP 代理集成：Linkerd 可以作為 HTTP 代理，幾乎所有現(xiàn)代 HTTP 客戶端都廣泛支持，使其易于集成到現(xiàn)有應(yīng)用程序中。
• 透明代理：您可以在主機(jī)上使用 iptables 規(guī)則，設(shè)置通過(guò) Linkerd 的透明代理。
• gRPC：Linkerd 支持 HTTP/2 和 TLS，允許它路由 gRPC 請(qǐng)求，支持高級(jí) RPC 機(jī)制，如雙向流，流程控制和結(jié)構(gòu)化數(shù)據(jù)負(fù)載。
• 分布式跟蹤：Linkerd 支持分布式跟蹤和度量?jī)x器，可以提供跨越所有服務(wù)的統(tǒng)一的可觀察性。
• 儀器儀表：Linkerd 支持分布式跟蹤和度量?jī)x器，可以提供跨越所有服務(wù)的統(tǒng)一的可觀察性。

Envoy

Envoy 是一個(gè)面向服務(wù)架構(gòu)的 L7 代理和通信總線而設(shè)計(jì)的，這個(gè)項(xiàng)目誕生是出于以下目標(biāo)：

對(duì)于應(yīng)用程序而言，網(wǎng)絡(luò)應(yīng)該是透明的，當(dāng)發(fā)生網(wǎng)絡(luò)和應(yīng)用程序故障時(shí)，能夠很容易定位出問(wèn)題的根源。

Envoy 可提供以下特性：

• 外置進(jìn)程架構(gòu)：可與任何語(yǔ)言開(kāi)發(fā)的應(yīng)用一起工作；可快速升級(jí)。
• 基于新 C++11 編碼：能夠提供高效的性能。
• L3/L4 過(guò)濾器：核心是一個(gè) L3/L4 網(wǎng)絡(luò)代理，能夠作為一個(gè)可編程過(guò)濾器實(shí)現(xiàn)不同 TCP 代理任務(wù)，插入到主服務(wù)當(dāng)中。通過(guò)編寫(xiě)過(guò)濾器來(lái)支持各種任務(wù)，如原始 TCP 代理、HTTP 代理、TLS 客戶端證書(shū)身份驗(yàn)證等。
• HTTP L7 過(guò)濾器：支持一個(gè)額外的 HTTP L7 過(guò)濾層。HTTP 過(guò)濾器作為一個(gè)插件，插入到 HTTP 鏈接管理子系統(tǒng)中，從而執(zhí)行不同的任務(wù)，如緩沖，速率限制，路由/轉(zhuǎn)發(fā)，嗅探 Amazon 的 DynamoDB 等等。
• 支持 HTTP/2：在 HTTP 模式下，支持 HTTP/1.1、HTTP/2，并且支持 HTTP/1.1、HTTP/2 雙向代理。這意味著 HTTP/1.1 和 HTTP/2，在客戶機(jī)和目標(biāo)服務(wù)器的任何組合都可以橋接。
• HTTP L7 路由：在 HTTP 模式下運(yùn)行時(shí)，支持根據(jù) content type、runtime values 等，基于 path 的路由和重定向?？捎糜诜?wù)的前端／邊緣代理。
• 支持 gRPC：gRPC 是一個(gè)來(lái)自谷歌的 RPC 框架，使用 HTTP/2 作為底層的多路傳輸。HTTP/2 承載的 gRPC 請(qǐng)求和應(yīng)答，都可以使用 Envoy 的路由和 LB 能力。
• 支持 MongoDB L7：支持獲取統(tǒng)計(jì)和連接記錄等信息。
• 支持 DynamoDB L7：支持獲取統(tǒng)計(jì)和連接等信息。
• 服務(wù)發(fā)現(xiàn)：支持多種服務(wù)發(fā)現(xiàn)方法，包括異步 DNS 解析和通過(guò) REST 請(qǐng)求服務(wù)發(fā)現(xiàn)服務(wù)。
• 健康檢查：含有一個(gè)健康檢查子系統(tǒng)，可以對(duì)上游服務(wù)集群進(jìn)行主動(dòng)的健康檢查。也支持被動(dòng)健康檢查。
• 高級(jí) LB：包括自動(dòng)重試、斷路器，全局限速，阻隔請(qǐng)求，異常檢測(cè)。未來(lái)還計(jì)劃支持請(qǐng)求速率控制。
• 前端代理：可作為前端代理，包括 TLS、HTTP/1.1、HTTP/2，以及 HTTP L7 路由。
• 極好的可觀察性：對(duì)所有子系統(tǒng)，提供了可靠的統(tǒng)計(jì)能力。目前支持 statsd 以及兼容的統(tǒng)計(jì)庫(kù)。還可以通過(guò)管理端口查看統(tǒng)計(jì)信息，還支持第三方的分布式跟蹤機(jī)制。
• 動(dòng)態(tài)配置：提供分層的動(dòng)態(tài)配置 API，用戶可以使用這些 API 構(gòu)建復(fù)雜的集中管理部署。

Istio

Istio 是一個(gè)用來(lái)連接、管理和保護(hù)微服務(wù)的開(kāi)放平臺(tái)。Istio 提供一種簡(jiǎn)單的方式來(lái)建立已部署服務(wù)網(wǎng)絡(luò)，具備負(fù)載均衡、服務(wù)間認(rèn)證、監(jiān)控等功能，而不需要改動(dòng)任何服務(wù)代碼。

想要為服務(wù)增加對(duì) Istio 的支持，您只需要在環(huán)境中部署一個(gè)特殊的邊車（sidecar），使用 Istio 控制面板功能配置和管理代理，攔截微服務(wù)之間的所有網(wǎng)絡(luò)通信。

Istio 目前僅支持在 Kubernetes 上的服務(wù)部署，但未來(lái)版本中將支持其他環(huán)境。

Istio 提供了一個(gè)完整的解決方案，通過(guò)為整個(gè)服務(wù)網(wǎng)格提供行為洞察和操作控制來(lái)滿足微服務(wù)應(yīng)用程序的多樣化需求。

它在服務(wù)網(wǎng)絡(luò)中統(tǒng)一提供了許多關(guān)鍵功能：

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

Istio 服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)面板和控制面板：

• 數(shù)據(jù)面板由一組智能代理（Envoy）組成，代理部署為邊車，調(diào)解和控制微服務(wù)之間所有的網(wǎng)絡(luò)通信。
• 控制面板負(fù)責(zé)管理和配置代理來(lái)路由流量，以及在運(yùn)行時(shí)執(zhí)行策略。

下圖顯示了構(gòu)成每個(gè)面板的不同組件： 

Conduit

Conduit 是為 Kubernetes 設(shè)計(jì)的一個(gè)超輕型服務(wù)網(wǎng)格服務(wù)，它可透明地管理在 Kubernetes 上運(yùn)行的服務(wù)的運(yùn)行時(shí)通信，使得它們更安全可靠。Conduit 提供了可見(jiàn)性、可靠性和安全性的功能，而無(wú)需更改代碼。

Conduit service mesh 也是由數(shù)據(jù)面板和控制面板組成。數(shù)據(jù)面板承載應(yīng)用實(shí)際的網(wǎng)絡(luò)流量。控制面板驅(qū)動(dòng)數(shù)據(jù)面板，并對(duì)外提供北向接口。

對(duì)比

Linkerd 和 Envoy 比較相似，都是一種面向服務(wù)通信的網(wǎng)絡(luò)代理，均可實(shí)現(xiàn)諸如服務(wù)發(fā)現(xiàn)、請(qǐng)求路由、負(fù)載均衡等功能。

它們的設(shè)計(jì)目標(biāo)就是為了解決服務(wù)之間的通信問(wèn)題，使得應(yīng)用對(duì)服務(wù)通信無(wú)感知，這也是 Service Mesh 的核心理念。

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

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

Data Plane 負(fù)責(zé)微服務(wù)間的所有網(wǎng)絡(luò)通信，而 Control Plane 負(fù)責(zé)管理 Data Plane Proxy：

并且 Istio 天生的支持 Kubernetes，這也彌合了應(yīng)用調(diào)度框架與 Service Mesh 之間的空隙。

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

Kubernetes + Service Mesh = 完整的微服務(wù)框架

Kubernetes 已經(jīng)成為了容器調(diào)度編排的事實(shí)標(biāo)準(zhǔn)，而容器正好可以作為微服務(wù)的最小工作單元，從而發(fā)揮微服務(wù)架構(gòu)的最大優(yōu)勢(shì)。

所以我認(rèn)為未來(lái)微服務(wù)架構(gòu)會(huì)圍繞 Kubernetes 展開(kāi)。而 Istio 和 Conduit 這類 Service Mesh 天生就是為了 Kubernetes 設(shè)計(jì)，它們的出現(xiàn)補(bǔ)足了 Kubernetes 在微服務(wù)間服務(wù)通訊上的短板。

雖然 Dubbo、Spring Cloud 等都是成熟的微服務(wù)框架，但是它們或多或少都會(huì)和具體語(yǔ)言或應(yīng)用場(chǎng)景綁定，并只解決了微服務(wù) Dev 層面的問(wèn)題。

若想解決 Ops 問(wèn)題，它們還需和諸如 Cloud Foundry、Mesos、Docker Swarm 或 Kubernetes 這類資源調(diào)度框架做結(jié)合：

但是這種結(jié)合又由于初始設(shè)計(jì)和生態(tài)，有很多適用性問(wèn)題需要解決。

Kubernetes 則不同，它本身就是一個(gè)和開(kāi)發(fā)語(yǔ)言無(wú)關(guān)的、通用的容器管理平臺(tái)，它可以支持運(yùn)行云原生和傳統(tǒng)的容器化應(yīng)用。

并且它覆蓋了微服務(wù)的 Dev 和 Ops 階段，結(jié)合 Service Mesh，它可以為用戶提供完整端到端的微服務(wù)體驗(yàn)。

所以我認(rèn)為，未來(lái)的微服務(wù)架構(gòu)和技術(shù)?？赡苁侨缦滦问剑?/p>

多云平臺(tái)為微服務(wù)提供了資源能力（計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等），容器作為最小工作單元被 Kubernetes 調(diào)度和編排，Service Mesh 管理微服務(wù)的服務(wù)通信，最后通過(guò) API Gateway 向外暴露微服務(wù)的業(yè)務(wù)接口。

我相信未來(lái)隨著以 Kubernetes 和 Service Mesh 為標(biāo)準(zhǔn)的微服務(wù)框架的盛行，將大大降低微服務(wù)實(shí)施的成本，最終為微服務(wù)落地以及大規(guī)模使用提供堅(jiān)實(shí)的基礎(chǔ)和保障。

名稱欄目：微服務(wù)并非SpringCloud和Dubbo，下一代微服務(wù)是什么？
URL分享：http://uogjgqi.cn/article/djeepcg.html