Round 1：背景
Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於阿里巴巴集團的各成員站點。阿里巴巴近幾年對開源社區的貢獻不論在國內還是國外都是引人注目的，比如：JStorm捐贈給Apache並加入Apache基金會等，為中國互聯網人爭足了面子，使得阿里巴巴在國人眼里已經從電商升級為一家科技公司了。
Spring Cloud，從命名我們就可以知道，它是Spring Source的產物，Spring社區的強大背書可以說是Java企業界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強大的后盾與技術輸出。其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。
小結：如果拿Dubbo與Netflix套件做對比，前者在國內影響力較大，后者在國外影響力較大，我認為在背景上可以打個平手；但是若要與Spring Cloud做對比，由於Spring Source的加入，在背書上，Spring Cloud略勝一籌。不過，英雄不問出處，在背景這一點上，不能作為選擇框架的主要因素，當您一籌莫展的時候，可以作為參考依據。
Round 2：社區活躍度
我們選擇一個開源框架，社區的活躍度是我們極為關注的一個要點。社區越活躍，解決問題的速度越快，框架也會越來越完善，不然當我們碰到問題，就不得不自己解決。而對於團隊來說，也就意味着我們不得不自己去維護框架的源碼，這對於團隊來說也將會是一個很大的負擔。
下面看看這兩個項目在github上的更新時間，下面截圖自2016年7月30日：
- Dubbo ： https://github.com/dubbo
最后更新時間為：2016年5月6日
- Spring Cloud ： https://github.com/spring-cloud
最后更新時間為：12分鍾前
可以看到Dubbo的更新已經是幾個月前，並且更新頻率很低。而Spring Cloud的更新是12分鍾前，仍處於高速迭代的階段。
小結：在社區活躍度上，Spring Cloud毋庸置疑的優於Dubbo，這對於沒有大量精力與財力維護這部分開源內容的團隊來說，Spring Cloud會是更優的選擇。
Round 3：架構完整度
或許很多人會說Spring Cloud和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而Spring Cloud下面有17個子項目（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。但是在選擇框架上，方案完整度恰恰是一個需要重點關注的內容。
根據Martin Fowler對 微服務架構 的描述中，雖然該架構相較於單體架構有模塊化解耦、可獨立部署、技術多樣性等諸多優點，但是由於分布式環境下解耦，也帶出了不少測試與運維復雜度。
根據微服務架構在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。
| Dubbo | Spring Cloud | |
|---|---|---|
| 服務注冊中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服務調用方式 | RPC | REST API |
| 服務網關 | 無 | Spring Cloud Netflix Zuul |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
| …… | …… | …… |
以上列舉了一些核心部件，大致可以理解為什么之前說Dubbo只是類似Netflix的一個子集了吧。當然這里需要申明一點，Dubbo對於上表中總結為“無”的組件不代表不能實現，而只是Dubbo框架自身不提供，需要另外整合以實現對應的功能，比如：
- 分布式配置：可以使用淘寶的diamond、百度的disconf來實現分布式配置管理。但是Spring Cloud中的Config組件除了提供配置管理之外，由於其存儲可以使用git，因此它天然的實現了配置內容的版本管理，可以完美的與應用版本管理整合起來。
- 服務跟蹤：可以使用京東開源的Hydra
- 批量任務：可以使用當當開源的Elastic-Job
- ……
雖然，Dubbo自身只是實現了服務治理的基礎，其他為保證集群安全、可維護、可測試等特性方面都沒有很好的實現，但是幾乎大部分關鍵組件都能找到第三方開源來實現，這些組件主要來自於國內各家大型互聯網企業的開源產品。
RPC vs REST
另外，由於Dubbo是基礎框架，其實現的內容對於我們實施微服務架構是否合理，也需要我們根據自身需求去考慮是否要修改，比如Dubbo的服務調用是通過RPC實現的，但是如果仔細拜讀過Martin Fowler的 microservices 一文，其定義的服務間通信是HTTP協議的REST API。那么這兩種有何區別呢？
先來說說，使用Dubbo的RPC來實現服務間調用的一些痛點：
- 服務提供方與調用方接口依賴方式太強：我們為每個微服務定義了各自的service抽象接口，並通過持續集成發布到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，因此不論開發、測試、集成環境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一致導致應用無法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼並install之后才能進行后續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關系會成為開發團隊的一大噩夢。而REST接口相比RPC更為輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，當然REST接口也有痛點，因為接口定義過輕，很容易導致定義文檔與實際實現不一致導致服務集成時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。所以在分布式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。
- 服務對平台敏感，難以簡單復用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平台的特點，任何一個語言的調用方都可以根據接口定義來實現。那么在Dubbo中我們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發布。若我們每個服務本身就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關系和權限控制就可實現服務的復用了。
相信這些痛點也是為什么當當網在dubbox（基於Dubbo的開源擴展）中增加了對REST支持的原因之一。
小結：Dubbo實現了服務治理的基礎，但是要完成一個完備的微服務架構，還需要在各環節去擴展和完善以保證集群的健康，以減輕開發、測試以及運維各個環節上增加出來的壓力，這樣才能讓各環節人員真正的專注於業務邏輯。而Spring Cloud依然發揚了Spring Source整合一切的作風，以標准化的姿態將一些微服務架構的成熟產品與框架揉為一體，並繼承了Spring Boot簡單配置、快速開發、輕松部署的特點，讓原本復雜的架構工作變得相對容易上手一些（如果您讀過我之前關於Spring Cloud的一些核心組件使用的文章，應該能體會這些讓人興奮而激動的特性，傳送門）。所以，如果選擇Dubbo請務必在各個環節做好整套解決方案的准備，不然很可能隨着服務數量的增長，整個團隊都將疲於應付各種架構上不足引起的困難。而如果選擇Spring Cloud，相對來說每個環節都已經有了對應的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區與高速的迭代進度也會是你可以依靠的強大后盾。
Round 4：文檔質量
Dubbo的 文檔 可以說在國內開源框架中算是一流的，非常全，並且講解的也非常深入，由於版本已經穩定不再更新，所以也不太會出現不一致的情況，另外提供了中文與英文兩種版本，對於國內開發者來說，閱讀起來更加容易上手，這也是dubbo在國內更火一些的原因吧。
Spring Cloud由於整合了大量組件，文檔在體量上自然要比dubbo多很多，文檔內容上還算簡潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要查看其整合組件的詳細文檔。另外由於Spring Cloud基於Spring Boot，很多例子相較於傳統Spring應用要簡單很多（因為自動化配置，很多內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議了解和學習Spring Boot之后再使用Spring Cloud，不然可能會出現很多一知半解的情況。
小結：雖然Spring Cloud的文檔量大，但是如果使用Dubbo去整合其他第三方組件，實際也是要去閱讀大量第三方組件文檔的，所以在文檔量上，我覺得區別不大。對於文檔質量，由於Spring Cloud的迭代很快，難免會出現不一致的情況，所以在質量上我認為Dubbo更好一些。而對於文檔語言上，Dubbo自然對國內開發團隊來說更有優勢。
總結
通過上面再幾個環節上的分析，相信大家對Dubbo和Spring Cloud有了一個初步的了解。就我個人對這兩個框架的使用經驗和理解，打個不恰當的比喻：使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。
從目前Spring Cloud的被關注度和活躍度上來看，很有可能將來會成為微服務架構的標准框架。所以，Spring Cloud的系列文章，我會繼續寫下去。也歡迎各位朋友一起交流，共同進步。
HSF：
簡介：HSF提供的是分布式服務開發框架，taobao內部使用較多，總體來說其提供的功能及一些實現基礎：
1.標准Service方式的RPC
1）、Service定義：基於OSGI的Service定義方式
2）、TCP/IP通信：
IO方式：nio,采用mina框架
連接方式：長連接
服務器端有限定大小的連接池
WebService方式
3）、序列化：Hessian序列化機制
2.軟件負載體系
3.模塊化、動態化
4.服務治理
性能：
Dubbo & HSF compare
Dubbo優點：
1. Dubbo比HSF的部署方式更輕量，HSF要求使用指定的JBoss等容器，還需要在JBoss等容器中加入sar包擴展，對用戶運行環境的侵入性大，如果你要運行在Weblogic或Websphere等其它容器上，需要自行擴展容器以兼容HSF的ClassLoader加載，而Dubbo沒有任何要求，可運行在任何Java環境中。
2. Dubbo比HSF的擴展性更好，很方便二次開發，一個框架不可能覆蓋所有需求，Dubbo始終保持平等對待第三方理念，即所有功能，都可以在不修改Dubbo原生代碼的情況下，在外圍擴展，包括Dubbo自己內置的功能，也和第三方一樣，是通過擴展的方式實現的，而HSF如果你要加功能或替換某部分實現是很困難的，比如支付寶和淘寶用的就是不同的HSF分支，因為加功能時改了核心代碼，不得不拷一個分支單獨發展，HSF現階段就算開源出來，也很難復用，除非對架構重寫。
3. HSF依賴比較多內部系統，比如配置中心，通知中心，監控中心，單點登錄等等，如果要開源還需要做很多剝離工作，而Dubbo為每個系統的集成都留出了擴展點，並已梳理干清所有依賴，同時為開源社區提供了替代方案，用戶可以直接使用。
4. Dubbo比HSF的功能更多，除了ClassLoader隔離，Dubbo基本上是HSF的超集，Dubbo也支持更多協議，更多注冊中心的集成，以適應更多的網站架構。
Dubbo在安全機制方面是如何解決的？
Dubbo主要針對內部服務，對外的服務，阿里有開放平台來處理安全和流控，所以Dubbo在安全方面實現的功能較少，基本上只防君子不防小人，只防止誤調用。
Dubbo通過Token令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。
HSF優點：
1.HSF框架采用 Netty + Hession數據序列化協議實現服務交互，Netty + Hession的組合在互聯網高並發量的場景下,特別是在TPS 上達到10w 以上時，性能和效率遠比REST 或者Web Service 高。
2.HSF框架的容錯機制，配置服務器是采用長連接的方式與服務節點進行網絡通訊，一旦發現有服務提供者實例出現故障，配置服務器在秒級就會感知到，此時會將出問題這台服務提供者的信息從該服務的服務器列表中刪除，並將更新后的服務器列表采用推送的方式同步給與該服務相關的所有服務調用者端，這樣當下次服務調用者再進行此服務的調用時，就不會因為隨機的方式再次對已經停止服務提供的服務器發起服務的調用。
3.HSF框架的線性擴展支持
Spring cloud:
Spring Cloud為開發人員提供了快速構建分布式系統中的一些通用模式（例如配置管理，服務發現，斷路器，智能路由，微代理，控制總線，一次性令牌，全局鎖，領導選舉，分布式 會話，群集狀態）。 分布式系統的協調引出樣板模式（boiler plate patterns），並且使用Spring Cloud開發人員可以快速地實現這些模式來啟動服務和應用程序。 它們可以在任何分布式環境中正常工作，包括開發人員自己的筆記本電腦，裸機數據中心和受管平台，如Cloud Foundry。
Dubbo和spring cloud的區別 ： 兩個框架的定義層面也不一樣，具體可以參照項目需求來選擇；