摘自:https://www.cnblogs.com/mrhelloworld/p/eureka.html
服務注冊中心是服務實現服務化管理的核心組件,類似於目錄服務的作用,主要用來存儲服務信息,譬如提供者 url 串、路由信息等。服務注冊中心是微服務架構中最基礎的設施之一。
在微服務架構流行之前,注冊中心就已經開始出現在分布式架構的系統中。Dubbo 是一個在國內比較流行的分布式框架,被大量的中小型互聯網公司所采用,它提供了比較完善的服務治理功能,而服務治理的實現主要依靠的就是注冊中心。
什么是注冊中心
注冊中心可以說是微服務架構中的“通訊錄”,它記錄了服務和服務地址的映射關系。在分布式架構中,服務會注冊到這里,當服務需要調用其它服務時,就到這里找到服務的地址,進行調用。
舉個現實生活中的例子,比如說,我們手機中的通訊錄的兩個使用場景:
當我想給張三打電話時,那我需要在通訊錄中按照名字找到張三,然后就可以找到他的手機號撥打電話。—— 服務發現
李四辦了手機號並把手機號告訴了我,我把李四的號碼存進通訊錄,后續,我就可以從通訊錄找到他。—— 服務注冊
通訊錄 —— ?什么角色(提示:服務注冊中心)
總結:服務注冊中心的作用就是服務的注冊和服務的發現。
常見的注冊中心
- Netflix Eureka
- Alibaba Nacos
- HashiCorp Consul
- Apache ZooKeeper
- CoreOS Etcd
- CNCF CoreDNS
特性 | Eureka | Nacos | Consul | Zookeeper |
---|---|---|---|---|
CAP | AP | CP + AP | CP | CP |
健康檢查 | Client Beat | TCP/HTTP/MYSQL/Client Beat | TCP/HTTP/gRPC/Cmd | Keep Alive |
雪崩保護 | 有 | 有 | 無 | 無 |
自動注銷實例 | 支持 | 支持 | 不支持 | 支持 |
訪問協議 | HTTP | HTTP/DNS | HTTP/DNS | TCP |
監聽支持 | 支持 | 支持 | 支持 | 支持 |
多數據中心 | 支持 | 支持 | 支持 | 不支持 |
跨注冊中心同步 | 不支持 | 支持 | 支持 | 不支持 |
SpringCloud集成 | 支持 | 支持 | 支持 | 支持 |
為什么需要注冊中心
了解了什么是注冊中心,那么我們繼續談談,為什么需要注冊中心。在分布式系統中,我們不僅僅是需要在注冊中心找到服務和服務地址的映射關系這么簡單,我們還需要考慮更多更復雜的問題:
- 服務注冊后,如何被及時發現
- 服務宕機后,如何及時下線
- 服務如何有效的水平擴展
- 服務發現時,如何進行路由
- 服務異常時,如何進行降級
- 注冊中心如何實現自身的高可用
這些問題的解決都依賴於注冊中心。簡單看,注冊中心的功能有點類似於 DNS 服務器或者負載均衡器,而實際上,注冊中心作為微服務的基礎組件,可能要更加復雜,也需要更多的靈活性和時效性。所以我們還需要學習更多 Spring Cloud 微服務組件協同完成應用開發。
注冊中心解決了什么問題
- 服務管理
- 服務的依賴關系管理
什么是 Eureka 注冊中心
Eureka 是 Netflix 開發的服務發現組件,本身是一個基於 REST 的服務。Spring Cloud 將它集成在其子項目 Spring Cloud Netflix 中,實現 Spring Cloud 的服務注冊與發現,同時還提供了負載均衡、故障轉移等能力。
Eureka 注冊中心三種角色
Eureka Server
通過 Register、Get、Renew 等接口提供服務的注冊和發現。
Application Service(Service Provider)
服務提供方,把自身的服務實例注冊到 Eureka Server 中。
Application Client(Service Consumer)
服務調用方,通過 Eureka Server 獲取服務列表,消費服務。
Eureka 入門案例
創建項目
我們創建聚合項目來講解 Eureka,首先創建一個 pom 父工程。
添加依賴
pom.xml
注冊中心 eureka-server
在剛才的父工程下創建 eureka-server
注冊中心的項目。
創建項目
添加依賴
pom.xml
配置文件
application.yml
此時如果直接啟動項目是會報錯的,錯誤信息:com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused: connect
,這是因為 Eureka 默認開啟了將自己注冊至注冊中心和從注冊中心獲取服務注冊信息的配置,如果該應用的角色是注冊中心並是單節點的話,要關閉這兩個配置項。
啟動類
EurekaServerApplication.java
訪問
訪問:http://localhost:8761/
高可用 Eureka 注冊中心
注冊中心 eureka-server
創建項目
在剛才的父工程下再創建一個 eureka-server02
注冊中心的項目,如果是多機器部署不用修改端口,通過 IP 區分服務,如果在一台機器上演示需要修改端口區分服務。
添加依賴
pom.xml
配置文件
集群配置下,注冊中心需要相互注冊實現信息的同步。
eureka-server 的 application.yml
eureka-server02 的 application.yml
啟動類
啟動類不變,啟動兩個 server。
訪問
訪問:http://localhost:8761/ 或者 http://localhost:8762/ 都出現如下圖說明互相注冊成功。
Status
顯示方式為默認值,如果想要清晰可見每個服務的 IP + 端口需要通過以下配置來實現。
顯示 IP + 端口
一個普通的 Netflix Eureka 實例注冊的 ID 等於其主機名(即,每個主機僅提供一項服務)。 Spring Cloud Eureka 提供了合理的默認值,定義如下:spring.cloud.client.hostname:spring.cloud.client.hostname:{spring.application.name}:\({spring.application.instance_id:\){server.port}}},也就是:主機名:應用名:應用端口。
我們也可以可以自定義進行修改:
服務提供者 service-provider
創建項目
在剛才的父工程下創建一個 service-provider
服務提供者的項目。
添加依賴
pom.xml
配置文件
application.yml
實體類
Product.java
編寫服務
ProductService.java
ProductServiceImpl.java
控制層
ProductController.java
該項目我們可以通過單元測試進行測試,也可以直接通過 url 使用 postman 或者瀏覽器來進行測試。
啟動類
ServiceProviderApplication.java
注冊中心
訪問注冊中心,可以看到用戶服務已經注冊至注冊中心。
服務消費者 service-consumer
創建項目
在剛才的父工程下創建一個 service-consumer 服務消費者的項目。
添加依賴
pom.xml
配置文件
application.yml
實體類
Product.java
Order.java
消費服務
OrderService.java
對於服務的消費我們這里講三種實現方式:
- DiscoveryClient:通過元數據獲取服務信息
- LoadBalancerClient:Ribbon 的負載均衡器
- @LoadBalanced:通過注解開啟 Ribbon 的負載均衡器
DiscoveryClient
Spring Boot 不提供任何自動配置的RestTemplate
bean,所以需要在啟動類中注入 RestTemplate
。
OrderServiceImpl.java
LoadBalancerClient
OrderServiceImpl.java
@LoadBalanced
啟動類注入 RestTemplate
時添加 @LoadBalanced
負載均衡注解,表示這個 RestTemplate
在請求時擁有客戶端負載均衡的能力。
OrderServiceImpl.java
控制層
OrderController.java
訪問
訪問:http://localhost:9090/order/1
Eureka 架構原理
- Register(服務注冊):把自己的 IP 和端口注冊給 Eureka。
- Renew(服務續約):發送心跳包,每 30 秒發送一次,告訴 Eureka 自己還活着。如果 90 秒還未發送心跳,宕機。
- Cancel(服務下線):當 Provider 關閉時會向 Eureka 發送消息,把自己從服務列表中刪除。防止 Consumer 調用到不存在的服務。
- Get Registry(獲取服務注冊列表):獲取其他服務列表。
- Replicate(集群中數據同步):Eureka 集群中的數據復制與同步。
- Make Remote Call(遠程調用):完成服務的遠程調用。
CAP 原則
CAP 原則又稱 CAP 定理,指的是在一個分布式系統中具有以下其中兩個特性:
- Consistency (一致性)
- Availability (可用性)
- Partition tolerance(分區容錯性)
CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出。該猜想在提出兩年后被證明成立,成為我們熟知的 CAP 定理。CAP 三者不可兼得。
特性 | 定理 |
---|---|
Consistency | 也叫做數據原子性,系統在執行某項操作后仍然處於一致的狀態。在分布式系統中,更新操作執行成功后所有的用戶都應該讀到最新的值,這樣的系統被認為是具有強一致性的。等同於所有節點訪問同一份最新的數據副本。 |
Availability | 每一個操作總是能夠在一定的時間內返回結果,這里需要注意的是"一定時間內"和"返回結果"。一定時間內指的是,在可以容忍的范圍內返回結果,結果可以是成功或者是失敗。 |
Partition tolerance | 在網絡分區的情況下,被分隔的節點仍能正常對外提供服務(分布式集群,數據被分布存儲在不同的服務器上,無論什么情況,服務器都能正常被訪問)。 |
取舍策略
CAP 三個特性只能滿足其中兩個,那么取舍的策略就共有三種:
- CA without P:如果不要求P(不允許分區),則C(強一致性)和A(可用性)是可以保證的。但放棄 P 的同時也就意味着放棄了系統的擴展性,也就是分布式節點受限,沒辦法部署子節點,這是違背分布式系統設計的初衷的。
- CP without A:如果不要求A(可用),相當於每個請求都需要在服務器之間保持強一致,而P(分區)會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務),一旦發生網絡故障或者消息丟失等情況,就要犧牲用戶的體驗,等待所有數據全部一致了之后再讓用戶訪問系統。設計成 CP 的系統其實不少,最典型的就是分布式數據庫,如 Redis、HBase 等。對於這些分布式數據庫來說,數據的一致性是最基本的要求,因為如果連這個標准都達不到,那么直接采用關系型數據庫就好,沒必要再浪費資源來部署分布式數據庫。
- AP without C:要高可用並允許分區,則需放棄一致性。一旦分區發生,節點之間可能會失去聯系,為了高可用,每個節點只能用本地數據提供服務,而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景,可能前幾秒你瀏覽商品的時候頁面提示是有庫存的,當你選擇完商品准備下單的時候,系統提示你下單失敗,商品已售完。這其實就是先在 A(可用性)方面保證系統可以正常的服務,然后在數據的一致性方面做了些犧牲,雖然多少會影響一些用戶體驗,但也不至於造成用戶購物流程的嚴重阻塞。
總結
現如今,對於多數大型互聯網應用的場景,主機眾多、部署分散,而且現在的集群規模越來越大,節點只會越來越多,所以節點故障、網絡故障是常態,因此分區容錯性也就成為了一個分布式系統必然要面對的問題。那么就只能在 C 和 A 之間進行取舍。但對於傳統的項目就可能有所不同,拿銀行的轉賬系統來說,涉及到金錢的對於數據一致性不能做出一絲的讓步,C 必須保證,出現網絡故障的話,寧可停止服務,可以在 A 和 P 之間做取舍。
總而言之,沒有最好的策略,好的系統應該是根據業務場景來進行架構設計的,只有適合的才是最好的。
Eureka 自我保護
啟動自我保護條件
一般情況下,服務在 Eureka 上注冊后,會每 30 秒發送心跳包,Eureka 通過心跳來判斷服務是否健康,同時會定期刪除超過 90 秒沒有發送心跳的服務。
有兩種情況會導致 Eureka Server 收不到微服務的心跳
- 微服務自身的原因
- 微服務與 Eureka 之間的網絡故障
自我保護模式
Eureka Server 在運行期間會去統計心跳失敗比例在 15 分鍾之內是否低於 85%,如果低於 85%,Eureka Server 會將這些實例保護起來,讓這些實例不會過期,同時提示一個警告。這種算法叫做 Eureka Server 的自我保護模式。
為什么要啟動自我保護
- 因為同時保留"好數據"與"壞數據"總比丟掉任何數據要更好,當網絡故障恢復后,這個 Eureka 節點會退出"自我保護模式"。
- Eureka 還有客戶端緩存功能(也就是微服務的緩存功能)。即使 Eureka 集群中所有節點都宕機失效,微服務的 Provider 和 Consumer 都能正常通信。
- 微服務的負載均衡策略會自動剔除死亡的微服務節點。
如何關閉自我保護
注冊中心配置自我保護
Eureka 優雅停服
配置了優雅停服以后,將不需要 Eureka Server 中配置關閉自我保護。本文使用 actuator 實現。
添加依賴
服務提供者添加 actuator 依賴
配置文件
服務提供者配置度量指標監控與健康檢查
優雅停服
使用 POST 請求訪問:http://localhost:7070/actuator/shutdown 效果如下
Eureka 安全認證
添加依賴
注冊中心添加 security 依賴
配置文件
注冊中心配置安全認證
修改訪問集群節點的 url
注冊中心的配置文件
服務提供者的配置文件
服務消費者的配置文件
過濾 CSRF
Eureka 會自動化配置 CSRF 防御機制,Spring Security 認為 POST, PUT, and DELETE http methods 都是有風險的,如果這些 method 發送過程中沒有帶上 CSRF token 的話,會被直接攔截並返回 403 forbidden。
官方給出了解決的方法,具體可以參考 spring cloud issue 2754,里面有大量的討論,這里提供兩種解決方案。
首先注冊中心配置一個 @EnableWebSecurity
配置類,繼承 org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter
,然后重寫 configure
方法。
方案一
使 CSRF 忽略 /eureka/**
的所有請求
方案二
保持密碼驗證的同時禁用 CSRF 防御機制
訪問
使用配置好的用戶名和密碼登錄以后可看到注冊中心界面,啟動服務提供者和服務消費者,功能正常使用,至此 Eureka 注冊中心所有的知識點就講解結束了。
大家可以通過 分類
查看更多關於 Spring Cloud
的文章。
本文采用 知識共享「署名-非商業性使用-禁止演繹 4.0 國際」許可協議
。
✍️ 本章節到這里就結束了,喜歡的話就點贊 🤗 加轉發吧。
📢 關注 哈嘍沃德先生
,學習更多 IT 技術 ~
__EOF__

出 處:https://www.cnblogs.com/mrhelloworld
關於博主:評論和私信會在第一時間回復。或者直接私信我。
版權聲明:署名 - 非商業性使用 - 禁止演繹,協議普通文本 | 協議法律文本。
聲援博主:如果您覺得文章對您有幫助,可以點擊文章右下角【推薦】一下。您的鼓勵是博主的最大動力!