1. 程式人生 > >SpringCloud(一)微服務概述及SpringCloud元件

SpringCloud(一)微服務概述及SpringCloud元件

1、微服務概述

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

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

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

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

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

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

地址訪問後臺的服務,通過路由配置,閘道器來判斷一個URL請求由哪個服務處理。請求轉發到服務上的時候也使用負載均衡。

 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:基於RibbonHystrix的宣告式服務呼叫元件。
  • Zuul:閘道器元件,提供智慧路由、訪問過濾等功能。
  • Archaius:外部化配置元件。 

2.3、SpringCloud特點

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

3、SpringCloud和SpringBoot的關係

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

4、SpringCloud和Dubbo的比較

4.1、最大的區別

SpringCloud拋棄了DubboRPC通訊,採用基於HTTPREST方式。

嚴格來說,這行兩種方式各有優劣。雖然從一定程度上來說,後者犧牲了服務呼叫的效能,但也避免了原生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/