一、概述

1、服務治理:SpringCloud封裝了NetFlix公司開發的Eureka模塊來實現服務治理。在傳統的RPC框架中,管理每個服務與服務之間依賴關系比較復雜,管理比較復雜,所以需要使用服務治理,管理服務與服務之間的依賴關系,可以實現服務調用、負載均衡、容錯等,實現服務的發現與注冊。
2、服務注冊與發現:
(1)在服務注冊與發現中,有一個注冊中心,當服務器啟動的時候,會把當前自己的服務器的信息(比如服務地址、通訊地址等)以別名的方式注冊到注冊中心上。另一方(消費者|服務提供者)以該別名的方式去注冊中心上獲取到實際的通訊地址,然后再實現本地RPC調用RPC遠程框架。核心設計思想在於注冊中心,因為注冊中心管理每個服務與服務之間的依賴關系(服務治理)。在任何RPC遠程框架中,都會有一個注冊中心(存放服務地址相關信息,接口地址等)。Eureka與Dubbo的架構對比如下:

(2)Eureka采用C/S的設計架構,EurekaServer作為服務注冊功能的服務器,它是服務注冊中心,而系統中的其他微服務,使用Eureka客戶端連接到Eureka Server並維持心跳。這樣系統的維護人員就可以通過Eureka Server來監控系統中各個微服務是否正常運行。
(3)Zookeeper則采用臨時節點的方式,臨時節點的聲明周期和客戶端綁定,一旦客戶端會話失效,那么這個客戶端創建的所有的節點都會被移除,也是服務注冊的原理所在。
(4) Consul服務注冊與發現原理:基於Raft協議,犧牲高可用性來保證數據強一致性,Leader/Follower模式,參考:https://blog.csdn.net/u013982921/article/details/93622716
二、Eureka服務注冊與發現
1、Eureka組件
包含2個組件:Eureka Server和Eureka Client
Eureka Server:提供服務注冊。各個微服務節點通過配置啟動后,會在Eureka中進行注冊,這樣Eureka Server的服務注冊表中將會存儲所有可用服務節點的信息,服務節點的信息可以在界面直觀看到。
Eureka Client:通過注冊中心訪問。是一個Java客戶端,用於簡化Eureka Client的交互,客戶端同時也具備一個內置的、使用輪詢(round-ribbon)負載算法的負載均衡器。在應用啟動后,將會向EurekaServer發送心跳(默認周期為30s)。如果Eureka Server在多個心跳周期內沒有接受到某個節點的心跳,Eureka Server將會從服務注冊表中將這個服務點移除(默認90s)。
2、Eureka集群原理

微服務RPC遠程過程調用最核心的是:高可用
3、EurekaServer端搭建
注意:EurekaServer端應該避免單點故障
參考之前搭建的Eureka高可用集群:SpringCloud全家桶學習之服務注冊與發現及Eureka高可用集群搭建(二)
啟動2個Eureka互相注冊為中心,查看服務注冊中心已注冊服務如下:

4、服務發現
相關注解:主類添加@EnableDiscoveryClient,對於注冊進Eureka里面的微服務,可以通過服務發現來獲得該服務的信息。使用方式很簡單注解注入DiscoveryClient使用

5、Eureka的自我保護機制
保護模式主要用於一組客戶端和Eureka Server之間存在網絡分區場景下的保護。一旦進入保護模式,Eureka Server將會嘗試保護其服務注冊表中的信息,不再刪除服務注冊表中的數據,也就是不會注銷任何微服務。如果在Eureka Server的首頁看到以下提示,則說明Eureka進入了保護模式:

總結一句話:某時刻某一個微服務不可用了,Eureka不會立刻清理,依舊會對該微服務的信息進行保存,屬於CAP里面的AP分支。
為什么會產生自我保護機制?為了防止EurekaClient可以正常運行,但是與EurekaServer網絡不通的情況下,EurekaServer不會立刻將EurekaClient服務剔除。
自我保護模式:默認情況下,如果EurekaServer在一定時間內沒有接收到某個服務實例的心跳,EurekaServer將會注銷該實例(默認時間為90s)。但是當網絡分區故障發生(延遲、卡頓、擁擠時),微服務與EurekaServer之間無法正常通信,以上行為就變得非常危險了----因為微服務本身其實是健康的,此時本不應該注銷這個微服務。Eureka通過“自我保護機制”來解決這個問題-----當EurekaServer節點在短時間內丟失過多客戶端時(可能發生了網絡分區故障),那么節點就會進入自我保護模式。

