一、微服務概述
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 會將當前的實例注冊信息保護起來， 讓這些實例不會過期， 盡可能保護這些注冊信息。
tips：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. 服務提供者
- pom.xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
- application.yml
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 來實現的。
- pom.xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
- Application.java
@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 來指定激活的環境變量。
- 負載均衡：
