微服務架構-選擇Spring Cloud，放棄Dubbo

Spring Cloud 在國內中小型公司能用起來嗎?從 2016 年初一直到如今，咱們在這條路上已經走了一年多。

在使用 Spring Cloud 以前，咱們對微服務實踐是沒有太多的體會和經驗的。從最初的開源軟件雲收藏來熟悉 Spring Boot，到項目中的慢慢使用，再到最後全面擁抱 Spring Cloud。

這篇文章給你們介紹咱們使用 Spring Boot / Cloud 一年多的經驗總結。

在開始以前咱們先介紹幾個概念，什麼是微服務，它的特色是什麼? Spring Boot / Cloud 都作了那些事情?他們三者之間又有什麼關係?

什麼是微服務

微服務的概念源於 2014 年 3 月 Martin Fowler 所寫的一篇文章「Microservices」。文中內容提到：微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。

每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相溝通(一般是基於 HTTP 的 RESTful API)。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。

另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。

微服務架構優點

01複雜度可控

在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。

因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性和開發效率。

02獨立部署

因爲微服務具有獨立的運行進程，因此每一個微服務也能夠獨立部署。當某個微服務發生變動時無需編譯、部署整個應用。

由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降對生產環境所形成的風險，最終縮短應用交付週期。

03技術選型靈活

微服務架構下，技術選型是去中心化的。每一個團隊能夠根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。

因爲每一個微服務相對簡單，因此須要對技術棧進行升級時所面臨的風險就較低，甚至徹底重構一個微服務也是可行的。

04容錯

當某一組件發生故障時，在單一進程的傳統架構下，故障頗有可能在進程內擴散，造成應用全局性的不可用。

在微服務架構下，故障會被隔離在單個服務中。若設計良好，其餘服務可經過重試、平穩退化等機制實現應用層面的容錯。

05擴展

單塊架構應用也能夠實現橫向擴展，就是將整個應用完整的複製到不一樣的節點。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

什麼是 Spring Boot

Spring Boot 是由 Pivotal 團隊提供的全新框架，其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員再也不須要定義樣板化的配置。

用個人話來理解，就是 Spring Boot 不是什麼新的框架，它默認配置了不少框架的使用方式，就像 maven 整合了全部的 jar 包，Spring Boot 整合了全部的框架(不知道這樣比喻是否合適)。

Spring Boot 簡化了基於 Spring 的應用開發，經過少許的代碼就能建立一個獨立的、產品級別的 Spring 應用。Spring Boot 爲 Spring 平臺及第三方庫提供開箱即用的設置，這樣你就能夠有條不紊地開始。

Spring Boot 的核心思想就是約定大於配置，多數 Spring Boot 應用只須要不多的 Spring 配置。採用 Spring Boot 能夠大大的簡化你的開發模式，全部你想集成的經常使用框架，它都有對應的組件支持。

Spring Cloud 都作了哪些事

Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用 Spring Boot 的開發風格作到一鍵啓動和部署。

Spring 並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過 Spring Boot 風格進行再封裝、屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

如下爲 Spring Cloud 的核心功能：

• 分佈式/版本化配置。
• 服務註冊和發現。
• 路由。
• 服務和服務之間的調用。
• 負載均衡。
• 斷路器。
• 分佈式消息傳遞。

咱們再來看一張圖：

解釋一下這張圖中各組件的運行流程：

• 全部請求都統一經過 API 網關(Zuul)來訪問內部服務。
• 網關接收到請求後，從註冊中心(Eureka)獲取可用服務。
• 由 Ribbon 進行均衡負載後，分發到後端的具體實例。
• 微服務之間經過 Feign 進行通訊處理業務。
• Hystrix 負責處理服務超時熔斷。
• Turbine 監控服務間的調用和熔斷相關指標。

固然上面只是 Spring Cloud 體系的一部分，Spring Cloud 共集成了 19 個子項目，裏面都包含一個或者多個第三方的組件或者框架!

Spring Cloud 工具框架：

