一、引言

1.1 微服務的目的

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

1.2 微服務的核心要點

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

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

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

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

容錯模式：

 熔斷

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

限流

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

拆分粒度：

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

1.3 微服務的優點與缺點

優點

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

缺點

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

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

二、Spring Cloud

2.1 整體架構

模塊交互流程圖

2.2 核心組件

2.3 特點

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

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

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

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

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

三、Dubbo

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

3.1 整體架構

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

Dubbo分層結構設計圖

• config配置層

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

• proxy服務代理層

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

• registry注冊中心層

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

• cluster路由層

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

• monitor監控層

RPC調用次數和調用時間監控，以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為統一接口，以Message為中心，擴展接口為Channel, Transporter, Client, Server, Codec；

• serialize數據序列化層

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

3.2 核心組件

Spring Cloud與Dubbo功能對比

3.3 特點

四、Spring Cloud Alibaba

4.1 整體架構

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

4.2 核心組件與特點

Nacos基本架構

Sentinel 的主要特性

Sentinel 的開源生態

與spring cloud相關組件對比

幾種服務治理組件對比

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

五、Service mes

5.1 整體架構

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

基本架構圖

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

服務的網格化（mesh）

5.2 核心組件

Istio架構圖

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

5.3 特點

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

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

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

3、控制面以Pilot為核心組件。通過建立與Envoy Proxy雙向GRPC連接，實現服務注冊信息、服務治理策略的實時下發與同步。其他控制面組件Mixer（策略檢查、監控、日志審計等）、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方式與業務Container同時啟動，Istio提供了Pilot-agent組件實現對Envoy Proxy生命周期、升級的支持，保證Envoy Proxy的高可用。控制面所有Istio組件均由Kubernetes多副本探針機制保證高可用性。Istio目前支持服務部署于Kubernetes、使用Consul注冊服務、服務運行于單個虛擬機上集成，自定義 Istio的策略執行組件可以擴展和定制，以及與acl、日志記錄、監視、配額、審核等現有解決方案集成。

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

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

7、Service Mesh 離普及還面臨一定挑戰：

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

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

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

六、Service Comb

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

6.1 整體架構

6.2 核心組件

6.3 特點

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

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

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

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

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

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