微服務(wù)架構(gòu)旨在將大型，復(fù)雜的系統(tǒng)垂直（按功能或業(yè)務(wù)要求）劃分為較小的子系統(tǒng)，這些子系統(tǒng)屬于流程（因此可獨立部署），并且這些子系統(tǒng)之間通過與語言無關(guān)的輕量級網(wǎng)絡(luò)通信相互通信（例如REST，gRPC）或異步（通過消息傳遞）方式。

作者：程小龍

單位：中移物聯(lián)網(wǎng)有限公司

1、引言

1.1 微服務(wù)的目的

以拆分和服務(wù)化為基礎(chǔ)，將海量用戶產(chǎn)生的大規(guī)模的訪問流量進行分解，采用分而治之的方法，達(dá)成用戶需要的功能指標(biāo)，并同時滿足用戶對高可用、高性能、可伸縮、可擴展和安全性的非功能質(zhì)量的要求。

1.2 微服務(wù)的核心要點

- 業(yè)務(wù)的功能劃分：每個單一的業(yè)務(wù)功能叫做一個服務(wù)，每個服務(wù)對應(yīng)一個獨立的職能團隊。

- 去中心化治理：微服務(wù)倡導(dǎo)去中心化的治理，不推薦每個微服務(wù)都使用相同的標(biāo)準(zhǔn)和技術(shù)來開發(fā)和使用服務(wù)。

- 交互模式：在微服務(wù)領(lǐng)域，微服務(wù)之間的交互通過定義良好的接口來實現(xiàn)，不允許使用共享數(shù)據(jù)來實現(xiàn)。通常使用RESTful樣式的API或者透明的RPC調(diào)用。

- 組合依賴：根據(jù)業(yè)務(wù)流程處理的需要，以一定的順序調(diào)用依賴的多個微服務(wù)，對依賴的微服務(wù)返回的數(shù)據(jù)進行組合、加工和轉(zhuǎn)換，最后以一定的形式返回給使用方。

- 容錯模式：

? 熔斷

當(dāng)服務(wù)的輸入負(fù)載迅速增加時，如果沒有有效的措施對負(fù)載進行熔斷，則會使服務(wù)迅速被壓垮，服務(wù)被壓垮會導(dǎo)致依賴的服務(wù)都被壓垮，出現(xiàn)雪崩效應(yīng)，因此，可通過模擬家庭的電路保險開關(guān)，在微服務(wù)架構(gòu)中實現(xiàn)熔斷。

? 限流

針對服務(wù)突然上量，我們必須有限流機制，限流機制一般會控制訪問的并發(fā)量，例如每秒允許處理的并發(fā)數(shù)及查詢量、請求量等，實現(xiàn)方式如計數(shù)器，令牌桶等。

- 拆分粒度：

按照微服務(wù)的初衷，服務(wù)要按照業(yè)務(wù)的功能進行拆分，知道每個服務(wù)的功能和職責(zé)單一，甚至不可再拆分為止，以至于每個服務(wù)都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆的越細(xì)，服務(wù)的耦合度越小，內(nèi)聚性越好，越適合敏捷發(fā)布和上線。

1.3 微服務(wù)的優(yōu)點與缺點

- 優(yōu)點

• 每個微服務(wù)都很小，這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求；
• 微服務(wù)能夠被小團隊單獨開發(fā)，這個小團隊是2到5人的開發(fā)人員組成；
• 微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨立的；
• 微服務(wù)能使用不同的語言開發(fā)；
• 微服務(wù)易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關(guān)注自己的工作成果，無需通過合作才能體現(xiàn)價值；
• 微服務(wù)允許你利用融合最新技術(shù)；
• 微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。

- 缺點

• 微服務(wù)架構(gòu)可能帶來過多的操作；
• 需要DevOps技巧；
• 可能雙倍的努力；
• 分布式系統(tǒng)可能復(fù)雜難以管理；
• 因為分布部署跟蹤問題難；
• 當(dāng)服務(wù)數(shù)量增加，管理復(fù)雜性增加。

下文將介紹下幾種微服務(wù)架構(gòu)的情況。

2、Spring Cloud

2.1 整體架構(gòu)

模塊交互流程圖