• Spring Cloud Config，配置中心，利用 git 集中管理程序的配置。
• Spring Cloud Netflix，集成衆多 Netflix 的開源軟件。
• Spring Cloud Bus，消息總線，利用分佈式消息將服務和服務實例鏈接在一塊兒，用於在一個集羣中傳播狀態的變化 。
• Spring Cloud for Cloud Foundry，利用 Pivotal Cloudfoundry 集成你的應用程序。
• Spring Cloud Foundry Service Broker，爲創建管理雲託管服務的服務代理提供了一個起點。
• Spring Cloud Cluster，基於 Zookeeper、Redis、Hazelcast、Consul 實現的領導選舉和平民狀態模式的抽象和實現。
• Spring Cloud Consul，基於 Hashicorp Consul 實現的服務發現和配置管理。
• Spring Cloud Security，在 Zuul 代理中爲 OAuth2 rest 客戶端和認證頭轉發提供負載均衡。
• Spring Cloud Sleuth Spring Cloud，應用的分佈式追蹤系統和 Zipkin、HTrace、ELK 兼容。
• Spring Cloud Data Flow，一個雲本地程序和操做模型，組成數據微服務在一個結構化的平臺上。
• Spring Cloud Stream，基於 Redis、Rabbit、Kafka 實現的消息微服務，簡單聲明模型用以在 Spring Cloud 應用中收發消息。
• Spring Cloud Stream App Starters，基於 Spring Boot 爲外部系統提供 Spring 的集成。
• Spring Cloud Task，短生命週期的微服務，爲 Spring Boot 應用簡單聲明添加功能和非功能特性。
• Spring Cloud Task App Starters。
• Spring Cloud Zookeeper，服務發現和配置管理基於 Apache Zookeeper。
• Spring Cloud for Amazon Web Services，快速和亞馬遜網絡服務集成。
• Spring Cloud Connectors，便於 PaaS 應用在各類平臺上鍊接到後端像數據庫和消息經紀服務。
• Spring Cloud Starters，項目已經終止而且在 Angel.SR2 後的版本和其餘項目合併。
• Spring Cloud CLI，插件用 Groovy 快速的建立 Spring Cloud 組件應用。

這個數量還在一直增長...

三者之間的關係

微服務是一種架構的理念，提出了微服務的設計原則，從理論爲具體的技術落地提供了指導思想。

Spring Boot 是一套快速配置腳手架，能夠基於 Spring Boot 快速開發單個微服務。

Spring Cloud 是一個基於 Spring Boot 實現的服務治理工具包;Spring Boot 專一於快速、方便集成的單個微服務個體;Spring Cloud 關注全局的服務治理框架。

Spring Boot / Cloud 是微服務實踐的最佳落地方案。

Spring Boot / Cloud 微服務實踐背景

2015 年初的時候，由於公司業務的大量發展，咱們開始對原有的業務進行拆分，新上的業務線也所有使用獨立的項目來開發，項目和項目之間經過 http 接口進行訪問。

2015 年的業務發展很是迅速，項目數量也就相應急劇擴大，到了年末的時候項目達 60 多個，當項目數達到 30 幾個的時候，咱們就遇到了問題，常常某個項目由於擴展增長了新的 IP 地址，就須要被動的更新好幾個相關的項目。

服務愈來愈多，服務之間的調用關係也愈來愈複雜，有時候想畫一張圖來表示項目和項目之間的依賴關係，線條密密麻麻沒法看清。下面有一張圖能夠表達咱們的心情：

這個時候咱們就想找一種方案，能夠將咱們這麼多分佈式的服務給管理起來，到網上進行了技術調研咱們發現有兩款開源軟件比較適合咱們，一個是 Dubbo，另外一個是 Spring Cloud。

剛開始咱們是走了一些彎路的，這兩款框架咱們都不熟悉，當時國內使用 Spring Cloud 進行開發的企業很是的少，我在網上也幾乎沒找到太多應用的案例。可是 Dubbo 在國內的使用仍是挺廣泛的，相關的資料各方面都比較完善。

