Spring Cloud 之 Eureka.

一、微服務概述

1. 什麼是微服務

簡單地說，微服務是系統架構上的一種設計風格，它的主旨是将一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的程序中運作，服務之間基于 RPC 進行通信協作。被拆分成的每一個小型服務都圍繞着系統中的某一項或一些耦合度較高的業務功能進行建構，并且每個服務都維護着自身的資料存儲（劃重點，每個微服務都有自己的資料庫執行個體）、業務開發、自動化測試案例以及獨立部署機制。

2. 微服務的特性

服務元件化 ：一個獨立的系統拆成多個小型服務。
以業務劃分服務 ：微服務應該以業務來劃分，而不是按能力或其他因素來劃分（比如之前做的一個項目直接将緩存能力建成了一個微服務元件）。
智能端點和啞管道
：服務之間通過 RPC 的方式調用，通常會使用以下兩種服務調用方式：

第一種：使用 HTTP 的 RESTfl API 或輕量級的消息發送協定，實作資訊傳遞與服務調用的觸發。

第二種：通過在輕量級消息總線上傳遞消息，類似 RabbitMQ 等一些提供可靠異步交換的中間件。
去中心化處理 ：不同的微服務元件可以選擇不同的技術方案，甚至可以選擇不同的語言。隻有實作了對技術平台的透明，才能更好地發揮不同語言對不同業務處理能力的優勢，進而打造更為強大的大型系統。
去中心化管理資料 ：采用分布式資料庫，不同的微服務元件有着自己單獨的資料庫執行個體。雖然資料管理的去中心化可以讓資料管理更加細緻化，通過采用更合适的技術可讓資料存儲和性能達到最優。但是，由于資料存儲于不同的資料庫執行個體中後，資料一緻性也成為微服務架構中亟待解決的問題之一。
基礎設施自動化 ：自動化測試（每次部署前的強心劑，盡可能地獲得對正在運作的軟體的信心）、自動化部署（解放煩瑣枯燥的重複操作以及對多環境的配置管理）等。
容錯設計 ：在微服務架構中，快速檢測出故障源并盡可能自動恢複服務是必須被設計和考慮的。
演進式設計 ：沒有必要一開始就把服務拆分的又細又多，可以随着業務系統的發展，把壓力大的服務或者穩定不變化的子產品做拆分合并動作。

2. 微服務的缺陷

運維的成本提高。這個是不可避免的，原來隻需要運維一個單一獨立的系統，現在要管理幾個或者幾十個微服務。
接口的一緻性問題。A 微服務修改了接口，需要調用方B、C 服務同時做出修改。除非開發過程中嚴格遵守開閉原則（在這個靈活流式開發的背景下，幾乎很難做到）。
分布式的複雜性。網絡延遲、分布式事務、異步消息等。

tips

：分布式事務本身的實作難度就非常大，是以在微服務架構中，我們更強調在各服務之間進行 “ 無事務 ” 的調用，而對于資料一緻性，隻要求資料在最後的處理狀态是一緻的即可；若在過程中發現錯誤，通過補償機制來進行處理，使得錯誤資料能夠達到最終的一緻性。

二、Spring Cloud 簡介

Spring Cloud 是一個基于Spring Boot實作的微服務架構開發工具。它為微服務架構中涉及的配置管理、服務治理、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和叢集狀态管理等操作提供了一種簡單的開發方式。

Spring Cloud 的出現，可以說是對微服務架構的巨大支援和強有力的技術後盾。它是一個解決微服務架構實施的綜合性解決架構，它整合了諸多被廣泛實踐和證明過的架構作為實施的基礎部件，又在該體系基礎上建立了一些非常優秀的邊緣元件。舉個 Dubbo 和 Spring Cloud 差異性的例子：在使用 Dubbo 開發過程中，分布式配置中心（百度的 Disconf、Netflix的Archaius、360的QConf、淘寶的 Diamond 等）、連結跟蹤（京東的 Hydra、Twitter的 Zipkin 等）...一系列需要的元件，我都要去找第三方進行內建，還要考慮版本相容的問題。而 Spring Cloud 就是一個微服務解決方案的“全家桶”，幾乎我需要的全部微服務元件，我都能在其中找到“原裝元件”：分布式配置中心（Config）、連結跟蹤（Sleuth）、批量任務（Task），而且可以完美相容。

三、Eureka 簡介

服務治理體系可以說是微服務架構中最為核心和基礎的子產品，它主要用來實作各個微服務執行個體的自動化注冊與發現。服務治理體系中的三個核心角色：服務注冊中心、服務提供者以及服務消費者。而 Eureka Server 就承擔了 Spring Cloud 的服務注冊中心。接下來捋一捋 Eureka Server 進行服務治理的過程：

