微服務架構是網際網路很熱門的話題，是網際網路技術發展的必然結果。它提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。雖然微服務架構沒有公認的技術标準和規範或者草案，但業界已經有一些很有影響力的開源微服務架構架構提供了微服務的關鍵思路，例如Dubbo和Spring Cloud。各大網際網路公司也有自研的微服務架構，但其模式都于這二者相差不大。
微服務主要的優勢如下：
1、降低複雜度
将原來偶合在一起的複雜業務拆分為單個服務，規避了原本複雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。每個服務開發者隻專注服務本身，通過使用緩存、DAL等各種技術手段來提升系統的性能，而對于消費方來說完全透明。
2、可獨立部署
由于微服務具備獨立的運作程序，是以每個微服務可以獨立部署。當業務疊代時隻需要釋出相關服務的疊代即可，降低了測試的工作量同時也降低了服務釋出的風險。
3、容錯
在微服務架構下，當某一元件發生故障時，故障會被隔離在單個服務中。 通過限流、熔斷等方式降低錯誤導緻的危害，保障核心業務正常運作。
4、擴充
單塊架構應用也可以實作橫向擴充，就是将整個應用完整的複制到不同的節點。當應用的不同元件在擴充需求上存在差異時，微服務架構便展現出其靈活性，因為每個服務可以根據實際需求獨立進行擴充。
本文主要圍繞微服務的技術選型、通訊協定、服務依賴模式、開始模式、運作模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發架構。架構師可以根據公司的技術實力并結合項目的特點來選擇某個合适的微服務架構平台，以此穩妥地實施項目的微服務化改造或開發程序。
一、核心部件
微服務的核心要素在于服務的發現、注冊、路由、熔斷、降級、分布式配置，基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。
1、總體架構
Dubbo 核心部件（如下圖）:
Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務
Consumer：調用遠端服務的服務消費方。
Registry： 服務注冊中心和發現中心。
Monitor： 統計服務和調用次數，調用時間監控中心。（dubbo的控制台頁面中可以顯示，目前隻有一個簡單版本）
Container：服務運作的容器。
▲Dubbo 總體架構
Spring Cloud總體架構如下圖
Service Provider： 暴露服務的提供方。
Service Consumer：調用遠端服務的服務消費方。
EureKa Server： 服務注冊中心和服務發現中心。
▲Spring Cloud總體架構
點評：從整體架構上來看，二者模式接近，都需要需要服務提供方，注冊中心，服務消費方。
2、微服務架構核心要素
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）如下：
說明：用戶端和服務端配置均采用阿裡雲的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其實并不重要，重點在于如何合理的利用微服務。下面是一張網際網路通用的架構圖,其中每個環節都是微服務的核心部分。
c
（一）、架構分解
網關叢集：資料的聚合、實作對接入用戶端的身份認證、防封包重放與防資料篡改、功能調用的業務鑒權、響應資料的脫敏、流量與并發控制等
業務叢集：一般情況下移動端通路和浏覽器通路的網關需要隔離，防止業務耦合
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都是實作微服務有效的工具。
歡迎工作一到五年的Java工程師朋友們加入Java程式員開發： 854393687
群内提供免費的Java架構學習資料（裡面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！