微服務架構旨在将大型，複雜的系統垂直（按功能或業務要求）劃分為較小的子系統，這些子系統屬于流程（是以可獨立部署），并且這些子系統之間通過與語言無關的輕量級網絡通信互相通信（例如REST，gRPC）或異步（通過消息傳遞）方式。
作者：程小龍
機關：中移物聯網有限公司
1、引言
1.1 微服務的目的
以拆分和服務化為基礎，将海量使用者産生的大規模的通路流量進行分解，采用分而治之的方法，達成使用者需要的功能名額，并同時滿足使用者對高可用、高性能、可伸縮、可擴充和安全性的非功能品質的要求。
1.2 微服務的核心要點
- 業務的功能劃分：每個單一的業務功能叫做一個服務，每個服務對應一個獨立的職能團隊。
- 去中心化治理：微服務倡導去中心化的治理，不推薦每個微服務都使用相同的标準和技術來開發和使用服務。
- 互動模式：在微服務領域，微服務之間的互動通過定義良好的接口來實作，不允許使用共享資料來實作。通常使用RESTful樣式的API或者透明的RPC調用。
- 組合依賴：根據業務流程處理的需要，以一定的順序調用依賴的多個微服務，對依賴的微服務傳回的資料進行組合、加工和轉換，最後以一定的形式傳回給使用方。
- 容錯模式：
➤ 熔斷
當服務的輸入負載迅速增加時，如果沒有有效的措施對負載進行熔斷，則會使服務迅速被壓垮，服務被壓垮會導緻依賴的服務都被壓垮，出現雪崩效應，是以，可通過模拟家庭的電路保險開關，在微服務架構中實作熔斷。
➤ 限流
針對服務突然上量，我們必須有限流機制，限流機制一般會控制通路的并發量，例如每秒允許處理的并發數及查詢量、請求量等，實作方式如計數器，令牌桶等。
- 拆分粒度：
按照微服務的初衷，服務要按照業務的功能進行拆分，知道每個服務的功能和職責單一，甚至不可再拆分為止，以至于每個服務都能獨立部署，擴容和縮容友善，能夠有效地提高使用率。拆的越細，服務的耦合度越小，内聚性越好，越适合靈活釋出和上線。
1.3 微服務的優點與缺點
- 優點
- 每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求；
- 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成；
- 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的；
- 微服務能使用不同的語言開發；
- 微服務易于被一個開發人員了解，修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能展現價值；
- 微服務允許你利用融合最新技術；
- 微服務隻是業務邏輯的代碼，不會和HTML,CSS 或其他界面元件混合。
- 缺點
- 微服務架構可能帶來過多的操作；
- 需要DevOps技巧；
- 可能雙倍的努力；
- 分布式系統可能複雜難以管理；
- 因為分布部署跟蹤問題難；
- 當服務數量增加，管理複雜性增加。
下文将介紹下幾種微服務架構的情況。
2、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️⃣ 部分元件的功能及穩定性并未達到生産級别，使用者不多，需要引入其他功能相似元件。
3、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 特點
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 的開源生态
與spring cloud相關元件對比
幾種服務治理元件對比
使用demo：https://www.jianshu.com/p/9a8d94c0c90c。
5、Service mesh
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）真實落地的産品和企業還是比較少，提供的經驗比較欠缺。
6、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。