我使用過的 Dubbo 和 Spring Cloud
自從2015年畢業開始從事 Java 開發工作，已經過去3年多了， 在各種不知名的小公司待過，經歷過生產力從低到高，技術從落後到先進的過程， Dubbo 和 Spring Cloud 就是我曾經所經歷過的兩次技術變革。微服務這個概念已經出現好多年了，但是最近幾年微服務異常火爆，很多以前使用 Dubbo 的公司也在紛紛嘗試轉型。Dubbo 好還是 Spring Cloud 好，有啥差異，有啥優缺點是人們常常討論的話題，很多知名大V也紛紛寫一些科普文章，我也拜讀過很多，讀完感受良多，也激起了我寫這篇文章的動力。這篇文章更多的不是解釋概念，而是講述我曾經使用到的兩種技術的方式，希望大家可以從文章中獲得啟發。
原生狀態
如果以前關注過 Dubbo ，對 Dubbo 印象最深的一個定位就是 ”服務治理“的概念。為什麼要服務治理？服務治理到底治理了什麼方面？這是我們遇到的最直觀的問題。
下面就展示下我們曾經沒有使用 Dubbo 的業務模型：
大體的業務如下：
1、我們有專案A，和專案B，專案A由專案管理部負責使用，專案B由物流部負責使用；
2、每當專案管理部在專案A中完成一個專案，那麼就必須發請求給專案B，通知專案B進行物流發貨；
3、專案B物流完成之後給專案A傳送一個請求，完成物流操作，告知專案A進入結算。
根據圖看的話，無非就是兩個專案互相呼叫，在沒用採用 Dubbo 之前，我們的專案結構就像圖中那樣混亂，很多問題都是不可避免的。下面我就把所有遇到的問題一一進行列舉，以專案A為例，：
1、開發者由於自身綜合素質不高，沒有良好編碼習慣和架構能力，對 webservice 的呼叫和服務暴露散落在各個層面如圖所示；
2、專案A中所有的請求的ip，寫在配置檔案，如果專案B修改了部署ip或者埠，專案A需要手動修改配置檔案然後重啟；
3、專案B如果修改了方法的引數和返回值，專案A無法得知；
4、專案A呼叫專案B使用的方式由於開發者的能力和經驗不同，採用的實現方式千奇百怪，有的使用 okhttp ，有的使用 Apache 的 HttpClient，有的使用原生的使用 Java 提供的原生操作。同樣，專案B中提供服務的方式也千奇百怪，有的是 Spring MVC 提供的 http 介面，有的使用的是 webservice，整個專案混亂不堪；
5、每個人寫的請求引數五花八門，比如超時時間設定，比如MediaType的設定等，沒有統一的規範；
6、當時介面是暴露在內網的，所以介面沒有做安全性校驗，但是這也是一大遺留問題。
Dubbo
當原生的架構出現了這些問題之後，我們需要對架構進行更新升級，綜合以前遇到的問題，我們提出了一些關於框架的需求：
1、呼叫其他服務的時候，不用手動的維護ip和埠；
2、暴露給其他服務的介面，介面形式要一致；呼叫其他服務的介面，方式要統一，引數統一設定，支援個別方法單獨設定引數；
3、採用RPC的形式，本地專案依賴遠端專案提供的sdk，呼叫sdk中的方法就可以實現遠端方法的呼叫。
在這樣的趨勢下，就很正常的選擇了 Dubbo 作為專案的框架，當時的想法也特別單純，和 Dubbo 當時的定位一樣，主要就是 ”服務治理“ ，讓混亂不堪的專案結構清晰起來。當時還沒有想到什麼分散式事務、服務熔斷、服務鑑權這些概念。我們使用 Dubbo 的時候， Dubbo 依然是停止更新狀態，還沒有捐獻給 Apache 。才採用 Dubbo 架構之後，我們對專案進行了整體的重構，同時引入了 SSO 的單點登入，最後的架構大致如下：
修改之後的架構大概如下：
1、新增了 CAS 伺服器作為統一認證，實現多專案的 SSO，保證登入了一個系統之後，其他的系統也處於登入狀態；
2、專案A和專案B，每個專案給對方提供一個 rpc-client 的包，裡面包含所提供的介面，公用的實體類等；
3、專案A和專案B，配置上增加 Dubbo 配置，比如註冊地址，序列化協議扥等 。一般都是採用 Dubbo 協議，認證到zookeeper中；
4、呼叫對方專案的介面時候，只需要注入 rpc-client 包中的類，呼叫其中的方法即可，dubbo會自動在zookeeper中查詢服務註冊資訊，傳送請求，返回結構。
Spring Cloud
現在的公司架構採用的 Spring Cloud 微服務架構，平時自己也有學習和研究 Spring Cloud 相關的知識，自己對 Spring Cloud 的架構認識大概如下圖：
大概的架構如下：
1、使用者訪問Nginx，跳轉到前臺頁面；
2、當頁面有ajax請求時候，通過訪問nginx，nginx轉發到 Spring Cloud Gateway，然後根據路由規則轉發到具體的某個微服務中；
3、nacos作為服務註冊發現 + 動態配置 + 服務監控使用，這裡替代了 eureka + config + admin，其中config 專案，沒有視覺化頁面，同時必須配合 Spring Cloud Bus + RabbitMQ通過訂閱訊息才可以實現配置的動態重新整理。是nacos一個專案融合了多個功能，如果以叢集方式部署，大大節省了專案的數量，比如 eureka + config + admin 都要實現高可用，那麼需要至少 3*3個例項，而 nacos 只需要3個例項即可，同時降低專案複雜度。同時動態配置這塊nacos提供了視覺化介面，並且有配置資訊回滾等操作，簡單且功能強大 ；
4、每個微服務之間難免有服務的呼叫，比如支付服務在付款的時候，必須呼叫訂單服務，把訂單中商品的數量和價格等資訊查詢過來，這裡使用的是 Feign ，每個微服務本身屬於 server 服務，給呼叫方提供一個 client 的sdk，當呼叫方使用 client 中的方法時候，就是實現了微服務之間的 Fegin 呼叫，同時配有 Hystrix 熔斷功能，防止介面長時間不返回，阻塞後續請求造成服務的連鎖奔潰反應。同時還包括有 Rbbion 的負載均衡和自動重試功能，某個服務無法訪問時候，自動進行切換並重試；
5、一次請求，可能涉及多個微服務，如果請求超時，那麼必須要能定位到哪一步的請求耗時過多，方便後續的優化修改，這時候就必須使用微服務的全鏈路追蹤，這裡使用了 Skywalking ，是因為 Skywalking 是通過位元組碼增強技術實現，無須手動埋點，切效能較高。 Zipkin + Seluth 的組合，需要多個專案，同時 Zipkin 是通過 http 請求收集資訊，效能較差；
6、其他的分散式事務、分散式主鍵發號器、分庫分表、快取等方案就暫時不寫，主要就是為了表達下 Spring Cloud 架構下的 Java 專案結構。
總結
大部分情況下，說區別其實是個偽概念，因為 Dubbo 能實現的方式 Spring Cloud 也能實現， 反之亦然。下面所說的區別是針對我個人曾經經歷過的專案，個人所得出的感覺，歡迎不同觀點朋友的探討：
- Dubbo
- 專案結構：一般為前後一體化的專案為主，多以 JSP 為頁面技術；
- 專案定位：每個專案一般稱之為一個系統，如 OA管理系統，BOSS系統等；
- 團隊構成：Java Web 員工為主，前後臺都寫；
- 使用群體：一般為公司內部員工及管理人員使用，受眾在百人與千人左右；
- 效能要求：效能要求不高，高可用要求也不高，偶爾停機更新影響個5分鐘，半小時都不會有太大影響（額。。好像容易捱打）；
- 技術聚焦：採用 Dubbo 更多是出於服務治理的原因，就是為了解決原生架構中，服務呼叫的混亂和難以管理等問題。
- Spring Cloud
- 專案結構： 微服務化，每個服務關於某個具體領域，每個專案擁有自己的資料庫。採用前後分離技術，前臺頁面關注於效果展示，頁面統一訪問閘道器，由閘道器根據路由規則轉發到具體的某個微服務中；
- 專案定位：每個專案稱之為微服務，只提供 http ( restful ) 介面，不負責頁面；
- 研發團隊：以微服務領域劃分，每個微服務應該有自己的團隊，獨立開發和維護，每個團隊儘可能將自己所負責的專案做到做好；
- 使用群體：以廣大使用者為主，人數成千上萬乃至億；
- 效能要求：一般微服務專案要求全年3個9（99.999%）或者4個9（99.9999%）高可用，微服務需要具備自動降級、故障切換、熔斷、線上擴容、重啟等功能；
- 技術聚焦：採用 Spring Cloud 架構，整個系統複雜度大幅度提升了，更多的是為在高併發和大流量下系統可以正常執行。
後記
由於本人經驗有限，經驗不足，文筆笨拙，文章寫的有點過於粗糙，以上分析和解釋可能還有錯誤和有失偏駁，還望大家批評指正。