所以在公司擴展新業務線衆籌平臺的時候，技術選型就先定了 Dubbo，由於也是全新的業務沒有什麼負擔，這個項目咱們大概開發了 6 個月投產，上線之初也遇到了一些問題，但最終還比較順利。

在新業務線選型使用 Dubbo 的同時，咱們也沒有徹底放棄 Spring Cloud，咱們抽出了一兩名開發人員學習 Spring Boot，我也參與其中。

爲了驗證 Spring Boot 是否能夠到達實戰的標準，咱們在業餘的時間使用 Spring Boot 開發了一款開源軟件雲收藏，通過這個項目的實戰驗證咱們對 Spring Boot 就有了信心。

最重要的是你們體會到使用 Spring Boot 的各類便利以後，就不再想使用傳統的方式來進行開發了。

可是還有一個問題，在選擇了 Spring Boot 進行新業務開發的同時，並無解決咱們上面的那個問題，服務與服務直接調用仍然比較複雜和傳統，這時候咱們就開始研究 Spring Cloud。

由於你們在前期對 Spring Boot 有了足夠的瞭解，所以學習 Spring Cloud 就顯得順風順水了。因此在使用 Dubbo 半年以後，咱們又全面開始擁抱 Spring Cloud。

爲何選擇使用 Spring Cloud 而放棄了 Dubbo

可能你們會問，爲何選擇了使用 Dubbo 以後，又選擇全面使用 Spring Cloud 呢?其中有以下四個緣由：

01從兩個公司的背景來談

Dubbo，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司;Spring Cloud 是大名鼎鼎的 Spring 家族的產品。

阿里巴巴是一個商業公司，雖然也開源了不少的頂級的項目，但從總體戰略上來說，仍然是服務於自身的業務爲主。

Spring 專一於企業級開源框架的研發，不管是在中國仍是在世界上使用都很是普遍，開發出通用、開源、穩健的開源框架是他們的主業。

02從社區活躍度這個角度來對比

Dubbo 雖然也是一個很是優秀的服務治理框架，而且在服務治理、灰度發佈、流量分發這方面作的比 Spring Cloud 還好，除過當當網在此基礎上增長了 rest 支持外，已有兩年多的時間幾乎沒有任何更新了。

在使用過程當中出現問題，開發者提交到 GitHub 的 Issue 也少有回覆。相反 Spring Cloud 自從發展到如今，仍然在不斷的高速發展。

從 GitHub 上提交代碼的頻度和發佈版本的時間間隔就能夠看出，如今 Spring Cloud 即將發佈 2.0 版本，到了後期會更加完善和穩定。

03從整個大的平臺架構來說

Dubbo 框架只是專一於服務之間的治理，若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中增長了使用 Dubbo 的難度。

Spring Cloud 幾乎考慮了服務治理的方方面面，更有 Spring Boot 這個大將的支持，開發起來很是的便利和簡單。

04從技術發展的角度來說

Dubbo 剛出來的那會技術理念仍是很是先進，解決了各大互聯網公司服務治理的問題，中國的各中小公司也從中受益很多。

通過了這麼多年的發展，互聯網行業也是涌現了更多先進的技術和理念，Dubbo 一直停滯不前，天然有些掉隊，有時候我我的也會感到有點惋惜，若是 Dubbo 一直沿着當初的那個路線發展，而且延伸到周邊，今天可能又是另外一番景象了。

Spring 推出Spring Boot / Cloud 也是由於自身的不少緣由。Spring 最初推崇的輕量級框架，隨着不斷的發展也愈來愈龐大，隨着集成項目愈來愈多，配置文件也愈來愈混亂，慢慢的背離最初的理念。

隨着這麼多年的發展，微服務、分佈式鏈路跟蹤等更多新的技術理念的出現，Spring 急需一款框架來改善之前的開發模式，所以纔會出現 Spring Boot / Cloud 項目。

咱們如今訪問 Spring 官網，會發現 Spring Boot 和 Spring Cloud 已經放到首頁最重點突出的三個項目中的前兩個，可見 Spring 對這兩個框架的重視程度。

所以 Dubbo 曾經確實很牛逼，可是 Spring Cloud 是站在近些年技術發展之上進行的開發，所以更具技術表明性。