綜上,自我保護模式是一種應對網絡異常的安全保護措施。它的架構哲學是寧可同時保留所有微服務(健康的微服務和不健康的微服務都會保留)也不盲目注銷任何異常的微服務。使用自我保護模式,可以讓Eureka集群更加的健壯、穩定。
禁用自我保護機制:
①EurekaServer:修改eureka.server.enable-self-preservation=true(默認為true)改為false;eureka.server.eviction-interval-timer-in-ms=2000(表示2s沒接收到心跳則剔除微服務)
②EurekaClient:eureka.client.lease-renewal-interval-in-seconds=30(客戶端發送心跳間隔,默認30s),eureka.client.lease-expiration-duration-in-seconds=90(Eureka服務端在收到最后一次心跳后等待時間上限,默認90s,超時將剔除微服務)
6、Eureka停更
Github地址:https://github.com/Netflix/eureka/wiki,Eureka已停更,但不停用。
三、Zookeeper服務注冊與發現
雖然Eureka已停更,現SpringCloud也支持Zookeeper作為注冊中心,使用起來也比較簡單,下面就操練一把
1、配置文件修改並添加注解@EnableDiscoveryClient
#消費端 server: port: 80 spring: application: # 服務別名 name: cloud-consumer-order cloud: zookeeper: # 注冊到zookeeper地址 connect-string: localhost:2181 #提供端 server: # 8004表示注冊到zookeeper服務器的支付服務提供者端口號 port: 8004 spring: application: # 服務別名---注冊zookeeper到注冊中心的名稱 name: cloud-provider-payment cloud: zookeeper: # 默認localhost:2181 connect-string: localhost:2181
2、Zookeeper服務端查看節點
如下所示,該服務注冊進Zookeeper臨時節點的信息

四、Consul服務注冊與發現
官方地址:https://www.consul.io/intro/index.html(Go語言編寫)
Consul是一套開源的分布式服務發現和配置管理系統,由HashCorp公司用Go語言開發。提供了微服務系統中的服務治理、配置中心、控制總線等功能。這些功能中的每一個都可以根據需求單獨使用,也可以一起使用構建全方位的服務網絡,總之Consul提供了一種完整的服務網絡解決方案。
下載地址:https://www.consul.io/downloads.html
安裝參考:https://learn.hashicorp.com/consul/getting-started/install
中文文檔:https://www.springcloud.cc/spring-cloud-consul.html
1、進入Consul Web界面
開發模式啟動:consul agent -dev,瀏覽器訪問:http://localhost:8500/即可進入Consul界面

2、消費者與提供者分別配置Consul
主啟動類分別添加@EnableDiscoveryClient
#消費者 server: port: 80 spring: application: name: cloud-consumer-order cloud: consul: # consul注冊中心地址 host: localhost port: 8500 discovery: hostname: 127.0.0.1 service-name: ${spring.application.name} #提供者 server: # consul服務端口 port: 8006 spring: application: name: cloud-provider-payment cloud: consul: # consul注冊中心地址 host: localhost port: 8500 discovery: hostname: 127.0.0.1 service-name: ${spring.application.name}
3、Consul Web查看微服務

五、Eureka、Zookeeper與Consul異同點

(1)AP架構(例Eureka)
當網絡分區出現后,為了保證可用性,系統B可以返回舊值,保證系統的可用性。
結論:違背了一致性C的要求,只滿足可用性和分區容錯即AP

(2)CP架構
當網路分區出現后,為了保證一致性,就必須拒絕請求,否則無法保證一致性。
結論:違背了可用性A的要求,只滿足一致性和分區容錯即CP
六、CAP簡介
理論:C代表強一致性、A代表可用性、P代表分區容錯性。由於是分布式系統,所以P必須滿足,要么AP、要么CP。

CAP核心:一個分布式系統不可能同時很好的滿足一致性,可用性和分區容錯性這三個需求,因此,根據CAP原理將NoSQL數據庫分成了滿足CA原則、滿足C原則和滿足AP原則:
(1)CA:單點集群,滿足一致性、可用性,通常在擴展性上不太強大
(2)CP:滿足一致性、分區容錯性,通常性能不是特別高
(3)AP:滿足可用性、分區容錯性,通常對一致性要求低一些
