系統微服務架構

系統微服務架構

 

一、系統微服務架構

2、什麼是微服務（Microservice）

 

　微服務英文名稱Microservice，Microservice架構模式就是將整個Web應用組織爲一系列小的Web服務。這些小的Web服務能夠獨立地編譯及部署，並經過各自暴露的API接口相互通信。它們彼此相互協做，做爲一個總體爲用戶提供功能，卻能夠獨立地進行擴充。

 

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

 1：咱們把整個系統根據業務拆分紅幾個子系統。

 2：每一個子系統能夠部署多個應用，多個應用之間使用負載均衡。

 3：須要一個服務註冊中心，全部的服務都在註冊中心註冊，負載均衡也是經過在註冊中心註冊的服務來使用必定策略來實現。

 4：全部的客戶端都經過同一個網關地址訪問後臺的服務，經過路由配置，網關來判斷一個URL請求由哪一個服務處理。請求轉發到服務上的時候也使用負載均衡。

 5：服務之間有時候也須要相互訪問。例若有一個用戶模塊，其餘服務在處理一些業務的時候，要獲取用戶服務的用戶數據。

 6：須要一個斷路器，及時處理服務調用時的超時和錯誤，防止因爲其中一個服務的問題而致使總體系統的癱瘓。

 7：還須要一個監控功能，監控每一個服務調用花費的時間等。

  

目前主流的微服務框架：Dubbo、 SpringCloud、thrift、Hessian等。

  

3、SpringCloud項目簡介

 

　SpringCloud是基於SpringBoot的一整套實現微服務的框架。他提供了微服務開發所需的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等組件。最重要的是，

跟spring boot框架一塊兒使用的話，會讓你開發微服務架構的雲服務很是好的方便。

  

  SpringBoot旨在簡化建立產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能

  

相關組件架構圖

  

 

1.Eureka簡介

 

   Eureka是Spring Cloud Netflix的一個子模塊，也是核心模塊之一。用於雲端服務發現，一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。

服務註冊與發現對於微服務系統來講很是重要。有了服務發現與註冊，你就不須要成天改服務調用的配置文件了，你只須要使用服務的標識符，就能夠訪問到服務。

   服務發現：服務發現是微服務基礎架構的關鍵原則之一。試圖着手配置每一個客戶端或某種格式的約定能夠說是很是困難的和很是脆弱的。Eureka是Netflix服務發現的一種服務和客戶端。這種服務是能夠被高可用性配置的和部署,而且在註冊的服務當中，每一個服務的狀態能夠互相複製給彼此。

   服務註冊:當一個客戶端註冊到Eureka,它提供關於本身的元數據（諸如主機和端口，健康指標URL，首頁等）Eureka經過一個服務從各個實例接收心跳信息。若是心跳接收失敗超過配置的時間，實例將會正常從註冊裏面移除

 下圖是基本的服務註冊和發現

 

對於應用，配製文件一般是放在項目中管理的，它可能有各類各樣的配置文件和屬性文件，另外還可能有開發環境、測試環境、生產環境等，這樣的話就得一式三份，如果傳統應用還好說，若是是微服務呢，這樣不光配置文件有可能冗餘並且量大，繁重複雜，很差維護，這樣的話就須要一個配置文件的統一管理了。

 

2.SpringCloud Config簡介

SpringCloud Config爲分佈式系統外部化配置提供了服務器端和客戶端的支持，它包括ConfigServer和ConfigClient兩部分。

 

　　　　

　　Server:

實例通常多於兩個，以實現HA；

配置以文件形式存儲，快速支持目前以SpringBoot的開發方式的配置文件；

支持GIt，碼雲，SVN，本地文件等多種形式；

支持屬性加密；

　　Client：即各自的微服務應用；

 

3.微服務網關ZUUL

 

因爲微服務過多，可能某一個小業務就須要調各類微服務的接口，不可避免的就會須要負載均衡和反向代理了，以確保ui不直接與全部的微服務接口接觸，因此咱們須要使用一個組件來作分發，跨域等各類請求。

　　ZUUL是Netflix開源的微服務網關，它能夠和Eureka、Ribbon、Hystrix等組件配合使用，它主要用做反向代理、Filter擴展、動態加載、動態路由、壓力測試、彈性擴展、審查監控、安全檢查等。
　　

 

經過網關的方式，提供致對外的服務，具體的服務調用分發由網關根據註冊中心進行分發。

 

4.熔斷器Hystrix

 

