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

作者：程小龍

單位：中移物聯網有限公司

1、引言

1.1 微服務的目的

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

1.2 微服務的核心要點

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

- 去中心化治理：微服務倡導去中心化的治理,，不推薦每個微服務都使用相同的標準和技術來開發(fā)和使用服務。

- 交互模式：在微服務領域,，微服務之間的交互通過定義良好的接口來實現,，不允許使用共享數據來實現。通常使用RESTful樣式的API或者透明的RPC調用,。

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

- 容錯模式：

? 熔斷

當服務的輸入負載迅速增加時,，如果沒有有效的措施對負載進行熔斷,，則會使服務迅速被壓垮,，服務被壓垮會導致依賴的服務都被壓垮，出現雪崩效應,，因此,，可通過模擬家庭的電路保險開關，在微服務架構中實現熔斷,。

? 限流

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

- 拆分粒度：

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

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

- 優(yōu)點

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

- 缺點

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

下文將介紹下幾種微服務架構的情況。

2,、Spring Cloud

2.1 整體架構

模塊交互流程圖

2.2 核心組件

2.3 特點

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

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

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

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

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

3,、Dubbo

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

3.1 整體架構

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

Dubbo分層結構設計圖

• config配置層

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

• proxy服務代理層

封裝了所有接口的透明化代理,，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時,，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker,，也就是去掉Proxy層RPC是可以Run的,，只是不那么透明，不那么像調本地服務一樣調遠程服務,；

• registry注冊中心層

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

• cluster路由層

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

• monitor監(jiān)控層

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

• protocol遠程調用層

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

• exchange信息交換層

封裝請求響應模式,，同步轉異步，以Request, Response為中心,，擴展接口為Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer,；

• transport網絡傳輸層

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

• serialize數據序列化層

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

3.2 核心組件

Spring Cloud與Dubbo功能對比

3.3 特點

4,、Spring Cloud Alibaba

4.1 整體架構

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

4.2 核心組件與特點

Nacos基本架構

Sentinel 的主要特性

Sentinel 的開源生態(tài)

與spring cloud相關組件對比

幾種服務治理組件對比

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

5、Service mesh

5.1 整體架構

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

基本架構圖

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

服務的網格化（mesh）

5.2 核心組件

Istio架構圖

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

5.3 特點

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

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

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

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

4、平臺開放與擴展主要通過Kubernetes CRD與Mesh Configuration Protocol（簡稱為MCP，一套標準GRPC協議）,。平臺默認支持Kubernetes基于ETCD的注冊中心機制,，可通過MCP機制對接更多諸如Consul、Eureka,、ZooKeeper等多注冊中心,；對服務治理策略的配置可通過定義Kubernetes CRD或實現MCP GRPC服務對接實現。

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

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

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

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

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

（2）Istio架構復雜,，一定的技術門檻,，掌握和實施成本較高，穩(wěn)定性及產品化應用有待驗證,；

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

6,、Service Comb

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

6.1 整體架構

6.2 核心組件

6.3 特點

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

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

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

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

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

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