服務注冊 ：”服務提供者”在啟動的時候會通過發送 REST 請求的方式将自己注冊到 Eureka Server 上，同時帶上了自身服務的一些中繼資料資訊（hostName 之類的）。Eureka Server 接收到這個 REST 請求之後，将中繼資料資訊存儲在一個雙層結構Map中，其中第一層的key是服務名，第二層的key是具體服務的執行個體名。
服務同步 ：由于服務注冊中心之間互相注冊為服務（Eureka Server 高可用場景），當服務提供者發送注冊請求到一個服務注冊中心時，它會将該請求轉發給叢集中相連的其他注冊中心，進而實作注冊中心之間的服務同步。通過服務同步，兩個服務提供者的服務資訊就可以通過這兩台服務注冊中心中的任意一台擷取到。
服務續約 ：在注冊完服務之後，“服務提供者”會維護一個心跳用來持續告訴 Eureka Sever "我還活着 ”，以防止Eureka Server 的 “ 剔除任務 ” 将該服務執行個體從服務清單中排除出去。
服務消費 ：當我們啟動“服務消費者”的時候，它會發送一個 REST 請求給服務注冊中心，來擷取上面注冊的服務清單。為了性能考慮， Eureka Serer會維護一份隻讀的服務清單來傳回給用戶端，同時該緩存清單會每隔30秒更新一次。
服務調用 ：“服務消費者”在擷取服務清單後，通過服務名可以獲得具體提供服務的執行個體名和該執行個體的中繼資料資訊。因為有這些服務執行個體的詳細資訊，是以用戶端可以根據自己的需要決定具體調用哪個執行個體，在 Ribbon 中會預設采用輪詢的方式進行調用，進而實作用戶端的負載均衡。
服務下線 ：服務執行個體進行正常的關閉操作時，它會觸發一個服務下線的 REST 請求給 Eureka Server，告訴服務注冊中心：“我要下線了 ”。服務端在接收到請求之後，将該服務狀态置為下線(DOWN), 并把該下線事件傳播出去。
失效剔除 ：有些時候，我們的服務執行個體并不一定會正常下線，可能由于記憶體溢出、網絡故障等原因使得服務不能正常工作，而服務注冊中心并未收到 “服務下線 ” 的請求。為了從服務清單中将這些無法提供服務的執行個體剔除，Eureka Server 在啟動的時候會建立一個定時任務，預設每隔一段時間（預設為60秒）将目前清單中逾時（預設為90秒）沒有續約的服務剔除出去。
自我保護 ：Eureka Server在運作期間，會統計心跳失敗的比例在15分鐘之内是否低于85%, 如果出現低于的情況（在單機調試的時候很容易滿足，實際在生産環境上通常是由于網絡不穩定導緻），Eureka Server 會将目前的執行個體注冊資訊保護起來，讓這些執行個體不會過期，盡可能保護這些注冊資訊。

：Spring Cloud Eureka實作的服務治理機制強調了CAP原理中的AP, 即可用性與分區容錯性，它與Zoo Keeper這類強調CP( 一緻性、分區容錯性）的服務治理架構最大的差別就是，Eureka為了實作更高的服務可用性，犧牲了一定的一緻性，在極端情況下它甯願接受故障執行個體也不要丢掉“健康”執行個體，比如，當服務注冊中心的網絡發生故障斷開時，由于所有的服務執行個體無法維持續約心跳，在強調 AP的服務治理中将會把所有服務執行個體都剔除掉，而 Eureka 則會因為超過 85% 的執行個體丢失心跳而會觸發保護機制，注冊中心将會保留此時的所有節點，以實作服務間依然可以進行互相調用的場景，即使其中有部分故障節點，但這樣做可以繼續保障大多數的服務正常消費。

四、Eureka 實戰

SpringBoot 版本号：2.1.6.RELEASE

SpringCloud 版本号：Greenwich.RELEASE

1. 服務注冊中心

pom.xml

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
            <version>2.1.0.RELEASE</version>
        </dependency>

application.yml

server:
  port: 1111

eureka:
  instance:
    hostname: localhost
    prefer-ip-address: true
  client:
    # 表示不向注冊中心注冊自己
    register-with-eureka: false
    # 注冊中心的職責是維護執行個體，不需要去檢索服務
    fetch-registry: false
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
   server:
     # 是否要打開自我保護機制
     enable-self-preservation: true

eureka 的配置項主要有三項：instance、client、server。“instance”維護該服務的執行個體資訊，包括 hostname、port 這類描述執行個體特征的中繼資料資訊；“client”主要是服務注冊資料的配置，比如逾時時間、服務緩存時間等；“server”是服務注冊中心特有的配置，配置 Eureka Server 的相關配置項，比如上面的是否打開自我保護。

Application.java

//啟動一個服務注冊中心
@EnableEurekaServer
@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

至此，我們一個Eureka Server — 服務注冊中心就搭建好了。

2. 服務提供者

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

server:
  port: 2222

spring:
  application:
    name: cloud-eureka-client

eureka:
  # 服務注冊相關的配置資訊
  client:
    service-url:
      defaultZone: http://localhost:1111/eureka/
  instance:
    # 是否優先使用IP位址作為主機名的辨別
    prefer-ip-address: true

就這樣，我們的一個 Eureka Client 算是注冊到 Eureka Server 上了。接下來，讓我們試試用 DiscoveryClient 發現我們的服務資訊：

// 自動化配置， 建立 DiscoveryClient 接口針對 Eureka 用戶端的 EurekaDiscoveryClient 執行個體
@EnableDiscoveryClient
@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application .class, args);
    }
}

