許多討論微服務架構中springcloud和dubbo區別的文章中，主要強調dubbo只是springcloud的子集，只是服務治理工具，不是完整解決方案。但是看了一下兩者，感覺完全無法兼容，理念完全不同啊。
springboot開發的典型應用目錄如下：
分Controller、service介面、Serviceimpl實作、dao等層次。
1、sprinbcloud是用http呼叫controller層的REST介面，就像App或前端頁面訪問一個REST介面一樣，只是用RestTemplate封裝簡化了http呼叫的代碼（httpClient的寫法過于復雜）；sprinbcloud無法呼叫Service介面，Feign方式是在消費端加一個特別的介面類，看似以java API方式寫呼叫，實際與restTemplate是一樣的呼叫的controller層。
2、而Dubbo則需要提供介面類，是呼叫的Service層介面，把服務端的Service介面打成共享包，客戶端匯入就可以像寫本地代碼一樣呼叫了。但是dubbo無法呼叫Controller，Controller類沒有介面！客戶端無法以java API方式呼叫。
那么哪種更好呢？springcloud可以通用于任何語言，因為全是http呼叫的json資料，不需要按照java API方式來寫。這種方式耦合度小，可以與不同語言的第三方應用進行服務呼叫；Dubbo則與本地呼叫寫法相似，java的標準寫法（近年也已經支持了node.js和python等語言），更適合java技術堆疊，也更適合同構的微服務組件不需要與其它語言第三方應用整合的情況。個人感覺，service介面的意義，就是為了封裝業務邏輯，controller只和于處理請求和回傳，那么微服務呼叫service更合理，畢竟是后臺呼叫，特別是微服務都是自己團隊開發的，是一個業務應用的拆解，呼叫controller意義不大，很多情況下前端可以直接呼叫不同微服務的controller，干嘛在后端再呼叫一遍呢，除非是呼叫第三方的某個服務。
呼叫第三方的某個服務，一般用于應用整合比較松散的，按照第三方介面檔案用restTemplate直接呼叫就行了，不像一個應用拆解為多個微服務之間的耦合，往往也很難要求第三方應用采用相同的服務注冊中心。所以我傾向于用dubbo。
我的看法，請大家討論！
以下是幾個問題：
1、微服務應用呼叫controller還是service?
2、springcloud能呼叫service介面嗎？
3、Dubbo能呼叫controller嗎？怎么呼叫呢？
4、有必要都用上嗎？以便兩者都可以呼叫？
uj5u.com熱心網友回復：
都是個人看法1、微服務應用呼叫controller還是service?
根據業務來，如果系統劃分比較多，那就用controller，前端通過路由來對應多個后臺感覺比較合適（但是服務間調
用需要考慮 引數的 序列化和反序列化，較大的引數影響性能）
如果業務多，但是系統劃分的少，那就用service ，需要改的只是后端
2、springcloud能呼叫service介面嗎？
不知道，只用它呼叫controller
3、Dubbo能呼叫controller嗎？怎么呼叫呢？
不知道，只用它調過service
4、有必要都用上嗎？以便兩者都可以呼叫？
如果系統劃分比較多，類似多平臺，那么多平臺可以使用 springcloud，平臺的內部呼叫使用dubbo
uj5u.com熱心網友回復：
從你的實踐來看用法確實不同，分別呼叫controller和service。1回答沒看明白，前端呼叫直接請求后端吧，微服務之間的呼叫應該是后端呼叫吧。
uj5u.com熱心網友回復：
其實我的意思就是
場景需要呼叫的service 數量多時就用 dubbo，數量少 就用 spring-cloud，
針對前端， 不同的請求呼叫不同的服務，
針對后臺，一個請求 一個服務接收，多個服務處理
可以把這個兩個框架的開發環境都搭建一下，畢竟每個人的習慣 和 業務的側重點是不一樣的。。。。
uj5u.com熱心網友回復：
網上看不到有人說springcloud無法呼叫Service層介面，或Dubbo無法呼叫Controller介面這種說法，請熟悉的高手來解答一下吧。轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/82230.html
標籤：Web 開發
上一篇：springboot2.1.1加入swagger后Docket缺失
下一篇：hashmap原始碼分析后疑慮