微服務架構是互聯網很熱門的話題，是互聯網技術發展的必然結果。它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。雖然微服務架構沒有公認的技術標準和規范或者草案，但業界已經有一些很有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如Dubbo和Spring Cloud。各大互聯網公司也有自研的微服務框架，但其模式都于這二者相差不大。
微服務主要的優勢如下：
1、降低復雜度
將原來偶合在一起的復雜業務拆分為單個服務，規避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。每個服務開發者只專注服務本身，通過使用緩存、DAL等各種技術手段來提升系統的性能，而對于消費方來說完全透明。
2、可獨立部署
由于微服務具備獨立的運行進程，所以每個微服務可以獨立部署。當業務迭代時只需要發布相關服務的迭代即可，降低了測試的工作量同時也降低了服務發布的風險。
3、容錯
在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。 通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常運行。
4、擴展
單塊架構應用也可以實現橫向擴展，就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。
本文主要圍繞微服務的技術選型、通訊協議、服務依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發框架。架構師可以根據公司的技術實力并結合項目的特點來選擇某個合適的微服務架構平臺，以此穩妥地實施項目的微服務化改造或開發進程。
獲取更多視頻資料加群：554355695
如果你想學習Java工程化、高性能及分布式、高性能、深入淺出。性能調優、Spring，MyBatis，Netty源碼分析和大數據等知識點可以來找我。
而現在我就有一個平臺可以提供給你們學習，讓你在實踐中積累經驗掌握原理。主要方向是JAVA架構師。如果你想拿高薪，想突破瓶頸，想跟別人競爭能取得優勢的，想進BAT但是有擔心面試不過的，可以加我的Java架構進階群：554355695
一、核心部件
微服務的核心要素在于服務的發現、注冊、路由、熔斷、降級、分布式配置，基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。
1、總體架構
Dubbo 核心部件（如下圖）:
Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務
Consumer：調用遠程服務的服務消費方。
Registry： 服務注冊中心和發現中心。
Monitor： 統計服務和調用次數，調用時間監控中心。（dubbo的控制臺頁面中可以顯示，目前只有一個簡單版本）
Container：服務運行的容器。
Dubbo 總體架構
Spring Cloud總體架構如下圖
Service Provider： 暴露服務的提供方。
Service Consumer：調用遠程服務的服務消費方。
EureKa Server： 服務注冊中心和服務發現中心。
Spring Cloud總體架構
點評：從整體架構上來看，二者模式接近，都需要需要服務提供方，注冊中心，服務消費方。
2、微服務架構核心要素
核心要素DubboSpring Cloud
服務注冊中心Zookeeper、RedisSpring Cloud Netflix Eureka
服務調用方式RPCREST API
服務網關無Spring Cloud Netflix Zuul
斷路器不完善Spring Cloud Netflix Hystrix
分布式配置無Spring Cloud Config
分布式追蹤系統無Spring Cloud Sleuth
消息總線無Spring Cloud Bus
數據流無Spring Cloud Stream 基于Redis,Rabbit,Kafka實現的消息微服務
批量任務無Spring Cloud Task
Dubbo只是實現了服務治理，而Spring Cloud子項目分別覆蓋了微服務架構下的眾多部件，而服務治理只是其中的一個方面。Dubbo提供了各種Filter，對于上述中“無”的要素，可以通過擴展Filter來完善。
例如
1．分布式配置：可以使用淘寶的diamond、百度的disconf來實現分布式配置管理
2．服務跟蹤：可以使用京東開源的Hydra，或者擴展Filter用Zippin來做服務跟蹤
3．批量任務：可以使用當當開源的Elastic-Job、tbschedule
點評：從核心要素來看，Spring Cloud 更勝一籌，在開發過程中只要整合Spring Cloud的子項目就可以順利的完成各種組件的融合，而Dubbo缺需要通過實現各種Filter來做定制，開發成本以及技術難度略高。
二、通訊協議
基于通訊協議層面對2種框架支持的協議類型以及運行效率方面進行比較；
（一）、支持協議
1、Dubbo：dubbo使用RPC通訊協議，提供序列化方式如下：
dubbo：Dubbo缺省協議采用單一長連接和NIO異步通訊，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況
rmi：RMI協議采用JDK標準的java.rmi.*實現，采用阻塞式短連接和JDK標準序列化方式
Hessian:Hessian協議用于集成Hessian的服務，Hessian底層采用Http通訊，采用Servlet暴露服務，Dubbo缺省內嵌Jetty作為服務器實現
http:采用Spring的HttpInvoker實現
Webservice:基于CXF的frontend-simple和transports-http實現
2、Spring Cloud：Spring Cloud 使用HTTP協議的REST API
（二）、性能比較
使用一個Pojo對象包含10個屬性，請求10萬次，Dubbo和Spring Cloud在不同的線程數量下，每次請求耗時（ms）如下：
線程數DubboSpring Cloud
10線程2.756.52
20線程4.1810.03
50線程10.328.14
100線程20.1355.23
200線程42110.21
說明：客戶端和服務端配置均采用阿里云的ECS服務器，4核8G配置，dubbo采用默認的dubbo協議
點評：dubbo支持各種通信協議，而且消費方和服務方使用長鏈接方式交互，通信速度上略勝Spring Cloud，如果對于系統的響應時間有嚴格要求，長鏈接更合適。
三、服務依賴方式
Dubbo：服務提供方與消費方通過接口的方式依賴，服務調用設計如下：
interface層：服務接口層，定義了服務對外提供的所有接口
Molel層：服務的DTO對象層，
business層：業務實現層，實現interface接口并且和DB交互
因此需要為每個微服務定義了各自的interface接口，并通過持續集成發布到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，開發、測試、集成環境都需要嚴格的管理版本依賴。
通過maven的install & deploy命令把interface和Model層發布到倉庫中，服務調用方只需要依賴interface和model層即可。在開發調試階段只發布Snapshot版本。等到服務調試完成再發布Release版本，通過版本號來區分每次迭代的版本。通過xml配置方式即可方面接入dubbo，對程序無入侵。
Dubbo接口依賴方式
Spring Cloud：服務提供方和服務消費方通過json方式交互，因此只需要定義好相關json字段即可，消費方和提供方無接口依賴。通過注解方式來實現服務配置，對于程序有一定入侵。
點評：Dubbo服務依賴略重，需要有完善的版本管理機制，但是程序入侵少。而Spring Cloud通過Json交互，省略了版本管理的問題，但是具體字段含義需要統一管理，自身Rest API方式交互，為跨平臺調用奠定了基礎。
四、組件運行流程
下圖中的每個組件都是需要部署在單獨的服務器上，gateway用來接受前端請求、聚合服務，并批量調用后臺原子服務。每個service層和單獨的DB交互。
Dubbo組件運行流程
gateWay:前置網關，具體業務操作，gateWay通過dubbo提供的負載均衡機制自動完成
Service：原子服務，只提供該業務相關的原子服務
Zookeeper：原子服務注冊到zk上
Spring Cloud 組件運行
Spring Cloud
所有請求都統一通過 API 網關（Zuul）來訪問內部服務。
網關接收到請求后，從注冊中心（Eureka）獲取可用服務。
由 Ribbon 進行均衡負載后，分發到后端的具體實例。
微服務之間通過 Feign 進行通信處理業務。
點評：業務部署方式相同，都需要前置一個網關來隔絕外部直接調用原子服務的風險。Dubbo需要自己開發一套API 網關，而Spring Cloud則可以通過Zuul配置即可完成網關定制。使用方式上Spring Cloud略勝一籌。
五、微服務架構組成以及注意事項
到底使用是dubbo還是Spring Cloud其實并不重要，重點在于如何合理的利用微服務。下面是一張互聯網通用的架構圖,其中每個環節都是微服務的核心部分。
（一）、架構分解
網關集群：數據的聚合、實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑒權、響應數據的脫敏、流量與并發控制等
業務集群：一般情況下移動端訪問和瀏覽器訪問的網關需要隔離，防止業務耦合
Local Cache：由于客戶端訪問業務可能需要調用多個服務聚合，所以本地緩存有效的降低了服務調用的頻次，同時也提示了訪問速度。本地緩存一般使用自動過期方式，業務場景中允許有一定的數據延時。
服務層：原子服務層，實現基礎的增刪改查功能，如果需要依賴其他服務需要在Service層主動調用
Remote Cache：訪問DB前置一層分布式緩存，減少DB交互次數，提升系統的TPS
DAL：數據訪問層，如果單表數據量過大則需要通過DAL層做數據的分庫分表處理。
MQ：消息隊列用來解耦服務之間的依賴，異步調用可以通過MQ的方式來執行
數據庫主從：服務化過程中畢竟的階段，用來提升系統的TPS
（二）注意事項
服務啟動方式建議使用jar方式啟動，啟動速度快，更容易監控
緩存、緩存、緩存，系統中能使用緩存的地方盡量使用緩存，通過合理的使用緩存可以有效的提高系統的TPS
服務拆分要合理，盡量避免因服務拆分而導致的服務循環依賴
合理的設置線程池，避免設置過大或者過小導致系統異常
六、總結
Dubbo出生于阿里系，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯網公司；只需要通過spring配置的方式即可完成服務化，對于應用無入侵。設計的目的還是服務于自身的業務為主。雖然阿里內部原因dubbo曾經一度暫停維護版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯網公司的業務需求。如果我們需要使用配置中心、分布式跟蹤這些內容都需要自己去集成，這樣無形中增加了使用 Dubbo 的難度。
Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專注于企業級開源框架的研發。 Spring Cloud 自從發展到現在，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來非常的便利和簡單。
Dubbo于2017年開始又重啟維護，發布了更新后的2.5.6版本，而Spring Cloud更新的非常快，目前已經更新到Finchley.M2。因此，企業需要根據自身的研發水平和所處階段選擇合適的架構來解決業務問題，不管是Dubbo還是Spring Cloud都是實現微服務有效的工具。