如何進行微服務架構演進

當咱們將全部的新業務都使用 Spring Cloud 這套架構以後，就會出現這樣一個現象：公司的系統被分紅了兩部分，一部分是傳統架構的項目;另外一部分是微服務架構的項目，如何讓這兩套配合起來使用就成爲了關鍵。

這時候 Spring Cloud 裏面的一個關鍵組件解決了咱們的問題，就是 Zuul。在 Spring Cloud 架構體系內的全部微服務都經過 Zuul 來對外提供統一的訪問入口，全部須要和微服務架構內部服務進行通信的請求都走統一網關。以下圖：

從上圖能夠看出咱們對服務進行了四種分類，不一樣服務遷移的優先級不一樣：

• 基礎服務，是一些基礎組件，與具體的業務無關。好比：短信服務、郵件服務。這裏的服務最容易摘出來作微服務，也是咱們第一優先級分離出來的服務。
• 業務服務，是一些垂直的業務系統，只處理單一的業務類型，好比：風控系統、積分系統、合同系統。
• 這類服務職責比較單一，根據業務狀況來選擇是否遷移，好比：若是忽然有需求對積分系統進行大優化，咱們就趁機將積分系統進行改造，是咱們的第二優先級分離出來的服務。
• 前置服務，前置服務通常爲服務的接入或者輸出服務，好比網站的前端服務、app 的服務接口這類，這是咱們第三優先級分離出來的服務。

組合服務，組合服務就是涉及到了具體的業務，好比買標過程，須要調用不少垂直的業務服務，這類的服務咱們通常放到最後再進行微服務化架構來改造，由於這類服務最爲複雜，除非涉及到大的業務邏輯變動，咱們是不會輕易進行遷移。

在這四類服務以外，新上線的業務所有使用 Sprng Boot / Cloud 這套技術棧。

架構演化的步驟

架構演化的步驟以下：

• 在肯定使用Spring Boot / Cloud 這套技術棧進行微服務改造以前，請先梳理平臺的服務，對不一樣的服務進行分類，以確認演化的節奏。
• 先讓團隊熟悉 Spring Boot 技術，而且優先在基礎服務上進行技術改造，推進改動後的項目投產上線。
• 當團隊熟悉 Spring Boot 以後，再推動使用 Spring Cloud 對原有的項目進行改造。
• 在進行微服務改造過程當中，優先應用於新業務系統，前期能夠只是少許的項目進行了微服務化改造，隨着你們對技術的熟悉度增長，能夠加快加大微服務改造的範圍。

傳統項目和微服務項目共存是一個很常見的狀況，除非公司業務有大的變化，不建議直接遷移核心項目。

服務拆分

服務拆分的兩個原則：

• 橫向拆分。按照不一樣的業務域進行拆分，例如訂單、營銷、風控、積分資源等，造成獨立的業務領域微服務集羣。
• 縱向拆分。把一個業務功能裏的不一樣模塊或者組件進行拆分。例如把公共組件拆分紅獨立的原子服務，下沉到底層，造成相對獨立的原子服務層。這樣一縱一橫，就能夠實現業務的服務化拆分。

要作好微服務的分層：梳理和抽取核心應用、公共應用，做爲獨立的服務下沉到核心和公共能力層，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

服務拆分是越小越好嗎?微服務的大與小是相對的。好比在初期，咱們把交易拆分爲一個微服務，可是隨着業務量的增大，可能一個交易系統已經慢慢變得很大，而且併發流量也不小。

爲了支撐更多的交易量，我會把交易系統，拆分爲訂單服務、投標服務、轉讓服務等。所以微服務的拆分力度需與具體業務相結合，總的原則是服務內部高內聚，服務之間低耦合。

微服務 vs 傳統開發

使用微服務有一段時間了，這種開發模式和傳統的開發模式對比，有很大的不一樣，以下面幾點：

