微服務架構基礎

時間 2019-11-13

標籤微服架構基礎欄目系統架構简体版

原文原文鏈接

一·微服務架構的組件

服務註冊中心：註冊系統中全部服務的地方

服務註冊：服務提供方將本身調用地址到服務註冊中心，讓服務調用方可以方便地找到本身

服務發現：服務調用方從服務註冊中心找到本身須要調用的服務的地址

負載均衡：服務提供方通常以多實例的形式提供服務，使用負載均衡可以讓服務調用方鏈接到合適的服務節點。

服務容錯：經過斷路器（也稱熔斷器）等一系列的服務保護機制，保證服務調用者在調用異常服務時快速地返回結果，避免大量的同步等待。

服務網關：也稱API網關，是服務調用的惟一入口，能夠在這個組件中實現用戶鑑權、動態路由、灰度發佈、負載限流等功能。

分佈式配置中心：將本地化的配置信息註冊到配置中心，實現程序包在開發、測試、生產環境的無差異性，方便程序包的遷移。

健康檢查

日誌處理

二·Spring Boot的工做機制

Spring Boot 的核心註解：@SpringBootApplication

是由@SpringBootConfiguration

@EnableAutoConfiguration

@ComponentScan 組成的能夠由這三個註解替換@SpringBootApplication這一註解

在@SpringBootApplication的源碼中能夠看出是由這三個註解組成的，這三個註解都有各自的做用

@SpringBootConfiguration 表示其標註的類是IoC容器的配置類

@EnableAutoConfiguration 用於將全部的符合自動配置的Bean加載到當前Spring Boot建立並使用的IoC容器中

@ComponentScan 用於掃描和加載符合條件的組件或Bean，並將Bean加載到ioc容器中

main方法的執行流程：

1 建立SpringApplication對象

2 調用實例的run()方法

執行流程：

spring boot整合了多個組件 redis、activeMQ等等，直接在pom.xml中配置相應的依賴就能夠。

三·Spring Cloud

服務發現：用於實現各個微服務實例的自動化註冊與發現。spring cloud使用Eureka來實現服務的發現功能。

Eureka:主要用於達到負載均衡和中間層服務故障轉移的目的（失效轉移）。

Eureka的服務發現包含兩大組件：服務端發現組件也叫服務註冊中心，主要提供了服務的註冊功能(Eureka Server)和客戶端發現組件（Eureka Client），主要用於處理服務的註冊與發現。

Eureka的服務發現機制以下圖所示

Eureka移除服務節點的條件：若是連續三次心跳都不能發現服務，那麼Eureka就會將這個服務節點從服務註冊表中移除。心跳默認時間爲30s。

與此同時，客戶端發現組件還會從服務端查詢當前註冊的服務信息並緩存到本地，即便Eureka Server出現了問題，客戶端組件也能夠經過緩存中的信息調用服務節點的服務。各個服務之間會經過註冊中心的註冊信息以Rest方式來實現調用，而且能夠直接經過服務名進行調用。

Eureka的服務發現機制包含了3個角色：服務註冊中心、服務提供者和服務消費者，三個角色之間的關係如圖所示：

服務提供者能夠是spring boot應用，也能夠是其餘技術平臺遵循Eureka通訊機制的應用，應用在運行時會自動的將本身提供的服務註冊到Eureka Server以提供其餘應用的發現。

服務消費者就是須要服務的應用，該服務在運行時會從服務註冊中心獲取服務列表，而後經過服務列表知道去何處調用其餘服務。服務消費者會與服務註冊中心保持心跳鏈接，一旦服務提供者的地址發生變化時，註冊中心會通知服務消費者。

客戶端負載均衡：

由 Spring cloud Ribbon 實現，Ribbon 在工做時主要分爲兩步：

首先選擇Eureka Server 他會優先選擇在同一個區域且負載較少的Server

第二步會根據用戶指定的策略(如輪詢、隨機等)從Server取到的服務註冊列表中選擇一個地址。

服務容錯保護 Spring cloud Hystris

分佈式架構的熔斷器至關於咱們生活中的空氣開關，當電流發生短路的時候，空氣開關會馬上斷開電流。

在微服務架構中，一般存在多個服務層調用的狀況，若是基礎服務出現故障可能會發生級聯傳遞，致使整個服務鏈上的服務不可用。

圖中A爲服務提供者，B爲A的服務服務調用者，C和D是B的服務調用者。隨着時間的推移，當服務A不可用的時候，會引發服務B的不可引用，進而影響服務C和D對於服務B的引用這一連鎖反應。

熔斷器能夠解決這個問題，也就是Spring cloud Hystris這一組件。它是用來實現斷路器、線程隔離等服務保護功能的。