2.2 核心組件

2.3 特點

1?? Spring Cloud利用SpringBoot的開發(fā)便利性巧妙的簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，組件支持豐富，功能齊全，為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)的一些工具，包括配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等。它們都可以用SpringBoot的開發(fā)風(fēng)格做到一鍵啟動和部署；

2?? 使用 HTTP 協(xié)議的 REST API，服務(wù)提供方和服務(wù)消費方通過 Json 數(shù)據(jù)格式交互，只需要定義好相關(guān) Json 字段即可，消費方和提供方無接口依賴。通過注解方式來實現(xiàn)服務(wù)配置，對于程序有一定入侵；

3?? 性能上因為是HTTP短連接，系統(tǒng)并發(fā)量和響應(yīng)時間不及RPC長連接方式（如Dubbo，相差三倍左右），在報文比較小，響應(yīng)時間要求嚴(yán)格的場景不太適合；

4??使用spring boot admin作為服務(wù)基本情況監(jiān)控，原理是Spring Boot Actuator組件；

5?? 部分組件的功能及穩(wěn)定性并未達(dá)到生產(chǎn)級別，使用者不多，需要引入其他功能相似組件。

3、Dubbo

Dubbo是一個分布式、高性能、透明化的RPC服務(wù)框架，提供服務(wù)自動注冊、自動發(fā)現(xiàn)等高效及多樣性服務(wù)治理方案，可以和Spring框架無縫集成。

3.1 整體架構(gòu)

• Provider：暴露服務(wù)的服務(wù)提供方；
• Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方，使用軟負(fù)載均衡算法；
• Registry：服務(wù)注冊與發(fā)現(xiàn)的注冊中心，如Zookeeper、Redis等；
• Monitor：統(tǒng)計服務(wù)的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心，服務(wù)消費者和提供者，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心；
• Container：服務(wù)運行容器；

Dubbo分層結(jié)構(gòu)設(shè)計圖

• config配置層

對外配置接口，以ServiceConfig, ReferenceConfig為中心，可以直接初始化配置類，也可以通過spring解析配置生成配置類；

• proxy服務(wù)代理層

封裝了所有接口的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉(zhuǎn)成接口，或?qū)⒔涌趯崿F(xiàn)轉(zhuǎn)成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那么透明，不那么像調(diào)本地服務(wù)一樣調(diào)遠(yuǎn)程服務(wù)；

• registry注冊中心層

封裝服務(wù)地址的注冊與發(fā)現(xiàn)，以服務(wù)URL為中心，擴展接口為 RegistryFactory, Registry, RegistryService；

• cluster路由層

封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心，以Invoker為中心，擴展接口為 Cluster, Directory, Router, LoadBalance；

• monitor監(jiān)控層

RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以Statistics為中心，擴展接口為 MonitorFactory, Monitor, MonitorService；

• protocol遠(yuǎn)程調(diào)用層

封裝RPC調(diào)用，以Invocation, Result 為中心，擴展接口為Protocol, Invoker, Exporter，Protocol是核心層，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調(diào)用，然后在Invoker的流程中實現(xiàn)Filter攔截點；

• exchange信息交換層

封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以Request, Response為中心，擴展接口為Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer；

• transport網(wǎng)絡(luò)傳輸層

抽象mina和netty為統(tǒng)一接口，以Message為中心，擴展接口為Channel, Transporter, Client, Server, Codec；

• serialize數(shù)據(jù)序列化層

可復(fù)用的一些工具，擴展接口為Serialization, ObjectInput, ObjectOutput, ThreadPool。

3.2 核心組件

Spring Cloud與Dubbo功能對比

3.3 特點

4、Spring Cloud Alibaba

4.1 整體架構(gòu)

類似Spring cloud的架構(gòu)，適配集成Alibaba的多種中間件，注冊中心換成了Nacos，限流熔斷從Hystrix換成了Sentinel，服務(wù)間調(diào)用可以使用Dubbo，使用RocketMQ作為消息總線及事件驅(qū)動組件，用Seata組件（前身是fescar）支持分布式事務(wù)功能，目前最新版本是2.1.0.RELEASE。

4.2 核心組件與特點

Nacos基本架構(gòu)