• 分工不一樣，之前咱們多是一個一個模塊，如今多是一人一個系統。
• 架構不一樣，服務的拆分是一個技術含量很高的問題，拆分是否合理對之後發展影響巨大。
• 部署方式不一樣，若是還像之前同樣部署估計累死了，自動化運維不可不上。
• 容災不一樣，好的微服務能夠隔離故障避免服務總體 down 掉，壞的微服務設計仍然能夠由於一個子服務出現問題致使連鎖反應。

給數據庫帶來的挑戰

每一個微服務都有本身獨立的數據庫，那麼後臺管理的聯合查詢怎麼處理?這是你們廣泛遇到的一個問題。

有以下三種處理方案：

• 嚴格按照微服務的劃分來作，微服務相互獨立，各微服務數據庫也獨立，後臺須要展現數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展現出來，這是標準的用法，也是最麻煩的用法。
• 將業務相關的表放到一個庫中，將業務無關的表嚴格按照微服務模式來拆分，這樣既可使用微服務，也避免了數據庫各類切換致使後臺統計難以實現，是一個折中的方案。
• 數據庫嚴格按照微服務的要求來切分，以知足業務高併發，實時或者準實時將各微服務數據庫數據同步到 NoSQL 數據庫中，在同步的過程當中進行數據清洗，用來知足後臺業務系統的使用，推薦使用 Mongodb、Hbase 等。

三種方案在不一樣的公司我都使用過，第一種方案適合業務較爲簡單的小公司;第二種方案，適合想在原有系統之上，慢慢演化爲微服務架構的公司;第三種適合大型高併發的互聯網公司。

微服務的經驗和建議

01建議儘可能不要使用 Jsp，頁面開發推薦使用 Thymeleaf

Web 項目建議獨立部署 Tomcat，不要使用內嵌的 Tomcat，內嵌 Tomcat 部署 Jsp 項目會偶現龜速訪問的狀況。

02服務編排是個好東西，主要的做用是減小項目中的相互依賴

好比如今有項目 a 調用項目 b，項目 b 調用項目 c...一直到 h，是一個調用鏈，那麼項目上線的時候須要先更新最底層的 h 再更新 g...更新 c 更新 b 最後是更新項目 a。

這只是一個調用鏈，在複雜的業務中有很是多的調用，若是要記住每個調用鏈對開發運維人員來講就是災難。

有一個好辦法能夠儘可能的減小項目間的相互依賴，就是服務編排，一個核心的業務處理項目，負責和各個微服務打交道。

好比以前是 a 調用 b，b 掉用 c，c 調用 d，如今統一在一個核心項目 W 中來處理，W 服務使用 a 的時候去調用 b，使用 b 的時候W去調用 c。

舉個例子：在第三方支付業務中，有一個核心支付項目是服務編排，負責處理支付的業務邏輯，W 項目使用商戶信息的時候就去調用「商戶系統」，須要校驗設備的時候就去調用「終端系統」，須要風控的時候就調用「風控系統」，各個項目須要的依賴參數都由W來作主控。之後項目部署的時候，只須要最後啓動服務編排項目便可。

03不要爲了追求技術而追求技術

須要考慮如下幾方面的因素：

• 團隊的技術人員是否已經具有相關技術基礎。
• 公司業務是否適合進行微服務化改造，並非全部的平臺都適合進行微服務化改造，好比：傳統行業有不少複雜垂直的業務系統。
• Spring Cloud 生態的技術有不少，並非每一種技術方案都須要用上，適合本身的纔是最好的。

總結

Spring Cloud 對於中小型互聯網公司來講是一種福音，由於這類公司每每沒有實力或者沒有足夠的資金投入去開發本身的分佈式系統基礎設施，使用 Spring Cloud 一站式解決方案能在從容應對業務發展的同時大大減小開發成本。

同時，隨着近幾年微服務架構和 Docker 容器概念的火爆，也會讓 Spring Cloud 在將來愈來愈「雲」化的軟件開發風格中立有一席之地。

尤爲是在目前五花八門的分佈式解決方案中提供了標準化的、全站式的技術方案，意義可能堪比當前 Servlet 規範的誕生，有效推動服務端軟件系統技術水平的進步。