@RestController
public class HelloController {

    private final Logger logger = LoggerFactory.getLogger(getClass());

    @Autowired
    private DiscoveryClient discoveryClient;
    @Value("${spring.application.name}")
    private String serviceId;

    @RequestMapping(value = "/hello", method = RequestMethod.GET)
    public String index() {
        List<ServiceInstance> instances = discoveryClient.getInstances(serviceId);
        ServiceInstance instance = instances.get(0);
        logger.info("/hello, host:" + instance.getHost() + ", serviceId:" + instance.getServiceId());
        return "Hello World";
    }
}

3. 服務消費者

有了服務注冊中心和服務提供者，我們還差一個服務消費者，服務消費者需要依賴 Spring Cloud Ribbon。

Spring Cloud Ribbon 是一個基于 HTTP 和 TCP 的用戶端負載均衡工具，它基于 Netflix Ribbon 實作。通過 Spring Cloud 的封裝，可以讓我們輕松地将面向服務的 REST 模闆請求自動轉換成用戶端負載均衡的服務調用。Spring Cloud Ribbon 雖然隻是一個工具類架構，它不像服務注冊中心、配置中心、API 網關那樣需要獨立部署，但是它幾乎存在于每一個 Spring Cloud 建構的微服務和基礎設施中。因為微服務間的調用，API 網關的請求轉發等内容實際上都是通過 Ribbon 來實作的。

Ribbon 中内置了多種負載均衡政策，包括 RoundRobinRule 輪詢政策、RandomRule 随機政策、BestAvailableRule 最大可用政策、WeightedResponseTimeRule 帶有權重的輪詢政策等。

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

@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }


    @LoadBalanced
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

ConsumerController.java

@RestController
public class ConsumerController {

    @Autowired
    private RestTemplate restTemplate;

    @RequestMapping("/ribbon-consumer")
    public String helloConsumer() {
        // 這裡通路的是服務名，而不是一個具體的位址（為了實作負載均衡政策），在服務治理架構中，這是一個非常重要的特性。
        ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
        return result.getBody();
    }
}

接下來我們來捋一捋 Spring Cloud Ribbon 實作用戶端負載均衡的步驟：

首先被 @loadBalanced 注解的 RestTemplate 發起的服務請求會被 LoadBalancerInterceptor 攔截下來。
LoadBalancerInterceptor 把請求重新組織後，帶上 serviceName（服務名）交由 LoadBalancerClient 去處理（在 Eureka 和 Ribbon 的內建中，處理由 RibbonLoadBalancerClient 進行）。
RibbonLoadBalancerClient 根據 serviceName 得到負載均衡政策 ILoadBalancer（預設的是 ZoneAwareLoadBalancer 區域親和政策）。
ILoadBalancer 根據負載均衡規則選取一台伺服器 Server。
有了 Server 資訊以後，正式發起一次請求，具體的請求動作在 AsyncLoadBalancerInterceptor 進行。它先将 restTemplate 中的 serviceName 轉換成 host:port 的形式（這個在 ServiceRequestWrapper 中實作），然後發起一個異步請求。

五、附加

預設情況下，Eureka 使用 Jersey 和 XStream 配合 JSON 作為 Server 與 Client 之間的通信協定。
YAML 的意思其實是： Yet Another Markup Language — 仍是一種标記語言（這個看着有點想笑）。
在 SpringBoot 的屬性配置檔案中，可以通過使用 ${random} 配置來産生随機的 int 值、long 值或者 string 字元串。
在 Spring Boot 中，多環境配置的檔案名需要滿足 application-{profile}.properties的格式，其中{profile}對應你的環境辨別。通過啟動參數 --spring.profiles.active=test 來指定激活的環境變量。
負載均衡：

Spring Cloud 之 Eureka.

Spring Cloud 之 Eureka.

一、微服務概述

1. 什麼是微服務

2. 微服務的特性

2. 微服務的缺陷

二、Spring Cloud 簡介

三、Eureka 簡介

四、Eureka 實戰

1. 服務注冊中心

2. 服務提供者

3. 服務消費者

五、附加

示範源代碼：https://github.com/JMCuixy/spring-cloud-demo

内容參考《Spring Cloud 微服務實戰》

Spring Cloud 之 Eureka.

一、微服務概述

1. 什麼是微服務

2. 微服務的特性

2. 微服務的缺陷

二、Spring Cloud 簡介

三、Eureka 簡介

四、Eureka 實戰

1. 服務注冊中心

2. 服務提供者

3. 服務消費者

五、附加

示範源代碼 ：https://github.com/JMCuixy/spring-cloud-demo

内容參考《Spring Cloud 微服務實戰》

示範源代碼：https://github.com/JMCuixy/spring-cloud-demo