微服務架構的概述
應用架構的發展
應用是可以獨立運行的程序代碼,提供相對完善的業務功能. 目前的軟件架構有三種架構類型:
- 業務架構
- 應用架構
- 技術架構
他們之間的甚是: 業務架構決定應用架構,技術架構支撐着應用架構. 應用架構的發展歷程:
- 單體架構: 最古老的單體應用,沒有任何應用拆分,整體就是一個war包
- 分布式應用 | SOA架構: 根據業務進行划分服務,不同的業務建立不同的服務,不同的服務之間通過服務接口進行數據交互(網絡通信).
- 微服務架構: 將業務功能拆分為多個相互獨立的微服務,各個微服務之間松耦合,通過各種遠程協議進行同步 / 異步通信,各服務之間可以獨立部署,擴 / 縮容以及升 / 降級.
每種技術架構都有其優缺點,存在即合理,不同的業務場景使用不同的應用架構,不一定說最新的架構就是最適合你的.
重點說一下微服務架構,在重新定義SpringCloud實戰中介紹了5種微服務架構技術選型,這里說兩種,我用過的,常聽到的.(先提及一個概念 CAP理論: 一致性,高可用,分區容錯性)
| 參數 | SpringCloud | Dubbo |
|---|---|---|
| 功能 | 微服務完整解決方案 | 服務治理(定位以及發現問題)框架 |
| 通信 | REST / HTTP | RPC(遠程方法調用)協議 |
| 服務注冊/ 發現 | Ecureka(AP) | ZK(CP),Nacos |
| 負載均衡 | Ribbon | 客戶端負載 |
| 容錯機制 | 六種容錯策略 | 六種容錯策略 |
| 熔斷機制 | Hystrix | 無 |
| 配置中心 | Spring Cloud Config | Nacos |
| 網關 | zuul,Gateway | 無 |
| 服務監控 | Hystrix + Turbine | Dubbo + Monitor |
| 鏈路監控 | Sleuth + Zipkin | 無 |
| 多語言 | REST支持多語言 | 只支持Java |
| 社區活躍 | 高(背靠Spring) | 高(背靠阿里) |
微服務的解決方案
- 基於SpringCloud的微服務解決方案
SpringCloud的技術選型是中立的,可隨意搭配更換.
| 組件 | 方案1 | 方案2 | 方案3 |
| 服務發現 | Eureka | Consul | etcd,阿里的Nacos |
| 共用組件 | 服務間調用組件Feign,負載均衡組件Ribbon,熔斷器Hystrix | ||
| 網關 | 性能低: zuul; 性能高: Spring Cloud Gateway | 自研網關中間件 | |
| 配置中心 | Spring Cloud Config, 攜程阿波羅, 阿里Nacos | ||
| 全鏈路監控 | zipkin(不推薦),Pinpoint(不推薦),Skywalking(推薦) | ||
| 搭配使用 | 分布式事務,容器化,Spring Cloud與DDD,gRPC | ||
- 基於Dubbo實現微服務解決方案
Dubbo不是一個微服務的全面解決方案,而是專注於RPC領域成為微服務生態體系的一個重要的組件,所以說基於Dubbo的微服務組件是: Dubbo + Nacos + 其他. (Nacos的定位是一個更易於幫助構建雲原生應用的動態服務發現,配置和服務管理平台)
Spring Cloud和Dubbo
Spring Cloud和Dubbo的比較其實是針對REST和RPC之間的對比,其余方面沒有對比性,因為領域不同,對於Spring Cloud提供的一套完整的微服務解決方案,提供分布式情況下的各種解決方案;而Dubbo則是專注於RPC.
Spring Cloud的設計理念是Integrate Everything,即充分利用現有的開源組件,在他們之上設計一套統一規范/接口使他們能夠接入Spring Cloud體系並能夠無縫切換底層實現.
2018年6月,Spring Cloud中國社區開源名為spring-cloud-dubbo項目,目標是將dubbo融入Spring Cloud體系中,使微服務之間的調用同時具備RESTful和Dubbo調用的能力,做到對業務代碼無侵入,無感知,在使用過程中引入jar包則在微服務間調用時使用Dubbo,去掉jar則使用默認的RESTful.