1、spring Cloud概述 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發,如服務發現註冊、配置中心、消息匯流排、負載均衡、斷路器、數據監控等,都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring ...
1、spring Cloud概述
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發,如服務發現註冊、配置中心、消息匯流排、負載均衡、斷路器、數據監控等,都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring Cloud並沒有重覆製造輪子,它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來,通過Spring Boot風格進行再封裝屏蔽掉複雜的配置和實現原理,最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。
2、微服務中的相關概念
2.1 服務註冊與發現
服務註冊:服務實例將自身服務信息註冊到註冊中心。這部分服務信息包括服務所在主機IP和提供服務的Port,以及暴露服務自身狀態以及訪問協議等信息。
服務發現:服務實例請求註冊中心獲取所依賴服務信息。服務實例通過註冊中心,獲取到註冊到其中的服務實例的信息,通過這些信息去請求它們提供的服務。
2.2 負載均衡
負載均衡是高可用網路基礎架構的關鍵組件,通常用於將工作負載分佈到多個伺服器來提高網站、應用、資料庫或其他服務的性能和可靠性。
2.3 熔斷
熔斷在互聯網系統中,當下游服務因訪問壓力過大而響應變慢或失敗,上游服務為了保護系統整體的可用性,可以暫時切斷對下游服務的調用。這種犧牲局部,保全整體的措施就叫做熔斷。
2.4 鏈路追蹤
隨著微服務架構的流行,服務按照不同的維度進行拆分,一次請求往往需要涉及到多個服務。互聯網應用構建在不同的軟體模塊集上,這些軟體模塊,有可能是由不同的團隊開發、可能使用不同的編程語言 來實現、有可能布在了幾千台伺服器,橫跨多個不同的數據中心。因此,就需要對一次請求涉及的多個服務鏈路進行日誌記錄,性能監控即鏈路追蹤。
2.5 API網關
隨著微服務的不斷增多,不同的微服務一般會有不同的網路地址,而外部客戶端可能需要調用多個服務 的介面才能完成一個業務需求,如果讓客戶端直接與各個微服務通信可能出現: 客戶端需要調用不同的url地址,增加難度再一定的場景下,存在跨域請求的問題,每個微服務都需要進行單獨的身份認證針對這些問題,API網關順勢而生。 API網關直面意思是將所有API調用統一接入到API網關層,由網關層統一接入和輸出。一個網關的基本功能有:統一接入、安全防護、協議適配、流量管控、長短鏈接支持、容錯能力。有了網關之後,各個 API服務提供團隊可以專註於自己的的業務邏輯處理,而API網關更專註於安全、流量、路由等問題。
3、 SpringCloud架構
3.1 SpringCloud中的核心組件
Spring Cloud的本質是在Spring Boot的基礎上,增加了一堆微服務相關的規範,並對應用上下文 (Application Context)進行了功能增強。既然 Spring Cloud 是規範,那麼就需要去實現,目前 Spring Cloud 規範已有 Spring官方,Spring Cloud Netflix,Spring Cloud Alibaba等實現。通過組件化的方式,Spring Cloud將這些實現整合到一起構成全家桶式的微服務技術棧。
Spring Cloud Netflix組件
3.2 SpringCloud的體繫結構
從上圖可以看出Spring Cloud各個組件相互配合,合作支持了一套完整的微服務架構。
註冊中心負責服務的註冊與發現,很好將各服務連接起來
斷路器負責監控服務之間的調用情況,連續多次失敗進行熔斷保護。
API網關負責轉發所有對外的請求和服務
配置中心提供了統一的配置信息管理服務,可以實時的通知各個服務獲取最新的配置信息
鏈路追蹤技術可以將所有的請求數據記錄下來,方便我們進行後續分析
各個組件又提供了功能完善的dashboard監控平臺,可以方便的監控各組件的運行狀況
4、 服務註冊Eureka基礎
4.1 微服務的註冊中心
註冊中心可以說是微服務架構中的”通訊錄“,它記錄了服務和服務地址的映射關係。在分散式架構中, 服務會註冊到這裡,當服務需要調用其它服務時,就這裡找到服務的地址,進行調用。
4.2 註冊中心的主要作用
服務註冊中心(下稱註冊中心)是微服務架構非常重要的一個組件,在微服務架構里主要起到了協調者 的一個作用。註冊中心一般包含如下幾個功能:
1. 服務發現:
服務註冊/反註冊:保存服務提供者和服務調用者的信息
服務訂閱/取消訂閱:服務調用者訂閱服務提供者的信息,最好有實時推送的功能
服務路由(可選):具有篩選整合服務提供者的能力。
2. 服務配置:
配置訂閱:服務提供者和服務調用者訂閱微服務相關的配置
配置下發:主動將配置推送給服務提供者和服務調用者
3. 服務健康檢測
檢測服務提供者的健康情況。
4.3 常見的註冊中心
Zookeeper
zookeeper它是一個分散式服務框架,是Apache Hadoop 的一個子項目,它主要是用來解決分散式應用中經常遇到的一些數據管理問題,如:統一命名服務、狀態同步服務、集群管理、分散式應用配置項 的管理等。簡單來說zookeeper=文件系統+監聽通知機制。
Eureka
Eureka是在Java語言上,基於Restful Api開發的服務註冊與發現組件,Springcloud Netflix中的重要組 件 Consul Consul是由HashiCorp基於Go語言開發的支持多數據中心分散式高可用的服務發佈和註冊服務軟體, 採用Raft演算法保證服務的一致性,且支持健康檢查。
Nacos
Nacos是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。簡單來說 Nacos 就是 註冊中心 + 配置中心的組合,提供簡單易用的特性集,幫助我們解決微服務開發必會涉及到的服務註冊 與發現,服務配置,服務管理等問題。Nacos 還是 Spring Cloud Alibaba 組件之一,負責服務註冊與 發現。 最後我們通過一張表格大致瞭解Eureka、Consul、Zookeeper的異同點。選擇什麼類型的服務註冊與 發現組件可以根據自身項目要求決定。
4.4 Eureka的概述
4.4.1 Eureka基礎
Eureka是Netflix開發的服務發現框架,SpringCloud將它集成在自己的子項目spring-cloud-netflix中, 實現SpringCloud的服務發現功能。
上圖簡要描述了Eureka的基本架構,由3個角色組成:
1、Eureka Server 提供服務註冊和發現
2、Service Provider 服務提供方 將自身服務註冊到Eureka,從而使服務消費方能夠找到
3、Service Consumer 服務消費方 從Eureka獲取註冊服務列表,從而能夠消費服務
1.1 Eureka Server
Eureka Server提供服務註冊服務,各個節點啟動後,會在Eureka Server中進行註冊,這樣Eureka Server中的服務註冊表中將會存儲所有可用服務節點的信息,服務節點的信息可以在界面中直觀的看到。
Eureka Server本身也是一個服務,預設情況下會自動註冊到Eureka註冊中心。
如果搭建單機版的Eureka Server註冊中心,則需要配置取消Eureka Server的自動註冊邏輯。畢竟當前服務註冊到當前服務代表的註冊中心中是一個說不通的邏輯。
Eureka Server通過Register、Get、Renew等介面提供服務的註冊、發現和心跳檢測等服務。
2.1 Eureka Client
Eureka Client是一個java客戶端,用於簡化與Eureka Server的交互,客戶端同時也具備一個內置的、使用輪詢(round-robin)負載演算法的負載均衡器。在應用啟動後,將會向Eureka Server發送心跳,預設周期為30秒,如果Eureka Server在多個心跳周期內沒有接收到某個節點的心跳,Eureka Server將會從服務註冊表中把這個服務節點移除(預設90秒)。
Eureka Client分為兩個角色,分別是:Application Service(Service Provider)和Application Client(Service Consumer)
4.4.2 Eureka的交互流程與原理
圖是來自Eureka官方的架構圖,大致描述了Eureka集群的工作過程。圖中包含的組件非常多,可能比 較難以理解,我們用通俗易懂的語言解釋一下: Application Service 相當於本書中的服務提供者,Application Client相當於服務消費者; Make Remote Call,可以簡單理解為調用RESTful API; us-east-1c、us-east-1d等都是zone,它們都屬於us-east-1這個region; 由圖可知,Eureka包含兩個組件:Eureka Server 和 Eureka Client,它們的作用如下: Eureka Client是一個Java客戶端,用於簡化與Eureka Server的交互; Eureka Server提供服務發現的能力,各個微服務啟動時,會通過Eureka Client向Eureka Server 進行註冊自己的信息(例如網路信息),Eureka Server會存儲該服務的信息; 微服務啟動後,會周期性地向Eureka Server發送心跳(預設周期為30秒)以續約自己的信息。如 果Eureka Server在一定時間內沒有接收到某個微服務節點的心跳,Eureka Server將會註銷該微服 務節點(預設90秒); 每個Eureka Server同時也是Eureka Client,多個Eureka Server之間通過複製的方式完成服務註 冊表的同步; Eureka Client會緩存Eureka Server中的信息。即使所有的Eureka Server節點都宕掉,服務消費 者依然可以使用緩存中的信息找到服務提供者。 綜上,Eureka通過心跳檢測、健康檢查和客戶端緩存等機制,提高了系統的靈活性、可伸縮性和可用性。
4.4.3 搭建Eureka註冊中心
(1) 引入maven坐標
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency>
(2) 配置application.properties(全局配置)
spring.application.name=eureka-server # 設置spring應用命名,可以自定義,非必要
server.port: 8761 #eureka server web配置埠
eureka.instance.hostname: localhost #設置eureka實例名稱,建議與配置文件的變數相同,必須和Linux系統功能變數名稱相同
eureka.client.registerWithEureka: false #是否將自己註冊到eureka-server中,預設為true
eureka.fetchRegistry: false #是否從eureka-server中獲取服務註冊信息,預設為true
euraka.serviceUrl.defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #設置服務註冊中心地址,指向另一個註冊中心,使用功能變數名稱作為訪問路徑
registerWithEureka: 是否將自己註冊到Eureka服務中,本身就是所有無需註冊 fetchRegistry : 是否從Eureka中獲取註冊信息 serviceUrlEureka: 客戶端與Eureka服務端進行交互的地址
(3) 配置啟動類
@SpringBootApplication @EnableEurekaServer public class EurekaServerApplication { public static void main(String[] args) { SpringApplication.run(EurekaServerApplication.class, args); }
(5) 服務註冊到Eureka註冊中心
5.1 引入坐標
<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-commons</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> </dependencies>
5.2 配置application.properties文件
在工程的 application.properties中添加Eureka Server的主機地址
# eureka server的路徑
eureka.client.serviceUrl.efaultZone: http://localhost:8761/eureka/
instance.prefer-ip-address: true #使用ip註冊
5.3 修改啟動類添加服務註冊註解
@SpringBootApplication //@EnableDiscoveryClient //@EnableEurekaClient public class UserApplication { public static void main(String[] args) { SpringApplication.run(UserApplication.class, args); } }
從Spring Cloud Edgware版本開始, @EnableDiscoveryClient 或 @EnableEurekaClient 可 省略。只需加上相關依賴,併進行相應配置,即可將微服務註冊到服務發現組件上。
4.4.4 Eureka中的自我保護
微服務第一次註冊成功之後,每30秒會發送一次心跳將服務的實例信息註冊到註冊中心。通知 Eureka Server 該實例仍然存在。如果超過90秒沒有發送更新,則伺服器將從註冊信息中將此服務移除。 Eureka Server在運行期間,會統計心跳失敗的比例在15分鐘之內是否低於85%,如果出現低於的情況 (在單機調試的時候很容易滿足,實際在生產環境上通常是由於網路不穩定導致),Eureka Server會 將當前的實例註冊信息保護起來,同時提示這個警告。保護模式主要用於一組客戶端和Eureka Server 之間存在網路分區場景下的保護。一旦進入保護模式,Eureka Server將會嘗試保護其服務註冊表中的信息,不再刪除服務註冊表中的數據(也就是不會註銷任何微服務) 驗證完自我保護機制開啟後,並不會馬上呈現到web上,而是預設需等待 5 分鐘(可以通過 eureka.server.wait-time-in-ms-when-sync-empty 配置),即 5 分鐘後你會看到下麵的提示信息:
如果關閉自我保護 通過設置 eureka.enableSelfPreservation=false 來關閉自我保護功能。
4.4.5 Eureka中的元數據
Eureka的元數據有兩種:標準元數據和自定義元數據。
標準元數據:主機名、IP地址、埠號、狀態頁和健康檢查等信息,這些信息都會被髮布在服務註 冊表中,用於服務之間的調用。
自定義元數據:可以使用eureka.instance.metadata-map配置,符合KEY/VALUE的存儲格式。這些元數據可以在遠程客戶端中訪問。 在程式中可以使用DiscoveryClient 獲取指定微服務的所有元數據信息
@SpringBootTest @RunWith(SpringJUnit4ClassRunner.class) public class RestTemplateTest { @Autowired private DiscoveryClient discoveryClient; @Test public void test() { //根據微服務名稱從註冊中心獲取相關的元數據信息 List<ServiceInstance> instances = discoveryClient.getInstances("shopservice-product"); for (ServiceInstance instance : instances) { System.out.println(instance); } } }
4.4.6 Eureka Server安全認證
Eureka Server作為Spring Cloud中的服務註冊中心,如果可以任意訪問的話,那麼其安全性太低。所以Spring Cloud中也有為Eureka Server提供安全認證的方式。可以使用spring-boot-starter-security組件來為Eureka Server增加安全認證。
pom文件
<!-- spring boot security安全認證啟動器 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>
修改全局配置文件,在全局配置文件中,開啟基於http basic的安全認證。
# eurekaserver1配置 spring.application.name=eureka-server server.port=8761 eureka.instance.hostname=eurekaserver1 # 使用http basic安全認證語法,在集群通信中增加認證信息。 http://用戶名:密碼@地址:埠/eureka/ eureka.client.serviceUrl.defaultZone=http://test:123456@eurekaserver2:8761/eureka/ # 開啟基於http basic的安全認證 security.basic.enabled=true # 設置安全認證用戶名 security.user.name=test # 設置安全認證密碼 security.user.password=123456 # eurekaserver2配置 spring.application.name=eureka-server server.port=8761 eureka.instance.hostname=eurekaserver2 eureka.client.serviceUrl.defaultZone=http://test:123456@eurekaserver1:8761/eureka/ security.basic.enabled=true security.user.name=test security.user.password=123456
4.4.8、服務註冊Eureka高級
Eureka Server 高可用集群
Eureka Client會定時連接 Eureka Server,獲取註冊表中的信息並緩存到本地。微服務在消費遠程API時總是使用本地緩存中的數 據。因此一般來說,即使Eureka Server發生宕機,也不會影響到服務之間的調用。但如果Eureka Server宕機時,某些微服務也出現了不可用的情況,Eureka Server中的緩存若不被刷新,就可能會影響到微服務的調用,甚至影響到整個應用系統的高可用。因此,在生成環境中,通常會部署一個高可用 的Eureka Server集群。 Eureka Server可以通過運行多個實例並相互註冊的方式實現高可用部署,Eureka Server實例會彼此增 量地同步信息,從而確保所有節點數據一致。事實上,節點之間相互註冊是Eureka Server的預設行為。
搭建 Eureka Server高可用集群
(1)修改本機host屬性 由於是在個人電腦中進行測試很難模擬多主機的情況,Eureka配置server集群時需要執行host地址。 所以需要修改個人電腦中host地址
127.0.0.1 eureka1
127.0.0.1 eureka2
(2)修改 shop_eureka_server 工程中的yml配置文件,添加如下配置屬性
#指定應用名稱
spring:
application:
name: shop-eureka-server
---
#執行peer1的配置信息
spring:
profiles: eureka1
server:
port: 8761
eureka:
instance:
hostname: eureka1
client:
service-url:
defaultZone: http://eureka2:8762/eureka
---
#執行peer2的配置信息
參考:https://www.cnblogs.com/jing99/p/11576133.html
5 Eureka替換方案Consul
5.1 Eureka閉源影響
在Euraka的GitHub上,宣佈Eureka 2.x閉源。近這意味著如果開發者繼續使用作為 2.x 分支上現有工作 repo 一部分發佈的代碼庫和工件,則將自負風險。
5.2 Eureka的替換方案
Zookeeper
ZooKeeper是一個分散式的,開放源碼的分散式應用程式協調服務,是Google的Chubby一個開源的實現,是Hadoop和Hbase的重要組件。它是一個為分散式應用提供一致性服務的軟體,提供的功能包 括:配置維護、功能變數名稱服務、分散式同步、組服務等。 Consul consul是近幾年比較流行的服務發現工具,工作中用到,簡單瞭解一下。consul的三個主要應用場景: 服務發現、服務隔離、服務配置。 Nacos Nacos 是阿裡巴巴推出來的一個新開源項目,這是一個更易於構建雲原生應用的動態服務發現、配置管 理和服務管理平臺。Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性 集,幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。Nacos 幫助您更敏捷和容易地 構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務範式、雲原 生範式) 的服務基礎設施。
5.2 什麼是consul
5.2.1 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 存儲多數據中心
5.2.2 consul與Eureka的區別
(1)一致性 Consul強一致性(CP) 服務註冊相比Eureka會稍慢一些。因為Consul的raft協議要求必須過半數的節點都寫入成功才認 為註冊成功 Leader掛掉時,重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。 Eureka保證高可用和最終一致性(AP) 服務註冊相對要快,因為不需要等註冊信息replicate到其他節點,也不保證註冊信息是否 replicate成功 當數據出現不一致時,雖然A, B上的註冊信息不完全相同,但每個Eureka節點依然能夠正常對外提 供服務,這會出現查詢服務信息時如果請求A查不到,但請求B就能查到。如此保證了可用性但犧牲了一致性。
(2)開發語言和使用 eureka就是個servlet程式,跑在servlet容器中 Consul則是go編寫而成,安裝啟動即可
5.2.3 Consul的核心知識
Gossip協議 傳統的監控,如ceilometer,由於每個節點都會向server報告狀態,隨著節點數量的增加server的壓力 隨之增大。在所有的Agent之間(包括伺服器模式和普通模式)運行著Gossip協議。伺服器節點和普通 Agent都會加入這個Gossip集群,收發Gossip消息。每隔一段時間,每個節點都會隨機選擇幾個節點發送Gossip消息,其他節點會再次隨機選擇其他幾個節點接力發送消息。這樣一段時間過後,整個集群都能收到這條消息。示意圖如下:
RAFT一致性演算法
為了實現集群中多個ConsulServer中的數據保持一致性,consul使用了基於強一致性的RAFT演算法。 在Raft中,任何時候一個伺服器可以扮演下麵角色之一:
1. Leader: 處理所有客戶端交互,日誌複製等,一般一次只有一個Leader;
2. Follower: 類似選民,完全被動;
3. Candidate(候選人): 可以被選為一個新的領導人。
Leader全權負責所有客戶端的請求,以及將數據同步到Follower中(同一時刻系統中只存在一個 Leader)。Follower被動響應請求RPC,從不主動發起請求RPC。Candidate由Follower向Leader轉換 的中間狀態 關於RAFT一致性演算法有一個經典的動畫http://thesecretlivesofdata.com/raft/,其中詳細介紹了選舉,數據同步的步驟。
5.2.4 Consul 常見問題
(1)節點和服務註銷 當服務或者節點失效,Consul不會對註冊的信息進行剔除處理,僅僅標記已狀態進行標記(並且不可使用)。如果擔心失效節點和失效服務過多影響監控。可以通過調用HTTP API的形式進行處理。
(2)健康檢查與故障轉移 在集群環境下,健康檢查是由服務註冊到的Agent來處理的,那麼如果這個Agent掛掉了,那麼此節點的健康檢查就處於無人管理的狀態。 從實際應用看,節點上的服務可能既要被髮現,又要發現別的服務,如果節點掛掉了,僅提供被髮現的 功能實際上服務還是不可用的。當然發現別的服務也可以不使用本機節點,可以通過訪問一個Nginx實 現的若幹Consul節點的負載均衡來實現。
感謝閱讀,借鑒了不少大佬資料,如需轉載,請註明出處,謝謝!https://www.cnblogs.com/huyangshu-fs/p/13876009.html