【轉載請注明出處】: https://www.jianshu.com/p/8b11636024d9
Consul 介紹
Consul 是 HashiCorp 公司推出的開源工具,用于實作分布式系統的服務發現與配置。與其它分布式服務注冊與發現的方案,Consul 的方案更“一站式”,内置了服務注冊與發現框 架、分布一緻性協定實作、健康檢查、Key/Value 存儲、多資料中心方案,不再需要依賴其它工具(比如 ZooKeeper 等)。使用起來也較 為簡單。Consul 使用 Go 語言編寫,是以具有天然可移植性(支援Linux、windows和Mac OS X);安裝包僅包含一個可執行檔案,友善部署,與 Docker 等輕量級容器可無縫配合。
Consul 的優勢:
使用 Raft 算法來保證一緻性, 比複雜的 Paxos 算法更直接. 相比較而言, zookeeper 采用的是 Paxos, 而 etcd 使用的則是 Raft。
支援多資料中心,内外網的服務采用不同的端口進行監聽。 多資料中心叢集可以避免單資料中心的單點故障,而其部署則需要考慮網絡延遲, 分片等情況等。 zookeeper 和 etcd 均不提供多資料中心功能的支援。
支援健康檢查。 etcd 不提供此功能。
支援 http 和 dns 協定接口。 zookeeper 的內建較為複雜, etcd 隻支援 http 協定。
官方提供 web 管理界面, etcd 無此功能。
綜合比較, Consul 作為服務注冊和配置管理的新星, 比較值得關注和研究。
特性:
- 服務發現
- 健康檢查
- Key/Value 存儲
- 多資料中心
Consul 角色
- client: 用戶端, 無狀态, 将 HTTP 和 DNS 接口請求轉發給區域網路内的服務端叢集。
-
server: 服務端, 儲存配置資訊, 高可用叢集, 在區域網路内與本地用戶端通訊, 通過廣域網與其它資料中心通訊。 每個資料中心的 server 數量推薦為 3 個或是 5 個。
Consul 用戶端、服務端還支援誇中心的使用,更加提高了它的高可用性。
Consul 工作原理:
- 1、當 Producer 啟動的時候,會向 Consul 發送一個 post 請求,告訴 Consul 自己的 IP 和 Port
- 2、Consul 接收到 Producer 的注冊後,每隔10s(預設)會向 Producer 發送一個健康檢查的請求,檢驗Producer是否健康
- 3、當 Consumer 發送 GET 方式請求 /api/address 到 Producer 時,會先從 Consul 中拿到一個存儲服務 IP 和 Port 的臨時表,從表中拿到 Producer 的 IP 和 Port 後再發送 GET 方式請求 /api/address
-
4、該臨時表每隔10s會更新,隻包含有通過了健康檢查的 Producer
Spring Cloud Consul 項目是針對 Consul 的服務治理實作。Consul 是一個分布式高可用的系統,它包含多個元件,但是作為一個整體,在微服務架構中為我們的基礎設施提供服務發現和服務配置的工具。
Consul VS Eureka
Eureka 是一個服務發現工具。該體系結構主要是用戶端/伺服器,每個資料中心有一組 Eureka 伺服器,通常每個可用區域一個。通常 Eureka 的客戶使用嵌入式 SDK 來注冊和發現服務。對于非本地內建的客戶,官方提供的 Eureka 一些 REST 操作 API,其它語言可以使用這些 API 來實作對 Eureka Server 的操作進而實作一個非 jvm 語言的 Eureka Client。
Eureka 提供了一個弱一緻的服務視圖,盡可能的提供服務可用性。當用戶端向伺服器注冊時,該伺服器将嘗試複制到其它伺服器,但不提供保證複制完成。服務注冊的生存時間(TTL)較短,要求用戶端對伺服器心跳檢測。不健康的服務或節點停止心跳,導緻它們逾時并從系統資料庫中删除。服務發現可以路由到注冊的任何服務,由于心跳檢測機制有時間間隔,可能會導緻部分服務不可用。這個簡化的模型允許簡單的群集管理和高可擴充性。
Consul 提供了一些列特性,包括更豐富的健康檢查,鍵值對存儲以及多資料中心。Consul 需要每個資料中心都有一套服務,以及每個用戶端的 agent,類似于使用像 Ribbon 這樣的服務。Consul agent 允許大多數應用程式成為 Consul 不知情者,通過配置檔案執行服務注冊并通過 DNS 或負載平衡器 sidecars 發現。
Consul 提供強大的一緻性保證,因為伺服器使用 Raft 協定複制狀态 。Consul 支援豐富的健康檢查,包括 TCP,HTTP,Nagios / Sensu 相容腳本或基于 Eureka 的 TTL。用戶端節點參與基于 Gossip 協定的健康檢查,該檢查分發健康檢查工作,而不像集中式心跳檢測那樣成為可擴充性挑戰。發現請求被路由到選舉出來的 leader,這使他們預設情況下強一緻性。允許用戶端過時讀取取使任何伺服器處理他們的請求,進而實作像 Eureka 這樣的線性可伸縮性。
Consul 強烈的一緻性意味着它可以作為上司選舉和叢集協調的鎖定服務。Eureka 不提供類似的保證,并且通常需要為需要執行協調或具有更強一緻性需求的服務運作 ZooKeeper。
Consul 提供了支援面向服務的體系結構所需的一系列功能。這包括服務發現,還包括豐富的運作狀況檢查,鎖定,密鑰/值,多資料中心聯合,事件系統和 ACL。Consul 和 consul-template 和 envconsul 等工具生态系統都試圖盡量減少內建所需的應用程式更改,以避免需要通過 SDK 進行本地內建。Eureka 是一個更大的 Netflix OSS 套件的一部分,該套件預計應用程式相對均勻且緊密內建。是以 Eureka 隻解決了一小部分問題,可以和 ZooKeeper 等其它工具可以一起使用。
Consul 強一緻性(C)帶來的是:
服務注冊相比 Eureka 會稍慢一些。因為 Consul 的 raft 協定要求必須過半數的節點都寫入成功才認為注冊成功 Leader 挂掉時,重新選舉期間整個 Consul 不可用。保證了強一緻性但犧牲了可用性。
Eureka 保證高可用(A)和最終一緻性:
服務注冊相對要快,因為不需要等注冊資訊 replicate 到其它節點,也不保證注冊資訊是否 replicate 成功 當資料出現不一緻時,雖然 A, B 上的注冊資訊不完全相同,但每個 Eureka 節點依然能夠正常對外提供服務,這會出現查詢服務資訊時如果請求 A 查不到,但請求 B 就能查到。如此保證了可用性但犧牲了一緻性。
其它方面,eureka 就是個 servlet 程式,跑在 servlet 容器中; Consul 則是 go 編寫而成。
Consul 服務端
接下來我們開發 Consul 的服務端,我們建立一個 spring-cloud-consul-producer 項目
添加依賴包
依賴包如下:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
spring-boot-starter-actuator
健康檢查依賴于此包。
spring-cloud-starter-consul-discovery
Spring Cloud Consul 的支援。
配置檔案
配置檔案内容如下
spring.application.name=spring-cloud-consul-producer
server.port=8501
spring.cloud.consul.host=localhost
spring.cloud.consul.port=8500
#注冊到consul的服務名稱
spring.cloud.consul.discovery.serviceName=service-producer
Consul 的位址和端口号預設是 localhost:8500 ,如果不是這個位址可以自行配置。 spring.cloud.consul.discovery.serviceName 是指注冊到 Consul 的服務名稱,後期用戶端會根據這個名稱來進行服務調用。
啟動類
@SpringBootApplication
@EnableDiscoveryClient
public class ConsulProducerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsulProducerApplication.class, args);
}
}
添加了
@EnableDiscoveryClient
注解表示支援服務發現。
提供服務
我們在建立一個 Controller,推文提供 hello 的服務。
@RestController
public class HelloController {
@RequestMapping("/hello")
public String hello() {
return "hello consul";
}
}
為了模拟注冊均衡負載複制一份上面的項目重命名為 spring-cloud-consul-producer-2 ,修改對應的端口為 8502,修改 hello 方法的傳回值為:”helle consul two”,修改完成後依次啟動兩個項目。這時候去consul ui看應該會有兩個服務已經注冊上了,這樣服務提供者就準備好了。
Consul 消費端
我們建立一個 spring-cloud-consul-consumer 項目,pom 檔案和上面示例保持一緻。
spring.application.name=spring-cloud-consul-consumer
server.port=8503
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
#設定不需要注冊到 consul 中
spring.cloud.consul.discovery.register=false
用戶端可以設定注冊到 Consul 中,也可以不注冊到 Consul 注冊中心中,根據我們的業務來選擇,隻需要在使用服務時通過 Consul 對外提供的接口擷取服務資訊即可。
@SpringBootApplication
public class ConsulConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsulConsumerApplication.class, args);
}
}
進行測試
我們先來建立一個 ServiceController ,試試如果去擷取 Consul 中的服務。
@RestController
public class ServiceController {
@Autowired
private LoadBalancerClient loadBalancer;
@Autowired
private DiscoveryClient discoveryClient;
/**
* 擷取所有服務
*/
@RequestMapping("/services")
public Object services() {
return discoveryClient.getInstances("service-producer");
}
/**
* 從所有服務中選擇一個服務(輪詢)
*/
@RequestMapping("/discover")
public Object discover() {
return loadBalancer.choose("service-producer").getUri().toString();
}
}
Controller 中有倆個方法,一個是擷取所有服務名為service-producer的服務資訊并傳回到頁面,一個是随機從服務名為service-producer的服務中擷取一個并傳回到頁面。
添加完 ServiceController 之後我們啟動項目,通路位址:
http://localhost:8503/services
,傳回:
[{"serviceId":"service-producer","host":"127.0.0.1","port":8501,"secure":false,"metadata":{"secure":"false"},"uri":"http://127.0.0.1:8501","scheme":null},{"serviceId":"service-producer","host":"127.0.0.1","port":8502,"secure":false,"metadata":{"secure":"false"},"uri":"http://127.0.0.1:8502","scheme":null}]
發現我們剛才建立的端口為 8501 和 8502 的兩個服務端都存在。
多次通路位址:
http://localhost:8503/discover
,頁面會交替傳回下面資訊:
http://127.0.0.1:8501
http://127.0.0.1:8502
...
說明 8501 和 8501 的兩個服務會交替出現,進而實作了擷取服務端位址的均衡負載。
大多數情況下我們希望使用均衡負載的形式去擷取服務端提供的服務,是以使用第二種方法來模拟調用服務端提供的 hello 方法。
建立 CallHelloController :
@RestController
public class CallHelloController {
@Autowired
private LoadBalancerClient loadBalancer;
@RequestMapping("/call")
public String call() {
ServiceInstance serviceInstance = loadBalancer.choose("service-producer");
System.out.println("服務位址:" + serviceInstance.getUri());
System.out.println("服務名稱:" + serviceInstance.getServiceId());
String callServiceResult = new RestTemplate().getForObject(serviceInstance.getUri().toString() + "/hello", String.class);
System.out.println(callServiceResult);
return callServiceResult;
}
}
使用 RestTemplate 進行遠端調用。添加完之後重新開機 spring-cloud-consul-consumer 項目。在浏覽器中通路位址:
http://localhost:8503/call
,依次傳回結果如下:
helle consul
helle consul two
...
說明我們已經成功的調用了 Consul 服務端提供的服務,并且實作了服務端的均衡負載功能。