熔斷器是能夠實現彈性容錯的，在必定條件下他可以自動打開或關閉，其使用時主要有三種狀態：

斷路器的開關由關閉到打開的狀態是經過當前服務健康情況（服務的健康情況=請求失敗數/請求總數）和設定閾值（默認爲10秒內的20次故障）比較決定的。當斷路器開關關閉時，請求被容許經過斷路器，若是當前健康情況高於設定閾值，開關繼續保持關閉；若是當前健康情況低於設定閾值，開關則切換爲打開狀態。當斷路器開關打開時，請求被禁止經過；若是設置了fallback方法，則會進入fallback的流程。當斷路器開關處於打開狀態，通過一段時間後，斷路器會自動進入半開狀態，這時斷路器只容許一個請求經過；當該請求調用成功時，斷路器恢復到關閉狀態；若該請求失敗，斷路器繼續保持打開狀態，接下來的請求會被禁止經過。

Spring Cloud Hystrix能保證服務調用者在調用異常服務時快速地返回結果，避免大量的同步等待，這是經過HystrixCommand的fallback方法實現的。雖然A服務仍然不可用，但採用fallback的方式能夠給用戶一個友好的提示結果，這樣就避免了其餘服務的崩潰問題。

@HystrixCommand 註解來指定回調方法該方法是經過其屬性fallbackMethod屬性值來指定的。回調方法的的參數類型以及返回值必需要和原方法保持一致。

/**
* 用戶控制器類
*/
@RestController
public class UserController {
@Autowired
private RestTemplate restTemplate;
/**
* 查找與用戶相關的訂單
*/
@GetMapping("/findOrdersByUser/{id}")
@HystrixCommand(fallbackMethod = "fallbackInfo")
public String findOrdersByUser(@PathVariable String id) {
    return this.restTemplate.getForObject("http://microservice-eureka-order/order/" +
     id,String.class);
}
/**
* 返回信息方法
*/
public String fallbackInfo(@PathVariable String id){
    return "服務不可用，請稍後再試！";
 }
}

Hystris Dashboard：可以對服務進行實時監控。要想實時地對服務進行監控，須要在項目中添加相關的依賴：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

API網關：

微服務基礎架構：

集羣包含ServiceA 和ServiceB兩種服務，他們會向Eureka Server註冊和訂閱服務，Open Service是一我的對外的RESTful API服務，客戶端會經過負載均衡技術，如Ngnix，實現對Open Servise的調用，同時服務之間也會經過Ribbon技術實現服務之間負載均衡的調用。但實際應用中，客戶端與微服務進行直接交互仍是存在着一些困難和限制的，主要體如今以下幾個方面：

1 增長開發成本和維護成本

2 微服務重構困難

3 微服務協議限制 web socket協議(服務端推送技術) http協議 rpc協議(跨越應用層和傳輸層)

解決上述問題最好的辦法就是採用API Gateway網關的方式。API Gateway是一個服務器，能夠說是進入系統的惟一節點，他封裝了內部系統的架構，而且提供可API給客戶端。它還能夠有其餘功能，如受權、監控、負載均衡、緩存、請求分片和管理、靜態相應處理。

當前架構圖

API Gateway負責請求轉發、合成和協議轉換。全部來自客戶端的請求都要先通過API Gateway，而後負載均衡這些請求到對應的微服務。API Gateway還能夠在Web協議與內部使用的非Web協議間進行轉換，如HTTP協議、WebSocket協議。

Ngnix 反向代理：正向代理最大的特色是客戶端很是明確要訪問的服務器地址。反向代理的客戶端不知道要訪問哪臺服務器。主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息。多個客戶端給服務器發送的請求，nginx服務器接收到以後，按照必定的規則分發給了後端的業務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的，可是請求具體由哪臺服務器處理的並不明確了，nginx扮演的就是一個反向代理角色。

nginx支持的負載均衡調度算法方式以下：

weight輪詢（默認）：接收到的請求按照順序逐一分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。這種方式下，能夠給不一樣的後端服務器設置一個權重值（weight），用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。

ip_hash：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。

fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊

url_hash：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意nginx默認不支持這種調度算法，要使用的話須要安裝nginx的hash軟件包。（摘自：原文：https://blog.csdn.net/tsummerb/article/details/79248015 ）

分佈式配置管理：Spring Cloud Config

是Spring Cloud團隊建立的一個全新的項目，該項目主要用來爲分佈式系統中的外部配置提供服務器和客戶端支持。

服務器端(Config Server)：也被稱之爲分佈式配置中心，它是一個獨立的微服務應用，主要用於集中管理應用程序各個環境下的配置，默認使用git存儲配置文件內容，也可使用svn、本地文件存儲。

