導讀：微服務(wu)架構旨在將大型，復雜的系(xi)統(tong)垂直(按(an)功(gong)能(neng)或業務(wu)要求)劃分為較小的子(zi)系(xi)統(tong)，這些子(zi)系(xi)統(tong)屬于流程(cheng)(因此可獨立部署)，并且這些子(zi)系(xi)統(tong)之間通(tong)(tong)過(guo)與(yu)語言無(wu)關的輕量級網(wang)絡通(tong)(tong)信相互通(tong)(tong)信(例如(ru)REST，gRPC)或異步(bu)(通(tong)(tong)過(guo)消息傳(chuan)遞)方式。
1、引言
1.1 微服務的目的
以拆分(fen)和服務化為基礎，將海量用戶(hu)產生(sheng)的(de)(de)大規模的(de)(de)訪(fang)問流(liu)量進行分(fen)解，采(cai)用分(fen)而治之的(de)(de)方法，達(da)成用戶(hu)需要的(de)(de)功(gong)能(neng)指標，并同時滿足用戶(hu)對(dui)高(gao)可用、高(gao)性(xing)(xing)能(neng)、可伸縮、可擴展和安(an)全性(xing)(xing)的(de)(de)非(fei)功(gong)能(neng)質量的(de)(de)要求。
1.2 微服務的核心要點
業務(wu)的功能劃分：每(mei)個單一的業務(wu)功能叫做一個服務(wu)，每(mei)個服務(wu)對(dui)應一個獨立(li)的職(zhi)能團隊。
去中心(xin)化(hua)治理：微服務倡(chang)導去中心(xin)化(hua)的治理，不推薦每個微服務都使用相同的標準和技術(shu)來開(kai)發和使用服務。
交互模式：在(zai)微(wei)服務領域，微(wei)服務之間的(de)(de)交互通過定(ding)義良(liang)好的(de)(de)接口(kou)來實現，不允許使用共享數據來實現。通常使用RESTful樣式的(de)(de)API或者透明(ming)的(de)(de)RPC調用。
組合依(yi)賴(lai)：根據(ju)業務(wu)(wu)流程處理(li)的(de)(de)(de)需要，以一定的(de)(de)(de)順(shun)序調用依(yi)賴(lai)的(de)(de)(de)多(duo)個微服(fu)務(wu)(wu)，對(dui)依(yi)賴(lai)的(de)(de)(de)微服(fu)務(wu)(wu)返回的(de)(de)(de)數據(ju)進行(xing)組合、加工和轉換，最(zui)后(hou)以一定的(de)(de)(de)形式返回給(gei)使用方(fang)。
容錯模式：
? 熔斷
當服(fu)務(wu)的輸(shu)入(ru)負載(zai)迅速(su)增加時，如果沒有(you)(you)有(you)(you)效(xiao)的措施(shi)對負載(zai)進行熔斷，則會使服(fu)務(wu)迅速(su)被(bei)壓(ya)垮(kua)，服(fu)務(wu)被(bei)壓(ya)垮(kua)會導致(zhi)依賴的服(fu)務(wu)都被(bei)壓(ya)垮(kua)，出現雪崩效(xiao)應，因(yin)此，可通過(guo)模(mo)擬家庭的電路保險開關，在(zai)微服(fu)務(wu)架構(gou)中實現熔斷。
? 限流
針對服務(wu)突然上量(liang)(liang)，我們(men)必須有限流機(ji)(ji)制，限流機(ji)(ji)制一(yi)般會控制訪問(wen)的(de)并(bing)發量(liang)(liang)，例如每秒允許處理的(de)并(bing)發數及查詢量(liang)(liang)、請求量(liang)(liang)等，實(shi)現方式如計數器，令(ling)牌桶等。
拆分粒度：
按(an)照微服(fu)務(wu)(wu)的初衷(zhong)，服(fu)務(wu)(wu)要按(an)照業務(wu)(wu)的功(gong)能(neng)進行拆(chai)分，知道每個(ge)(ge)服(fu)務(wu)(wu)的功(gong)能(neng)和(he)職(zhi)責單一，甚至不可再拆(chai)分為止，以至于(yu)每個(ge)(ge)服(fu)務(wu)(wu)都能(neng)獨立部署，擴容和(he)縮榮方便，能(neng)夠有(you)效地提高利用率(lv)。拆(chai)的越(yue)細，服(fu)務(wu)(wu)的耦合度越(yue)小(xiao)，內聚(ju)性越(yue)好，越(yue)適合敏捷(jie)發布和(he)上線。
1.3 微服務的優點與缺點
優點
每個(ge)微服務都很小，這(zhe)樣能聚焦一個(ge)指定的業(ye)務功能或業(ye)務需求;
微服務能夠被(bei)小團隊單獨開(kai)發，這(zhe)個小團隊是2到5人(ren)(ren)的開(kai)發人(ren)(ren)員組成;
微服務(wu)是(shi)松耦合(he)的，是(shi)有功(gong)能意(yi)義的服務(wu)，無論是(shi)在開發階(jie)(jie)段或(huo)部署(shu)階(jie)(jie)段都是(shi)獨(du)立的;
微服(fu)務能使(shi)用(yong)不同的(de)語言開發;
微服務易于(yu)被一個開發人員理解，修改和維(wei)護，這樣小團(tuan)隊能夠更(geng)關注自(zi)己(ji)的工作成果，無需通過合作才能體(ti)現價值(zhi);
微(wei)服(fu)務(wu)允許你利用融合最(zui)新技術;
微服(fu)務(wu)只是業(ye)務(wu)邏輯的代碼，不會和HTML,CSS 或其他(ta)界面組件混合(he)。
缺點
微服務架(jia)構可能(neng)帶來過(guo)多的操(cao)作;
需(xu)要DevOps技巧;
可能雙倍的努力;
分布式系統可能(neng)復雜難以(yi)管理;
因為分布部署跟蹤問題難;
當服務數量增(zeng)加，管理復雜性增(zeng)加。
下文將(jiang)介紹下幾種微服務架構的情(qing)況。
2、Spring Cloud
2.1 整體架構
模塊交互流程圖
2.2 核心組件
2.3 特點
1?? Spring Cloud利用SpringBoot的(de)(de)開發(fa)便利性巧妙的(de)(de)簡(jian)化了分(fen)布(bu)式(shi)系統基(ji)礎(chu)設(she)施的(de)(de)開發(fa)，組件支持豐富，功(gong)能齊全，為開發(fa)人員(yuan)提供(gong)了快速構建分(fen)布(bu)式(shi)系統的(de)(de)一些工具，包括配置管理、服務發(fa)現、斷路(lu)器、路(lu)由、微(wei)代理、事件總(zong)線(xian)、全局鎖、決策競選、分(fen)布(bu)式(shi)會話等。它們都可以用SpringBoot的(de)(de)開發(fa)風格做到一鍵(jian)啟動和部署;
2?? 使用(yong) HTTP 協議的 REST API，服(fu)務提供方(fang)(fang)和(he)服(fu)務消費(fei)方(fang)(fang)通(tong)過 Json 數據格式交(jiao)互，只需要定義好相(xiang)關 Json 字(zi)段(duan)即可，消費(fei)方(fang)(fang)和(he)提供方(fang)(fang)無接口依賴。通(tong)過注(zhu)解(jie)方(fang)(fang)式來(lai)實現服(fu)務配(pei)置，對(dui)于程序有一定入侵(qin);
3?? 性能上(shang)因為是(shi)HTTP短(duan)連(lian)接(jie)，系(xi)統并發量和響應時間不及RPC長連(lian)接(jie)方式(如Dubbo，相差三倍(bei)左右)，在報文比較小，響應時間要(yao)求嚴格的(de)場景不太適合;
4??使用spring boot admin作為服務(wu)基本情況監控，原理是Spring Boot Actuator組件;
5?? 部分組(zu)件的功能及穩定性并未達到(dao)生產(chan)級別(bie)，使用(yong)者不多(duo)，需要(yao)引入其他功能相(xiang)似組(zu)件。
3、Dubbo
Dubbo是(shi)一個(ge)分布式、高(gao)性能、透明(ming)化的RPC服務框架，提供服務自動(dong)注冊、自動(dong)發(fa)現等高(gao)效及多樣性服務治理方案(an)，可以和Spring框架無縫集成。
3.1 整體架構
Provider：暴露(lu)服務(wu)的(de)服務(wu)提供方;
Consumer：調(diao)用遠程服務的服務消費(fei)方(fang)，使用軟(ruan)負(fu)載均衡(heng)算(suan)法;
Registry：服務注冊與發現的(de)注冊中心，如Zookeeper、Redis等;
Monitor：統計服(fu)務的(de)調(diao)用(yong)次(ci)(ci)數(shu)(shu)和調(diao)用(yong)時(shi)(shi)間(jian)的(de)監(jian)控(kong)中(zhong)心，服(fu)務消費者(zhe)和提供者(zhe)，在內存中(zhong)累計調(diao)用(yong)次(ci)(ci)數(shu)(shu)和調(diao)用(yong)時(shi)(shi)間(jian)，定時(shi)(shi)每(mei)分(fen)鐘發送一次(ci)(ci)統計數(shu)(shu)據到監(jian)控(kong)中(zhong)心;
Container：服務運行容器;
Dubbo分層結(jie)構設計圖
config配置層
對外配(pei)置(zhi)(zhi)接(jie)口，以ServiceConfig, ReferenceConfig為中心，可以直接(jie)初始化配(pei)置(zhi)(zhi)類，也可以通過spring解析配(pei)置(zhi)(zhi)生(sheng)成配(pei)置(zhi)(zhi)類;
proxy服務代理層
封裝了(le)(le)所有接口(kou)的透明化代理，而在(zai)其它層都以Invoker為中心(xin)，只(zhi)有到了(le)(le)暴露(lu)給用(yong)戶使用(yong)時，才用(yong)Proxy將Invoker轉成接口(kou)，或(huo)將接口(kou)實現(xian)轉成Invoker，也(ye)就是去掉Proxy層RPC是可以Run的，只(zhi)是不(bu)那(nei)么透明，不(bu)那(nei)么像調(diao)本地服務(wu)一樣調(diao)遠程服務(wu);
registry注冊中心層
封裝服(fu)務地址的注冊(ce)與(yu)發現，以(yi)服(fu)務URL為中心，擴(kuo)展接口為 RegistryFactory, Registry, RegistryService;
cluster路由層
封裝多個(ge)提(ti)供(gong)者(zhe)的路由(you)及負載均衡，并橋接(jie)注冊(ce)中心，以Invoker為(wei)中心，擴展接(jie)口為(wei) Cluster, Directory, Router, LoadBalance;
monitor監控層
RPC調(diao)用(yong)次(ci)數和調(diao)用(yong)時間監控(kong)，以Statistics為中心，擴(kuo)展接(jie)口為 MonitorFactory, Monitor, MonitorService;
protocol遠程調用層
封裝RPC調用(yong)，以Invocation, Result 為中(zhong)心，擴展接口為Protocol, Invoker, Exporter，Protocol是核(he)心層，也就是只要有Protocol + Invoker + Exporter就可以完成(cheng)非透(tou)明的RPC調用(yong)，然后在Invoker的流程中(zhong)實(shi)現Filter攔截點;
exchange信息交換層
封(feng)裝(zhuang)請求響應模式，同(tong)步轉異步，以Request, Response為(wei)中心，擴(kuo)展接口為(wei)Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer;
transport網絡傳輸層
抽象mina和netty為(wei)統一接(jie)(jie)口，以Message為(wei)中心，擴展接(jie)(jie)口為(wei)Channel, Transporter, Client, Server, Codec;
serialize數(shu)據序列(lie)化層
可復用的一些工具，擴展接口為(wei)Serialization, ObjectInput, ObjectOutput, ThreadPool。
3.2 核心組件
Spring Cloud與(yu)Dubbo功能對比
3.3 特點
4、Spring Cloud Alibaba
4.1 整體架構
類似Spring cloud的(de)(de)架構，適(shi)配集成(cheng)Alibaba的(de)(de)多種(zhong)中間(jian)(jian)件(jian)(jian)，注冊(ce)中心(xin)換成(cheng)了Nacos，限流熔斷從Hystrix換成(cheng)了Sentinel，服務(wu)間(jian)(jian)調用可(ke)以使(shi)用Dubbo，使(shi)用RocketMQ作為消息總線及事(shi)件(jian)(jian)驅動組件(jian)(jian)，用Seata組件(jian)(jian)(前身是fescar)支持分布式事(shi)務(wu)功能，目前最新(xin)版(ban)本是2.1.0.RELEASE。
4.2 核心組件與特點
Nacos基本架構
Sentinel 的主(zhu)要特(te)性
Sentinel 的開源生態
與(yu)spring cloud相關組件對比
幾種服務治理(li)組(zu)件對比
5、Service mesh
5.1 整體架構
如下(xia)是(shi)(shi)簡(jian)化的Service Mesh架(jia)構，服務A和服務B相(xiang)互調(diao)用，不再是(shi)(shi)以前通過微服務框架(jia)直接指向的方式，而是(shi)(shi)在中(zhong)間加(jia)了兩個叫做Sidecar(邊車)的東西，各種服務都在這里處理數據上的邏輯。Sidecar的作用是(shi)(shi)數據面(mian)的代理，貼近數據并(bing)受控于控制面(mian)。
基本架構圖
實際業務(wu)中，尤其是中臺架構下，企(qi)業往往需要很多的(de)微(wei)服務(wu)，即服務(wu)A、服務(wu)B相互調用情形不斷擴(kuo)展，逐(zhu)漸形成更(geng)多的(de)服務(wu)加Sidecar的(de)組合，就變成了一個真正意義的(de)Service Mesh。
服務(wu)的(de)網格化(mesh)
5.2 核心組件
Istio架構圖
主流云原生Service Mesh框架是Istio，Go語言實現，與容器編排系統(tong)Kubernetes一脈相(xiang)承，下面介紹其主要組件，目前Istio版(ban)本為1.3.x release：
5.3 特點
1、Service Mesh所(suo)帶來的(de)核心價值可以總結為(wei)：
基礎設施下沉 —— 微(wei)服務架構支撐、網絡通信、治理等相關能力下沉到(dao)基礎設施層(ceng)，業務部門無需投入專人開(kai)發與維護(hu)，可以有效(xiao)降(jiang)低微(wei)服務架構下研發與維護(hu)成本;
降低升級成本(ben) —— Sidecar支持(chi)熱升級，降低中間件和技(ji)術(shu)框架(jia)客戶(hu)端、SDK升級成本(ben);
語言無關 —— 提供多語言服(fu)務治理能力;
降低(di)復(fu)雜測試、演練成本 —— 降低(di)全鏈(lian)路壓測、故障演練成本和業務侵(qin)入性。
2、數(shu)據(ju)面(mian)以Envoy Proxy作為代理(li)組件。通過Outbound流(liu)(liu)量(liang)(liang)(liang)攔(lan)截(jie)或顯示指向Envoy Proxy地(di)址的方(fang)式(shi)代理(li)發起請求流(liu)(liu)量(liang)(liang)(liang)，經過Envoy Proxy的服務發現、負載均衡、路由等數(shu)據(ju)面(mian)邏輯后(hou)，選(xuan)擇目(mu)標服務實例地(di)址進行(xing)流(liu)(liu)量(liang)(liang)(liang)轉(zhuan)發;在Inbound流(liu)(liu)量(liang)(liang)(liang)接收端進行(xing)流(liu)(liu)量(liang)(liang)(liang)攔(lan)截(jie)(可配置(zhi)是否攔(lan)截(jie))，對Inbound流(liu)(liu)量(liang)(liang)(liang)進行(xing)處理(li)后(hou)轉(zhuan)發至目(mu)標服務實例。
3、控(kong)制面(mian)以Pilot為核心組件(jian)(jian)。通(tong)過建立與(yu)(yu)Envoy Proxy雙向GRPC連(lian)接，實現服(fu)(fu)務(wu)注(zhu)冊信息、服(fu)(fu)務(wu)治理策(ce)略(lve)的實時下(xia)發與(yu)(yu)同步(bu)。其他(ta)控(kong)制面(mian)組件(jian)(jian)Mixer(策(ce)略(lve)檢查(cha)、監控(kong)、日(ri)志審計等)、Citadel(認(ren)證與(yu)(yu)授權)、Galley(配(pei)置(zhi)檢查(cha))可在實際場景中配(pei)置(zhi)關閉(bi)。
4、平(ping)臺開放(fang)與擴展主(zhu)要通過(guo)Kubernetes CRD與Mesh Configuration Protocol(簡稱為MCP，一套(tao)標準GRPC協(xie)議(yi))。平(ping)臺默認支持(chi)Kubernetes基于ETCD的注冊中心機制(zhi)，可(ke)通過(guo)MCP機制(zhi)對(dui)接更多(duo)諸如(ru)Consul、Eureka、ZooKeeper等多(duo)注冊中心;對(dui)服(fu)務治(zhi)理策略(lve)的配(pei)置(zhi)可(ke)通過(guo)定義Kubernetes CRD或(huo)實現MCP GRPC服(fu)務對(dui)接實現。
5、高(gao)可(ke)(ke)用(yong)設計主要基于(yu)(yu)Kubernetes及(ji)Istio機(ji)制實現(xian)。數據面Envoy Proxy以(yi)Init-Container方(fang)(fang)式與業務(wu)Container同時(shi)啟動(dong)，Istio提供了Pilot-agent組(zu)件(jian)實現(xian)對Envoy Proxy生命周期、升級的支持(chi)，保證(zheng)Envoy Proxy的高(gao)可(ke)(ke)用(yong)。控(kong)制面所有Istio組(zu)件(jian)均由Kubernetes多副本探針機(ji)制保證(zheng)高(gao)可(ke)(ke)用(yong)性。Istio目(mu)前(qian)支持(chi)服(fu)務(wu)部署于(yu)(yu)Kubernetes、使用(yong)Consul注冊服(fu)務(wu)、服(fu)務(wu)運行于(yu)(yu)單個虛(xu)擬機(ji)上集成，自定(ding)義 Istio的策(ce)略執行組(zu)件(jian)可(ke)(ke)以(yi)擴展(zhan)和定(ding)制，以(yi)及(ji)與acl、日志記錄(lu)、監視、配額(e)、審核等現(xian)有解決方(fang)(fang)案集成。
6、Alibaba的對(dui)Istio架構(gou)的改造落地實(shi)踐(jian)：//zhuanlan.zhihu.com/p/96720618。
實(shi)踐方案(an)中(zhong)放棄Istio 通(tong)過(guo) iptables 的(de)(de)(de)(de) NAT 表(biao)去(qu)做(zuo)流(liu)量透(tou)明攔截的(de)(de)(de)(de)方式(NAT 表(biao)所使(shi)用(yong)到的(de)(de)(de)(de) nf_contrack 內(nei)(nei)核(he)模塊效率(lv)很低)，自(zi)研全新的(de)(de)(de)(de)透(tou)明攔截組(zu)(zu)件(jian)mangle;也(ye)沒有采用(yong) Istio 中(zhong)的(de)(de)(de)(de) Mixer 組(zu)(zu)件(jian)，用(yong)內(nei)(nei)部(bu)廣泛使(shi)用(yong)的(de)(de)(de)(de) Sentinel 組(zu)(zu)件(jian)替代，每個(ge)請求都會經過(guo) Sentinel Filter 做(zuo)處理。限流(liu)所需的(de)(de)(de)(de)配置(zhi)信息則是(shi)通(tong)過(guo) Pilot 從(cong) Nacos 中(zhong)獲取，并通(tong)過(guo) xDS 協(xie)議(yi)下發到 Envoy 中(zhong)，實(shi)踐中(zhong)Service Mesh 的(de)(de)(de)(de)引入對于 RT 的(de)(de)(de)(de)影響和帶來的(de)(de)(de)(de) CPU 開銷(xiao)是(shi)基本(ben)一樣(yang)的(de)(de)(de)(de)，而內(nei)(nei)存(cun)開銷(xiao)則因為依賴服務和集群規模的(de)(de)(de)(de)不同而有相(xiang)當大的(de)(de)(de)(de)差異，Envoy 在內(nei)(nei)存(cun)的(de)(de)(de)(de)使(shi)用(yong)上仍存(cun)在很大的(de)(de)(de)(de)優化空間。
7、Service Mesh 離普及(ji)還面臨一定挑(tiao)戰：
(1)性能(neng)尚存(cun)問題，服務(wu)間調用因為兩層Sidecar，請求(qiu)鏈(lian)路多兩跳;Istio Mixer集(ji)中式后(hou)端成(cheng)為性能(neng)瓶頸;
(2)Istio架構復雜，一定的技(ji)術門檻，掌握和(he)實施(shi)成本較高(gao)，穩(wen)定性及產(chan)品化應用有待驗證;
(3)真實落地的(de)產品和企業還是比較(jiao)少(shao)，提(ti)供的(de)經驗(yan)比較(jiao)欠缺。
6、Service Comb
2018年10月24日(ri)， Apache軟件基金會宣布Apache ServiceComb 畢業成為(wei)Apache頂級項目。Apache ServiceComb已在數(shu)十家企業中(zhong)(zhong)使用(yong)，包括奇蛙智能科技、華為(wei)云(yun)、軟通動(dong)力，傳智播客、梅斯醫學、文思海(hai)輝(hui)、中(zhong)(zhong)國人保(bao)和同(tong)濟大學等(deng)。
6.1 整體架構
6.2 核心組件
6.3 特點
1、異步內核：基于VertX的同步和異步模型編程有效確保了無論是在傳統企業或電商領域，還是在新興的互聯網或物聯網等(deng)新興企業(ye)中，都能夠(gou)保持高性能和低延遲，以避(bi)免在達到峰值負載時應(ying)用出現雪崩效應(ying);
2、ServiceComb支(zhi)持多種通信(xin)協(xie)議(yi)(yi), Rest、Highway(RPC)等，相比SpringCloud的(de)(de)Rest協(xie)議(yi)(yi)，Highway(RPC)協(xie)議(yi)(yi)性能更(geng)高(gao)，Highway是(shi)基于二(er)進制的(de)(de)序(xu)列化方式傳輸(shu)數據，采用(yong)二(er)進制編碼的(de)(de)系統的(de)(de)性能遠高(gao)于采用(yong)文(wen)本的(de)(de)HTTP協(xie)議(yi)(yi);
3、開箱即用體驗，開發簡單，開發人(ren)員通(tong)過腳(jiao)手(shou)架網站start.servicecomb.io啟動(dong)的微服務(wu)項目，可以集(ji)服務(wu)注冊、發現、通(tong)信和微服務(wu)治理能力(li)和默認(ren)的集(ji)中化配置為(wei)一體;
4、ServiceComb的商(shang)業版本CSE相(xiang)比SpringCloud不僅(jin)提供(gong)了微服(fu)務開(kai)發框架，還提供(gong)了微服(fu)務云部署，管理、治理等一站(zhan)式解決方案;
5、OpenAPI自動代(dai)碼(ma)生成(cheng)，業(ye)務邏(luo)輯(ji)代(dai)碼(ma)和(he)治(zhi)理能力(li)隔離，可以使能DevOps Pipeline， 使用契約文件和(he)OpenAPI的雙向(xiang)生成(cheng)能力(li)可以使不同的團隊高效且(qie)獨立的開(kai)發和(he)管(guan)理代(dai)碼(ma)、測試和(he)進行文檔(dang)化工(gong)作(zuo);