Sentinel 的主要特性

Sentinel 的開源生態(tài)

與spring cloud相關(guān)組件對比

幾種服務(wù)治理組件對比

使用demo：
https://www.jianshu.com/p/9a8d94c0c90c。

5、Service mesh

5.1 整體架構(gòu)

如下是簡化的Service Mesh架構(gòu)，服務(wù)A和服務(wù)B相互調(diào)用，不再是以前通過微服務(wù)框架直接指向的方式，而是在中間加了兩個叫做Sidecar（邊車）的東西，各種服務(wù)都在這里處理數(shù)據(jù)上的邏輯。Sidecar的作用是數(shù)據(jù)面的代理，貼近數(shù)據(jù)并受控于控制面。

基本架構(gòu)圖

實際業(yè)務(wù)中，尤其是中臺架構(gòu)下，企業(yè)往往需要很多的微服務(wù)，即服務(wù)A、服務(wù)B相互調(diào)用情形不斷擴展，逐漸形成更多的服務(wù)加Sidecar的組合，就變成了一個真正意義的Service Mesh。

服務(wù)的網(wǎng)格化（mesh）

5.2 核心組件

Istio架構(gòu)圖

主流云原生Service Mesh框架是Istio，Go語言實現(xiàn)，與容器編排系統(tǒng)Kubernetes一脈相承，下面介紹其主要組件，目前Istio版本為1.3.x release：

5.3 特點

1、Service Mesh所帶來的核心價值可以總結(jié)為：

• 基礎(chǔ)設(shè)施下沉 —— 微服務(wù)架構(gòu)支撐、網(wǎng)絡(luò)通信、治理等相關(guān)能力下沉到基礎(chǔ)設(shè)施層，業(yè)務(wù)部門無需投入專人開發(fā)與維護，可以有效降低微服務(wù)架構(gòu)下研發(fā)與維護成本；
• 降低升級成本 —— Sidecar支持熱升級，降低中間件和技術(shù)框架客戶端、SDK升級成本；
• 語言無關(guān) —— 提供多語言服務(wù)治理能力；
• 降低復(fù)雜測試、演練成本 —— 降低全鏈路壓測、故障演練成本和業(yè)務(wù)侵入性。

2、數(shù)據(jù)面以Envoy Proxy作為代理組件。通過Outbound流量攔截或顯示指向Envoy Proxy地址的方式代理發(fā)起請求流量，經(jīng)過Envoy Proxy的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、路由等數(shù)據(jù)面邏輯后，選擇目標(biāo)服務(wù)實例地址進行流量轉(zhuǎn)發(fā)；在Inbound流量接收端進行流量攔截（可配置是否攔截），對Inbound流量進行處理后轉(zhuǎn)發(fā)至目標(biāo)服務(wù)實例。

3、控制面以Pilot為核心組件。通過建立與Envoy Proxy雙向GRPC連接，實現(xiàn)服務(wù)注冊信息、服務(wù)治理策略的實時下發(fā)與同步。其他控制面組件Mixer（策略檢查、監(jiān)控、日志審計等）、Citadel（認(rèn)證與授權(quán)）、Galley（配置檢查）可在實際場景中配置關(guān)閉。

4、平臺開放與擴展主要通過Kubernetes CRD與Mesh Configuration Protocol（簡稱為MCP，一套標(biāo)準(zhǔn)GRPC協(xié)議）。平臺默認(rèn)支持Kubernetes基于ETCD的注冊中心機制，可通過MCP機制對接更多諸如Consul、Eureka、ZooKeeper等多注冊中心；對服務(wù)治理策略的配置可通過定義Kubernetes CRD或?qū)崿F(xiàn)MCP GRPC服務(wù)對接實現(xiàn)。

5、高可用設(shè)計主要基于Kubernetes及Istio機制實現(xiàn)。數(shù)據(jù)面Envoy Proxy以Init-Container方式與業(yè)務(wù)Container同時啟動，Istio提供了Pilot-agent組件實現(xiàn)對Envoy Proxy生命周期、升級的支持，保證Envoy Proxy的高可用?？刂泼嫠蠭stio組件均由Kubernetes多副本探針機制保證高可用性。Istio目前支持服務(wù)部署于Kubernetes、使用Consul注冊服務(wù)、服務(wù)運行于單個虛擬機上集成，自定義 Istio的策略執(zhí)行組件可以擴展和定制，以及與acl、日志記錄、監(jiān)視、配額、審核等現(xiàn)有解決方案集成。

