spring cloud vs dubbo

題外話

dubbo到底是讀杜博還是達博，官方已有音标 |ˈdʌbəʊ|

正題

一、背景方面

-----------------------------------------------------------------------------------------------

• dubbo前期社群活躍度并不高，淘寶系主推的是HSF而并非dubbo。2017年dubbo被阿裡重新開機、2018年dubbo正式進入Apache孵化器。随着dubbo重新開機及進行apache體系，dubbo社群也非常活躍，阿裡也把dubbo做為重點項目。
• dubbo前期隻是一個PRC架構，目前随着nacos、sentinel等阿裡系項目開源，阿裡微服務架構也逐漸成為生态。
• 阿裡巴巴是一個商業公司，雖然也開源了很多的頂級的項目，但從整體戰略上來講，仍然是服務于自身的業務為主。
• 目前帶‘國’字号的企業使用dubbo還是比較多的，中國人壽、中國電信、中國工商銀行...

vs

• springcloud有着強大活躍的社群，在全全球範圍使用與影響巨大。
• springcloud是大名鼎鼎的Spring家族的産品,Spring專注于企業級開源架構的研發，不論是在中國還是在世界上使用都非常廣泛，開發出通用、開源、穩健的開源架構就是他們的主業
• springcloud生态相對全面完Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等(springcloud全家桶)
• 劉軍作為Dubbo重新開機的負責人也發表過觀點，Dubbo的發展方向是積極适應SpringCloud生态，并不是起沖突。

二、通訊方面

-----------------------------------------------------------------------------------------------

• Dubbo基于RPC協定，在OSI七層參考模型中http處于第一層應用層而rpc處于第三層會話層，是二進制的傳輸，占用帶寬會更少。
• Dubbo架構在于面向接口的程式設計模型，使得開發遠端服務調用就像開發本地服務一樣
• RPC依賴性強，對用戶端與服務端均要引用共用的service，對雙方在版本控制也有要求增加一定的耦合性
• REST在分布式環境下比RPC更加靈活,這也是為什麼當當網的DubboX在對Dubbo的增強中增加了對REST的支援的原因

vs

• Spring Cloud是HTTP協定傳輸，帶寬占用會比較多。但當下的企業内這點消耗的影響還是比較小的，并且http的封包也可以做一些壓縮的優化。
• springcloud使用feign(open feign)是rest輕量級、松散、更加靈活，不存在代碼之間的耦合，比較自由且松散。
• 微服務的提出者馬丁福勒定義的微服務通訊就是基于散耦合的rest

三、實作方面

-----------------------------------------------------------------------------------------------

• dubbo為每個微服務定義了各自的service抽象接口，并通過持續內建釋出到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，這就是大家所說的要依賴一大堆jar包。

vs

• Spring Cloud的接口協定約定比較自由且松散不存在強依賴

四、人才方面

-----------------------------------------------------------------------------------------------

• 目前市場上Spring Cloud的研發人員相關dubbo會更好招，springcloud人才更受企業歡迎