1.選型依據
整體解決方案和架構成熟度
社群熱度
可維護性
學習曲線
2.目前各大IT公司用的微服務架構
阿裡Dubbo/HSF
京東JSF
新浪微網誌Motan
當當網DubboX
......
3.各微服務架構對比
4.SpringCloud與Dubbo的對比
（1）社群活躍度
SpringCloud:https://github.com/spring-cloud
Dubbo:https://github.com/dubbo
（2）詳細對比結果
最大差別：SpringCloud抛棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。
嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴隻依靠一紙契約，不存在代碼級别的強依賴，這在強調快速演化的微服務環境下，顯得更加合适。
品牌機與組裝機的差別
很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務而言是至關重要的。使用Dubbo建構的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體品質不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的了解。
社群支援與更新力度
最為重要的是，DUBBO停止了5年左右的更新，雖然2017.7重新開機了。對于技術發展的新需求，需要由開發者自行拓展更新（比如當當網弄出了DubboX），這對于很多想要采用微服務架構的中小軟體組織，顯然是不太合适的，中小公司沒有這麼強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，并不是每一個公司都有阿裡的大牛+真實的線上生産環境測試過。
5.總結SpringCloud與Dubbo
問題：
曾風靡國内的開源 RPC 服務架構 Dubbo 在重新開機維護後，令許多使用者為之雀躍，但同時，也迎來了一些質疑的聲音。網際網路技術發展迅速，Dubbo 是否還能跟上時代？Dubbo 與 Spring Cloud 相比又有何優勢和差異？是否會有相關舉措保證 Dubbo 的後續更新頻率？
人物：Dubbo重新開機維護開發的劉軍，主要負責人之一
劉軍，阿裡巴巴中間件進階研發工程師，主導了 Dubbo 重新開機維護以後的幾個發版計劃，專注于高性能 RPC 架構和微服務相關領域。曾負責網易考拉 RPC 架構的研發及指導在内部使用，參與了服務治理平台、分布式跟蹤系統、分布式一緻性架構等從無到有的設計與開發過程。