6、Alibaba的對Istio架構(gòu)的改造落地實踐：
https://zhuanlan.zhihu.com/p/96720618。

實踐方案中放棄Istio 通過 iptables 的 NAT 表去做流量透明攔截的方式（NAT 表所使用到的 nf_contrack 內(nèi)核模塊效率很低），自研全新的透明攔截組件mangle；也沒有采用 Istio 中的 Mixer 組件，用內(nèi)部廣泛使用的 Sentinel 組件替代，每個請求都會經(jīng)過 Sentinel Filter 做處理。限流所需的配置信息則是通過 Pilot 從 Nacos 中獲取，并通過 xDS 協(xié)議下發(fā)到 Envoy 中，實踐中Service Mesh 的引入對于 RT 的影響和帶來的 CPU 開銷是基本一樣的，而內(nèi)存開銷則因為依賴服務(wù)和集群規(guī)模的不同而有相當(dāng)大的差異，Envoy 在內(nèi)存的使用上仍存在很大的優(yōu)化空間。

7、Service Mesh 離普及還面臨一定挑戰(zhàn)：

（1）性能尚存問題，服務(wù)間調(diào)用因為兩層Sidecar，請求鏈路多兩跳；Istio Mixer集中式后端成為性能瓶頸；

（2）Istio架構(gòu)復(fù)雜，一定的技術(shù)門檻，掌握和實施成本較高，穩(wěn)定性及產(chǎn)品化應(yīng)用有待驗證；

（3）真實落地的產(chǎn)品和企業(yè)還是比較少，提供的經(jīng)驗比較欠缺。

6、Service Comb

2018年10月24日， Apache軟件基金會宣布Apache ServiceComb 畢業(yè)成為Apache頂級項目。Apache ServiceComb已在數(shù)十家企業(yè)中使用，包括奇蛙智能科技、華為云、軟通動力，傳智播客、梅斯醫(yī)學(xué)、文思海輝、中國人保和同濟大學(xué)等。

6.1 整體架構(gòu)

6.2 核心組件

6.3 特點

1、異步內(nèi)核：基于VertX的同步和異步模型編程有效確保了無論是在傳統(tǒng)企業(yè)或電商領(lǐng)域，還是在新興的互聯(lián)網(wǎng)或物聯(lián)網(wǎng)等新興企業(yè)中，都能夠保持高性能和低延遲，以避免在達(dá)到峰值負(fù)載時應(yīng)用出現(xiàn)雪崩效應(yīng)；

2、ServiceComb支持多種通信協(xié)議, Rest、Highway（RPC）等，相比SpringCloud的Rest協(xié)議，Highway（RPC）協(xié)議性能更高，Highway是基于二進制的序列化方式傳輸數(shù)據(jù)，采用二進制編碼的系統(tǒng)的性能遠(yuǎn)高于采用文本的HTTP協(xié)議；

3、開箱即用體驗，開發(fā)簡單，開發(fā)人員通過腳手架網(wǎng)站start.servicecomb.io啟動的微服務(wù)項目，可以集服務(wù)注冊、發(fā)現(xiàn)、通信和微服務(wù)治理能力和默認(rèn)的集中化配置為一體；

4、ServiceComb的商業(yè)版本CSE相比SpringCloud不僅提供了微服務(wù)開發(fā)框架，還提供了微服務(wù)云部署，管理、治理等一站式解決方案；

5、OpenAPI自動代碼生成，業(yè)務(wù)邏輯代碼和治理能力隔離，可以使能DevOps Pipeline， 使用契約文件和OpenAPI的雙向生成能力可以使不同的團隊高效且獨立的開發(fā)和管理代碼、測試和進行文檔化工作；

6、官網(wǎng)上的文檔資料比較簡略，網(wǎng)上可借鑒的實現(xiàn)案例不多，demo：
https://blog.csdn.net/zengdongwen/article/details/93486257。