在微服務架構中一般會有多個服務層調用，基礎服務的故障可能會致使級聯故障，進而形成整個系統不可用的狀況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因「服務提供者」的不可用致使「服務消費者」的不可用,並將不可用逐漸放大的過程。

若是下圖所示：A做爲服務提供者，B爲A的服務消費者，C和D是B的服務消費者。A不可用引發了B的不可用，並將不可用像滾雪球同樣放大到C和D時，雪崩效應就造成了。

熔斷器（CircuitBreaker）

熔斷器的原理很簡單，如同電力過載保護器。它能夠實現快速失敗，若是它在一段時間內偵測到許多相似的錯誤，會強迫其之後的多個調用快速失敗，再也不訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操做，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可使應用程序可以診斷錯誤是否已經修正，若是已經修正，應用程序會再次嘗試調用操做。

熔斷器模式就像是那些容易致使錯誤的操做的一種代理。這種代理可以記錄最近調用發生錯誤的次數，而後決定使用容許操做繼續，或者當即返回錯誤。 熔斷器開關相互轉換的邏輯以下圖：

熔斷器就是保護服務高可用的最後一道防線。

 

 

5.熔斷器監控Hystrix-dashboard

是一款針對Hystrix進行實時監控的工具，經過Hystrix Dashboard咱們能夠在直觀地看到各Hystrix Command的請求響應時間, 請求成功率等數據。可是隻使用Hystrix Dashboard的話, 你只能看到單個應用內的服務信息, 這明顯不夠. 咱們須要一個工具能讓咱們彙總系統內多個服務的數據並顯示到Hystrix Dashboard上, 這個工具就是Turbine.在複雜的分佈式系統中，相同服務的節點常常須要部署上百甚至上千個，不少時候，運維人員但願可以把相同服務的節點狀態以一個總體集羣的形式展示出來，這樣能夠更好的把握整個系統的狀態。 爲此，Netflix提供了一個開源項目（Turbine）來提供把多個hystrix.stream的內容聚合爲一個數據源供Dashboard展現

 

 

6.Spring Cloud Sleuth服務跟蹤系統

 

通常的，一個分佈式服務跟蹤系統，主要有三部分：數據收集、數據存儲和數據展現。根據系統大小不一樣，每一部分的結構又有必定變化。譬如，對於大規模分佈式系統，數據存儲可分爲實時數據和全量數據兩部分，實時數據用於故障排查（troubleshooting），全量數據用於系統優化；數據收集除了支持平臺無關和開發語言無關係統的數據收集，還包括異步數據收集（須要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數據展現又涉及到數據挖掘和分析。雖然每一部分均可能變得很複雜，但基本原理都相似。

服務追蹤的追蹤單元是從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）爲止的過程，稱爲一個「trace」。每一個 trace 中會調用若干個服務，爲了記錄調用了哪些服務，以及每次調用的消耗時間等信息，在每次調用服務時，埋入一個調用記錄，稱爲一個「span」。這樣，若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程當中，會不斷地有請求和響應發生，也就會不斷生成 trace，把這些帶有span 的 trace 記錄下來，就能夠描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間，以及請求成功與否等信息，就能夠在發生問題的時候，找到異常的服務；根據歷史數據，還能夠從系統總體層面分析出哪裏性能差，定位性能優化的目標。

Spring Cloud Sleuth爲服務之間調用提供鏈路追蹤。經過Sleuth能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長。從而讓咱們能夠很方便的理清各微服務間的調用關係。此外Sleuth能夠幫助咱們：

•耗時分析: 經過Sleuth能夠很方便的瞭解到每一個採樣請求的耗時，從而分析出哪些服務調用比較耗時;

•可視化錯誤: 對於程序未捕捉的異常，能夠經過集成Zipkin服務界面上看到;

•鏈路優化: 對於調用比較頻繁的服務，能夠針對這些服務實施一些優化措施。

spring cloud sleuth能夠結合zipkin，將信息發送到zipkin，利用zipkin的存儲來存儲信息，利用zipkin ui來展現數據。

這是Spring Cloud Sleuth的概念圖：

ZipKin

Zipkin 是一個開放源代碼分佈式的跟蹤系統，由Twitter公司開源，它致力於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展示。

每一個服務向zipkin報告計時數據，zipkin會根據調用關係經過Zipkin UI生成依賴關係圖，顯示了多少跟蹤請求經過每一個服務，該系統讓開發者可經過一個 Web 前端輕鬆的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。