SpringClound簡介，微服務架構，以及與Dubbo的詳細比較

• 什麼是Spring Clound
• 為什麼需要Spring Clound
• SpringClound與同類Dubbo微服務比較

什麼是Spring Clound

Spring Cloud 是一套完整的微服務解決方案，基於 Spring Boot 框架，準確的說，它不是一個框架，而是一個大的容器，它將市面上較好的微服務框架整合進來，從而簡化了開發者的程式碼量。

為什麼需要Spring Clound

Spring Cloud 是整個 Spring 家族中新的成員，要致力於分散式系統、雲服務的框架。 Spring Cloud 為開發人員提供了快速構建分散式系統中一些常見模式的工具，例如：

• 配置管理
• 服務註冊與發現
• 斷路器
• 智慧路由
• 服務間呼叫
• 負載均衡
• 微代理
• 控制匯流排
• 一次性令牌
• 全域性鎖
• 領導選舉
• 分散式會話
• 叢集狀態
• 分散式訊息
  一句話概括：SpringCloud是分散式微服務架構下的一站式解決方案，是各個微服務架構落地技術集合，俗稱微服務全家桶。
  微服務架構使用場景
  首先，我們需要看看一般的微服務架構需要的功能或使用場景：

1. 我們把整個系統根據業務拆分成幾個子系統。
2. 每個子系統可以部署多個應用，多個應用之間使用負載均衡。
3. 需要一個服務註冊中心，所有的服務都在註冊中心註冊，負載均衡也是通過在註冊中心註冊的服務來使用一定策略來實現。
4. 所有的客戶端都通過同一個閘道器地址訪問後臺的服務，通過路由配置，閘道器來判斷一個URL請求由哪個服務處理。請求轉發到服務上的時候也使用負載均衡。
5. 服務之間有時候也需要相互訪問。例如有一個使用者模組，其他服務在處理一些業務的時候，要獲取使用者服務的使用者資料。
6. 需要一個斷路器，及時處理服務呼叫時的超時和錯誤，防止由於其中一個服務的問題而導致整體系統的癱瘓。
7. 還需要一個監控功能，監控每個服務呼叫花費的時間等。
   總之，Spring Clound只是微服務架構的一種解決方案，下面我們再看看微服務架構同類產品比較。

SpringClound與同類Dubbo微服務比較

目前市面上主要就是SpringClound VS Dubbo。

1. Spring Clound的優缺點
   Spring Clound主要優點：

• 集大成者，Spring Cloud 包含了微服務架構的方方面面。
• 約定優於配置，基於註解，沒有配置檔案。
• 輕量級元件，Spring Cloud 整合的元件大多比較輕量級，且都是各自領域的佼佼者。
• 開發簡便，Spring Cloud 對各個元件進行了大量的封裝，從而簡化了開發。
• 開發靈活，Spring Cloud 的元件都是解耦的，開發人員可以靈活按需選擇元件。
  Spring Clound的缺點：
• 專案結構複雜，每一個元件或者每一個服務都需要建立一個專案。
• 部署門檻高，專案部署需要配合 Docker 等容器技術進行叢集部署，而要想深入瞭解 Docker，學習成本高。

2. Spring Clound 對比Dubbo
   Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於阿里巴巴集團的各成員站點。
   1）社群活躍度
   在社群活躍度上，Spring Cloud毋庸置疑的優於Dubbo，這對於沒有大量精力與財力維護這部分開源內容的團隊來說，Spring Cloud會是更優的選擇。
   2）架構完整度
   
   圖可以看出，Spring Cloud 比較全面，Spring Cloud下面有17個子專案（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面。
   而 Dubbo 由於只實現了服務治理，需要整合其他模組，需要單獨引入，增加了學習成本和整合成本。一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。
   3）文件質量
   Dubbo的文件可以說在國內開源框架中算是一流的，非常全，並且講解的也非常深入，由於版本已經穩定不再更新，所以也不太會出現不一致的情況，另外提供了中文與英文兩種版本，對於國內開發者來說，閱讀起來更加容易上手，這也是dubbo在國內更火一些的原因吧。
   Spring Cloud由於整合了大量元件，文件在體量上自然要比dubbo多很多，文件內容上還算簡潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要檢視其整合元件的詳細文件。另外由於Spring Cloud基於Spring Boot，很多例子相較於傳統Spring應用要簡單很多（因為自動化配置，很多內容都成了約定的預設配置），這對於剛接觸的開發者可能會有些不適應，比較建議瞭解和學習Spring Boot之後再使用Spring Cloud，不然可能會出現很多一知半解的情況。
   總之：雖然Spring Cloud的文件量大，但是如果使用Dubbo去整合其他第三方元件，實際也是要去閱讀大量第三方元件文件的，所以在文件量上，我覺得區別不大。對於文件質量，由於Spring Cloud的迭代很快，難免會出現不一致的情況，所以在質量上我認為Dubbo更好一些。而對於文件語言上，Dubbo自然對國內開發團隊來說更有優勢。
3. 對比總結
   通過上面幾個環節上的分析，相信大家對Dubbo和Spring Cloud有了一個初步的瞭解。
   就我個人對這兩個框架的使用經驗和理解，打個不恰當的比喻：
   使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題。
   而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的瞭解。