客戶端(Config Client):是Config Server的客戶端，即微服務架構中的各個微服務應用。它們經過指定的配置中心(Config Server)來管理應用資源以及與業務相關的配置內容，並在啓動時從配置中心獲取和加載配置信息。

用戶會先將配置文件推送到Git或SVN中，而後在微服務應用(Config Client)啓動時，會從配置中心(Config Server)中獲取配置信息，而配置中心會根據配置從從Git或SVN中獲取相應的配置信息。

配置的資源文件按照以下格式命名：

/{application}/{profile}[/{lable}]

/{application}-{profile}.yml

/{lable}/{application}-{profile}.yml

/{application}-{profile}.properties

/{lable}/{application}-{profile}.properties 其中application表示應用名稱，profile表示變化的文件，而lable是可選的，表示Git的分支，默認是master

pom.xml文件添加config的server依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

application.yml配置文件以下

spring:
  application:
   name: microservice-config-server #服務名
  profiles:
   active: native # 使用本地文件系統的存儲方式來保存配置信息，通常來講使用git
 server:
  port: 8080

新建三個分別用於表示開發、預發佈和測試的資源配置文件

·application-dev.yml中編寫內容：clientParam: native-dev-1.0

·application-prod.yml中編寫內容：clientParam: native-prod-1.0

·application-test.yml中編寫內容：clientParam: native-test-1.0 其中 dev、 prod、test是表示可變化的文件profile（以後會用到）

在啓動類上新增一個@EnableConfigServer註解來開啓服務端功能、而後啓動工程，在地址欄中輸入localhost:8080/microservice-config-server/dev，其中地址中的dev會找到application-dev.yml文件，顯示出應用名microservice-config-server、環境名dev，以及資源文件路徑等等信息。也能夠直接訪問資源文件localhost:8080/application-dev.yml顯示其中的信息。

而後建立客戶端工程：

在客戶端工程的pom.xml文件中新增兩條依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

編寫bootstrap.yml文件，在其中配置應用名稱、服務中心地址、須要訪問的文件和端口號信息。這個配置文件的名稱必須爲bootstrap.yml或bootstrap.properties，只有這樣配置中心纔可以正常加載，bootstrap.yml或bootstrap.properties必需要優先加載。

spring:
  application:
   name: microservice-config-client
  cloud:
   config:
    profile: prod # 配置服務中的{profile}
    uri: http://localhost:8080/ # 配置中心的地址
 server:
  port: 8081

建立啓動類，在啓動類上加上@RestController註解，而後啓動工程，在瀏覽器中輸入localhost:8081/clientParam

@SpringBootApplication
@RestController
public class Application {
  @Value("${clientParam}")
  private String clientParam;
  @RequestMapping("/clientParam")
  public String getParam(){
     return this.clientParam;
   }
 @RequestMapping("/hello")
 public String hello(){
  return "hello world";
  }
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

會將application-prod.yml中的內容native-prod-1.0顯示出來

工做中咱們通常採用的是git配置倉庫

（1）在Git上建立microservice-study-config目錄，並在目錄中增長開發、預發佈和測試的配置文件，分別編輯三個文件中的內容以下：

·application-dev.yml中編寫內容：clientParam: git-dev-1.0

·application-prod.yml中編寫內容：clientParam: git-prod-1.0

·application-test.yml中編寫內容：clientParam: git-test-1.0

（2）修改服務端配置文件。將microservice-config-server工程的配置文件中本地文件存儲方式的配置刪除（或註釋），並添加git的配置信息

spring:
  application:
   name: microservice-config-server
  cloud:
   config:
    server:
     git: # 使用git的方式
     uri: https://github.com/993640191/microservice-study-config.git
 server:
  port: 8080

修改客戶端配置文件。在microservice-config-client工程的配置文件中添加屬性label，並將其屬性值設置爲master（label屬性表示Git中的分支，其屬性默認值爲master）

啓動工程，測試應用。分別啓動Spring Cloud Config的服務端和客戶端工程，經過訪問地址http://localhost:8081/clientParam，發現已經能夠獲取Git中的配置信息了

流程：首先經過localhost:8081訪問Spring cloud config客戶端，而後根據客戶端配置文件bootstrap.yml中的uri: http://localhost:8080/找到配置中心(服務端)，由於配置中心的server.port是8080。而後根據Spring cloud config服務端的配置文件application.yml中配置的uri，uri: https://github.com/993640191/microservice-study-config.git 去該git地址中找。根據地址欄的clientParam這一路由找到啓動類中對應的方法。而後根據客戶端配置文件bootstrap.yml中的 profile: prod 這一條件找到git中的application-prod.yml文件，並獲取到了咱們在這個文件中定義的clientParam屬性對應的值。