系統微服務架構

一、系統微服務架構

二、什麽是微服務（Microservice）

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

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

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

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

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

4

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

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

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

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

三、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 前端輕松的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。

系統微服務架構