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