1、微服務概述

微服務的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術的角度看就是一種小而獨立的處理過程，類似程序概念，能夠自行單獨啟動或銷燬，擁有自己獨立的資料庫。

微服務架構需要的功能或使用場景：

1、我們把整個系統根據業務拆分成幾個子系統。

 2、每個子系統可以部署多個應用，多個應用之間使用負載均衡。

 3、需要一個服務註冊中心，所有的服務都在註冊中心註冊，負載均衡也是通過在註冊中心註冊的服務來使用一定策略來實現。

 4、所有的客戶端都通過同一個閘道器

 5、服務之間有時候也需要相互訪問。例如有一個使用者模組，其他服務在處理一些業務的時候，要獲取使用者服務的使用者資料。

 6、需要一個斷路器，及時處理服務呼叫時的超時和錯誤，防止由於其中一個服務的問題而導致整體系統的癱瘓。

 7、還需要一個監控功能，監控每個服務呼叫花費的時間等。

2、SpringCloud是什麼？

2.1、官網說明

SpringCloud，基於SpringBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務閘道器，負載均衡，熔斷器等元件，除了基於NetFlix的開源元件做高度抽象封裝之外，還有一些選型中心的開源元件。

           SpringCloud利用SpringBoot的開發便利性巧妙的簡化了分散式系統基礎設施的開發，SpringCloud為開發人員提供了快速構建分散式系統的一些工具，，包括配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等,它們都可以用SpringBoot的開發風格做到一鍵啟動和部署。

2.2、SpringCloud常用元件

spring cloud子專案包括：

1. Spring Cloud Config：配置管理開發工具包，可以讓你把配置放到遠端伺服器，目前支援本地儲存、Git以及Subversion。
2. Spring Cloud Bus：事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
3. Spring Cloud for Cloud Foundry：通過Oauth2協議繫結服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS雲平臺。
4. Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper,Zipkin和HTrace操作。
5. Spring Cloud Data Flow：大資料操作工具，通過命令列方式操作資料流。
6. Spring Cloud Security：安全工具包，為你的應用程式新增安全控制，主要是指OAuth2。
7. Spring Cloud Consul：封裝了Consul操作，consul是一個服務發現與配置工具，與Docker容器可以無縫整合。
8. Spring Cloud Zookeeper：操作Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。
9. Spring Cloud Stream：資料流操作開發包，封裝了與Redis,Rabbit、Kafka等傳送接收訊息。
10. Spring Cloud CLI：基於 Spring Boot CLI，可以讓你以命令列方式快速建立雲元件。
11. SpringCloud Netflix：針對多種Netflix元件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

• Eureka：服務治理元件，包含服務註冊中心、服務註冊與發現機制的實現。
• Hystrix：容錯管理元件，實現斷路器模式，幫組服務服務依賴中出現的延遲和故障提供強大的容錯能力。
• Ribbon：客戶端負載均衡的服務呼叫元件。
• Feign：基於Ribbon和Hystrix的宣告式服務呼叫元件。
• Zuul：閘道器元件，提供智慧路由、訪問過濾等功能。
• Archaius：外部化配置元件。 

2.3、SpringCloud特點

• 約定優於配置
• 開箱即用、快速啟動
• 適用於各種環境
• 輕量級的元件
• 元件支援豐富，功能齊全

3、SpringCloud和SpringBoot的關係

• SpringBoot專注於快速方便的開發單個個體微服務。
• SpringCloud是關注全域性的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
• 為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等繼承服務。
• SpringBoot可以離開SpringCloud獨立使用開發專案，但是SpringCloud離不開SpringBoot，屬於依賴的關係。
• SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud專注全域性的服務治理框架。

4、SpringCloud和Dubbo的比較

4.1、最大的區別

SpringCloud拋棄了Dubbo的RPC通訊，採用基於HTTP的REST方式。

嚴格來說，這行兩種方式各有優劣。雖然從一定程度上來說，後者犧牲了服務呼叫的效能，但也避免了原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和呼叫方的依賴只依賴一紙契約，不存在程式碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。

4.2、品牌機與組裝機的區別

很明顯，Spring Cloud的功能比dubbo更加強大，涵蓋面更廣，而且作為Spring的拳頭專案，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring專案完美融合，這些對於微服務而言是至關重要的。

使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的瞭解。 

4.3、社群支援與更新力度

最為重要的是，dubbo停止了5年左右的更新，雖然2017.7重啟了。對於技術發展的新需求，需要由開發者自行拓展升級（比如噹噹網弄出了DubboX），這對於很多想要採用微服務架構的中小軟體組織，顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改Dubbo原始碼+周邊的一整套解決方案，並不是每一個公司都有阿里的大牛+真實的線上生產環境測試過。

5、經驗和教訓

5.1、架構演化的步驟

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

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

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

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

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

5.2、服務拆分原則

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

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

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

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

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

5.3、微服務vs傳統開發

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

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

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

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

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

5.4、給資料庫帶來的挑戰

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

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

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

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

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

5.5、微服務的經驗和建議

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生態的技術有很多，並不是每一種技術方案都需要用上，適合自己的才是最好的。

6、參考資料

1、官網：http://projects.spring.io/spring-cloud/

2、參考書：

         https://springcloud.cc/spring-cloud-netflix.html

         本次開發API說明：

                   http://cloud.spring.io/spring-cloud-static/Dalston.SR1/

                   https://springcloud.cc/spring-cloud-dalston.html

                   https://springcloud.cc/spring-cloud-dalston.html

3、springcloud中國社群：http://springcloud.cn/

4、springcloud中文網：https://springcloud.cc/