SpringCloud和Dubbo

SpringCloud整合了一套較為完整的微服務解決方案框架，而Dubbo只是解決了微服務的幾個方面的問題。

當然，雖然dubbo沒有提供很多解決方案，但他也可以整合第三方的專案來實現。

如何進行微服務架構演進

當我們將所有的新業務都使用Spring Cloud這套架構之後，就會出現這樣一個現象，公司的系統被分成了兩部分，一部分是傳統架構的專案，一部分是微服務架構的專案，如何讓這兩套配合起來使用就成為了關鍵，這時候Spring Cloud裡面的一個關鍵元件解決了我們的問題，就是Zuul。在Spring Cloud架構體系內的所有微服務都通過Zuul來對外提供統一的訪問入口，所有需要和微服務架構內部服務進行通訊的請求都走統一閘道器。如下圖：

從上圖可以看出我們對服務進行了分類，有四種：基礎服務、業務服務、組合服務、前置服務。不同服務遷移的優先順序不同

• 基礎服務，是一些基礎元件，與具體的業務無關。比如：簡訊服務、郵件服務。這裡的服務最容易摘出來做微服務，也是我們第一優先順序分離出來的服務。

• 業務服務，是一些垂直的業務系統，只處理單一的業務型別，比如：風控系統、積分系統、合同系統。這類服務職責比較單一，根據業務情況來選擇是否遷移，比如：如果突然有需求對積分系統進行大優化，我們就趁機將積分系統進行改造，是我們的第二優先順序分離出來的服務。

• 前置服務，前置服務一般為服務的接入或者輸出服務，比如網站的前端服務、app的服務介面這類，這是我們第三優先順序分離出來的服務。

• 組合服務，組合服務就是涉及到了具體的業務，比如買標過程，需要呼叫很多垂直的業務服務，這類的服務我們一般放到最後再進行微服務化架構來改造，因為這類服務最為複雜，除非涉及到大的業務邏輯變更，我們是不會輕易進行遷移。

在這四類服務之外，新上線的業務全部使用Sprng Boot/Cloud這套技術棧。就這樣，我們從開源專案雲收藏開始，上線幾個Spring Boot專案，到現在公司絕大部分的專案都是在Spring Cloud這個架構體系中。

經驗和教訓

架構演化的步驟

• 在確定使用Spring Boot/Cloud這套技術棧進行微服務改造之前，先梳理平臺的服務，對不同的服務進行分類，以確認演化的節奏。

• 先讓團隊熟悉Spring Boot技術，並且優先在基礎服務上進行技術改造，推動改動後的專案投產上線

• 當團隊熟悉Spring Boot之後，再推進使用Spring Cloud對原有的專案進行改造。

• 在進行微服務改造過程中，優先應用於新業務系統，前期可以只是少量的專案進行了微服務化改造，隨著大家對技術的熟悉度增加，可以加快加大微服務改造的範圍

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

服務拆分原則

服務拆分有以下幾個原則和大家分享

橫向拆分。按照不同的業務域進行拆分，例如訂單、營銷、風控、積分資源等。形成獨立的業務領域微服務叢集。

縱向拆分。把一個業務功能裡的不同模組或者元件進行拆分。例如把公共元件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現業務的服務化拆分。

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

服務拆分是越小越好嗎？微服務的大與小是相對的。比如在初期，我們把交易拆分為一個微服務，但是隨著業務量的增大，可能一個交易系統已經慢慢變得很大，並且併發流量也不小，為了支撐更多的交易量，我會把交易系統，拆分為訂單服務、投標服務、轉讓服務等。因此微服務的拆分力度需與具體業務相結合，總的原則是服務內部高內聚，服務之間低耦合。

微服務vs傳統開發

使用微服務有一段時間了，這種開發模式和傳統的開發模式對比，有很大的不同。

• 分工不同，以前我們可能是一個一個模組，現在可能是一人一個系統。

• 架構不同，服務的拆分是一個技術含量很高的問題，拆分是否合理對以後發展影響巨大。

• 部署方式不同，如果還像以前一樣部署估計累死了，自動化運維不可不上。

• 容災不同，好的微服務可以隔離故障避免服務整體down掉，壞的微服務設計仍然可以因為一個子服務出現問題導致連鎖反應。

給資料庫帶來的挑戰

每個微服務都有自己獨立的資料庫，那麼後臺管理的聯合查詢怎麼處理？這應該是大家會普遍遇到的一個問題，有三種處理方案。

1）嚴格按照微服務的劃分來做，微服務相互獨立，各微服務資料庫也獨立，後臺需要展示資料時，呼叫各微服務的介面來獲取對應的資料，再進行資料處理後展示出來，這是標準的用法，也是最麻煩的用法。

2) 將業務高度相關的表放到一個庫中，將業務關係不是很緊密的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了資料庫分散導致後臺系統統計功能難以實現，是一個折中的方案。

3）資料庫嚴格按照微服務的要求來切分，以滿足業務高併發，實時或者準實時將各微服務資料庫資料同步到NoSQL資料庫中，在同步的過程中進行資料清洗，用來滿足後臺業務系統的使用，推薦使用MongoDB、HBase等。

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

微服務的經驗和建議

1、建議儘量不要使用Jsp，頁面開發推薦使用Thymeleaf。Web專案建議獨立部署Tomcat，不要使用內嵌的Tomcat，內嵌Tomcat部署Jsp專案會偶現龜速訪問的情況。

2、服務編排是個好東西，主要的作用是減少專案中的相互依賴。比如現在有專案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來做主控。以後專案部署的時候，只需要最後啟動服務編排專案即可。

3、不要為了追求技術而追求技術，確定進行微服務架構改造之前，需要考慮以下幾方面的因素：
1）團隊的技術人員是否已經具備相關技術基礎。
2）公司業務是否適合進行微服務化改造，並不是所有的平臺都適合進行微服務化改造，比如：傳統行業有很多複雜垂直的業務系統。
3）Spring Cloud生態的技術有很多，並不是每一種技術方案都需要用上，適合自己的才是最好的。