一、引言

1.1 微服務(wù)的目的

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

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

業(yè)務(wù)的功能劃分：每個(gè)單一的業(yè)務(wù)功能叫做一個(gè)服務(wù)，每個(gè)服務(wù)對(duì)應(yīng)一個(gè)獨(dú)立的職能團(tuán)隊(duì)。

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

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

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

容錯(cuò)模式：

 熔斷

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

限流

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

拆分粒度：

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

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

優(yōu)點(diǎn)

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

缺點(diǎn)

• 微服務(wù)架構(gòu)可能帶來過多的操作；
• 需要DevOps技巧；
• 可能雙倍的努力；
• 分布式系統(tǒng)可能復(fù)雜難以管理；
• 因?yàn)榉植疾渴鸶檰栴}難；
• 當(dāng)服務(wù)數(shù)量增加，管理復(fù)雜性增加。

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

二、Spring Cloud

2.1 整體架構(gòu)

模塊交互流程圖

2.2 核心組件

2.3 特點(diǎn)

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

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

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

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

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

三、Dubbo

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

3.1 整體架構(gòu)

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

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

• config配置層

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

• proxy服務(wù)代理層

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

• registry注冊(cè)中心層

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

• cluster路由層

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

• monitor監(jiān)控層

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

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

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

• exchange信息交換層

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

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

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

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

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

3.2 核心組件

Spring Cloud與Dubbo功能對(duì)比

3.3 特點(diǎn)

四、Spring Cloud Alibaba

4.1 整體架構(gòu)

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

4.2 核心組件與特點(diǎn)

Nacos基本架構(gòu)

Sentinel 的主要特性

Sentinel 的開源生態(tài)

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

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

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

五、Service mes

5.1 整體架構(gòu)

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

基本架構(gòu)圖

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

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

5.2 核心組件

Istio架構(gòu)圖

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

5.3 特點(diǎn)

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

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

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

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

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

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

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

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

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

（1）性能尚存問題，服務(wù)間調(diào)用因?yàn)閮蓪覵idecar，請(qǐng)求鏈路多兩跳；Istio Mixer集中式后端成為性能瓶頸；

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

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

六、Service Comb

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

6.1 整體架構(gòu)

6.2 核心組件

6.3 特點(diǎn)

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

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

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

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

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

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