微服務框架
微服務是一種架構風格,一個大型復雜軟體應用應該由一個或多個微服務組成,系統中的各個微服務都可以被獨立部署,每個服務僅關注于完成一件任務就行了,在所有情況下,每個任務都代表著一個小的業務能力,微服務架構其實就是一種架構風格,我們將整個專案劃分為多個獨立的小專案,也就是我們俗稱的微服務,可以理解為每個微服務都單獨處理某個功能模塊,可以獨立開發、測驗、部署、監控和擴展,甚至可以用不同的編程語言開發它們,它有利于我們平時專案的開發,解決了一體化架構專案難以擴展,開發周期長,故障級聯等問題,
主要記錄一下微服務框架中SpringCloud的,SpringCloud是一個一系列的有序集合,利用SpringBoot的開發便利性簡化了分布式系統基礎設施的開發,如服務注冊與發現、配置中心、訊息總線、負載均衡、斷路器、資料監控等,都可以用SpringBoot的開發風格做到一鍵啟動與部署,
微服務的優缺點:
優點:
- 獨立開發部署
- 圍繞業務功能創建、組織代碼
- 改善故障隔離、一個服務的宕機不會影響到其他服務的使用
- 易于規模化開發、多個團隊協同并行開發
- 可以使用不同語言開發
缺點:
- 測驗作業困難
- 部署復雜
- 開發人員需要處理分布式系統的復雜性、提高了開發的復雜性
SpringCloud核心組件

Eureka(注冊中心)
Eureka是SpringCloud微服務架構中的注冊中心,專門負責服務的注冊與發現,里面有一個注冊表,保存了各個服務器的機器埠,
Eureka服務端:
稱為服務注冊中心,跟其他的服務注冊中心一樣,支持高可用配置,如果Eureka集群模式部署,當集群中有分片出現故障的時候,那么Eureka就會轉入自我保護模式,它允許在分片出現故障期間繼續提供服務的發現與注冊,當故障分片回復運行的時候,集群中的其他分片就會把它們的狀態再次同步起來,
Eureka客戶端:
主要處理服務的注冊與發現,客戶端通過注解和引數配置的方式,嵌入在客戶端應用程式中,在應用程式運行時,Eureka客戶端向注冊中心自身提供的服務并周期性的發送心跳來更新它的服務租約,同時,也能從服務端查詢當前注冊的服務資訊并把它們快取到本地并周期性的重繪服務狀態,
Eureka Server的高可用實際上就是作為一個服務注冊到其他的注冊中心,這樣就可以形成一組互相注冊的服務注冊中心,以實作服務清單的互相同步,達到高可用的效果,
創建SpringCloud微服務框架:??????IDEA中搭建一個SpringCloud微服務框架及簡單介紹_Sinder小德的博客-CSDN博客_idea 微服務框架搭建
Zuul(服務網關)
服務網關Zuul是負責轉發請求給對應服務模塊的,這個組件是負責網路路由的,
SpringCloud Zuul通過與Eureka的整合,將自身注冊為注冊中心治理下的一個應用服務,通過從注冊中心中獲得了其他微服務的實體資訊
對于路由規則的維護,Zuul默認會通過以服務名稱作為ContextPath的方式來創建路由映射,并且Zuul支持在API網關上進行統一的呼叫來對微服務介面做前置過濾,已實作對微服務介面的攔截和校驗,
Ribbon(負載均衡)
Ribbon是一個基于HTTP與TCP的客戶端負載均衡器,在通過客戶端中配置的ribbonServerList服務端串列去輪詢訪問達到服務均衡的作用,
而在Eureka中,Ribbon的服務端串列會重寫拓展成從注冊中心去獲取服務端串列,在客戶端負載均衡中,也需要利用心跳來維護服務端清單的健康性,只是這個步驟需要與服務注冊中心配合完成,
在SpringCloud Ribbon中,服務提供者只需要啟動多個服務實體并且注冊到一個注冊中心或者多個相關聯的服務注冊中心,服務消費者直接通過呼叫被@LoadBalanced注解修飾過的RestTemplate來實作面向服務的介面呼叫,
Hystrix(熔斷保護器)
熔斷器,容錯管理工具,是指通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供容錯能力,提供執行緒池不同的服務走不同的執行緒池,實作了不同服務呼叫的隔離,避免了服務器雪崩的問題,
在微服務架構當中,存在著許多的服務單元,當一個單元出現故障的時候,就很容易因為服務間的依賴關系從而導致故障的蔓延,最終導致整個系統的癱瘓,這會使得系統架構更加不穩定,因此為了解決這類問題,就有了斷路器等服務保護機制,
分布式架構中,當某個服務單元發生故障之后,通過斷路器的故障監控,向服務呼叫方回傳一個錯誤的回應,而不是長時間的等待,這樣就不會使得執行緒因為呼叫故障服務導致長時間占用不釋放,避免了故障的蔓延,
Hystrix具備服務降級、服務熔斷、執行緒和信號隔離、請求快取、請求合并、服務監控等強大的功能,
Hystrix使用艙壁模式實作執行緒池的隔離,會為每一個依賴服務創建一個獨立的執行緒池,這樣就算某個依賴服務出現延遲過高的情況,也只是對該依賴服務的呼叫產生影響,而不會拖慢其他服務的使用,
艙壁模式:隔離了每個作業負載或服務的關鍵資源,如連接池、記憶體和CPU, 使用艙壁避免了單個作業負載(或服務)消耗掉所有資源,從而導致其他服務出現故障的場景, 這種模式主要是通過防止由一個服務引起的級聯故障來增加系統的彈性,讓不同任務請求通過自個專門的執行緒池請求到各自微服務,像艙壁一樣對資源進行隔離,
整合Hystrix:SpringCloud的熔斷機制Hystrix的實作_Sinder小德的博客-CSDN博客
Feign(Rest轉換器)
Feign是基于動態代理機制,根據注解和選擇的機器,拼接請求URL地址,發起請求,Feign的關鍵在于是使用了動態代理機制,
實際使用:
- 對某個介面定義了@FeignClient注解,Feign就會針對這個介面創建動態代理,
- 呼叫介面的時候,就是呼叫Feign創建的動態代理,
- Feign的動態代理會根據在介面上的@RequestMapping等注解,來動態構造要請求的服務的地址,
- 針對于這個地址,發起請求、決議回應,
Feign和Ribbon、Eureka的協作:
首先Ribbon從Eureka中獲取對應的服務注冊表,也就知道每個服務對應的地址和埠,
Feign就可以構造并發起請求,
Config(分布式配置)
配置管理的工具,可以把配置資訊放到遠程的服務器,集中化管理集群的配置資訊,目前支持本地存盤,Git和Subversion(嘗試過用gitee統一放組態檔)
注冊中心與API網關
記錄一下一些文章的分析與使用建議
微服務網關更多是在前后端分離應用,也就是把內部的各個微服務組件模塊的API介面能力統一注冊和接入到網關中,對于前端的訪問只需要訪問網關暴露的介面即可,同時通過網關還可以進一步的實作安全隔離,也就是說,網關更多的是實作了介面服務的代理和路由轉發能力,更多的是向外的一種能力的發布,
因此:
1、一個獨立的開發團隊,為了保證獨立自治,以及內部多個微服務模塊間的互動集成,最好啟用獨立的服務注冊中心實作服務注冊,發現能力,即開發團隊內部多個微服務模塊間的集成,不需要通過網關,只需要通過服務注冊中心進行集成即可,
2、開發團隊需要暴露能力給外部,包括暴露能力給其他的開發團隊,需要考慮將API介面注冊到外部的網關中,建議拆分成兩個獨立的網關,一個是內部集成的API網關,一個是放置到DMZ區面對公網房訪問的API網關,對于服務如果同時涉及到內部和外部的使用,則兩邊注冊,建議不要通過兩次網關去路由,一個影響性能,一個是不方便后續問題的排查,
3、構建在開發團隊之外的API網關必須具備負載均衡能力,可以配置多個IP地址,通過該API網關也最好具備和Docker容器拓展后的服務自動注冊和地址加入拓展能力,
除Eureka外的其他的注冊中心(競品)
記錄引入 :
Eureka
1、Spring Cloud Eureka所選擇的是AP,采用的是去中心化結構,放棄了強一致性,也就是說Eureka集群中的各個結點都是平等的,沒有主從的概念,通過互相注冊的方式來進行訊息同步和保證高可用,并且一個Eureka Server結點掛掉了,還有其他同等的結點來提供服務,并不會引發服務的中斷
2、Eureka只能當注冊中心,想搞配置中心的話,還得搭配Spring Cloud Config+Spring Cloud Bus,其中后者支持Rabbiimq和Kafka兩種模式,
3、使用Java語言來開發的,并且也是Spring Cloud的子專案,所以可以直接通過引入jar包的方式來集成Eureka,這點非常方便
1. ZooKeeper
這是一款經典的服務注冊中心產品(雖然它最初的定位并不在于此),在很長一段時間里,它是國人在提起RPC服務注冊中心時心里想到的唯一選擇,這很大程度上與Dubbo在中國的普及程度有關,
1、Apache Zookeeper所選擇的是CP,也就是放棄了高可用性,Zookeeper集群在進行訊息同步的時候,必須有一半以上結點完成了同步才會回傳;而當Master結點掛了或者集群中有過半的結點不能作業了,此時就會觸發故障恢復,重新進行Master選舉,在這個程序中,整個Zookeeper集群無法對外提供服務,從而實去了A(可用性)
2、為了達到C,Zookeeper采用的是自己的ZAB協議,
2. Nacos
Nacos是阿里巴巴旗下的開源專案,在2018年開源,攜帶著阿里巴巴大規模服務生產經驗,試圖在服務注冊和配置管理這個市場上,提供給用戶一個新的選擇,
1、Nacos一大特性是即支持CP,也支持AP,可以根據需要靈活選擇,
2、Nacos除了注冊中心之外,也能充當配置中心的作用,且配置中心可以按照namespace,group等維度來進行資料隔離,來達到不同環境之間配置隔離的功能,
值得一提的是,Nacos作為配置中心的持久化機制可以依賴于
Mysql來完成(默認依賴于內置資料庫),只需要將Nacos目錄下的sql腳本放到mysql中執行(會生成11個表),然后在nacos組態檔里面配一下mysql的賬號密碼即可,這樣使用mysql作為資料源的方式相比于nacos內置資料庫來說更容易管理
3. Consul
Consul是HashiCorp公司推出的一個開源工具,
1、Consul是用Go語言撰寫的,所以無法像Eureka那樣直接引入jar包就能集成,它還需要去服務器中進行額外的安裝,
2、除了注冊中心的功能之外,Consul還能起到配置中心的作用,
Consul它保證的是CP,使用raft協議,要求必須有過半的結點都寫入成功才算是注冊成功了,并且它也有Master和Follower的概念,在Master掛掉后,也需要自己內部進行
4. Etcd(待續)
對比SpringCloud,Kubernetes也提供完整的分布式微服務管理框架,幾乎所有組件都有對應的產品,其中Etcd也可以提供類似Eureka的注冊中心,
在 Go 生態中,還可以選擇基于 Etcd 作為注冊中心,Etcd 是由 CoreOS 團隊維護的、高可用分布式鍵值存盤資料庫,可用于為集群提供配置和服務發現功能,Google 開源的容器管理工具 Kuberbetes 就是基于 Etcd 的,
和 Consul 一樣,Etcd 也是基于 Raft 協議作為分布式一致性演算法來解決領導者選舉和日志復制問題,同樣也是基于 Go 語言撰寫,
Etcd 也支持代理模式(proxy),只不過在 Etcd 中,代理模式和 Consul 的客戶端代理模式類似,安裝在部署服務的節點上,用來轉發請求到 Etcd 集群,本身不存盤任何資料,Etcd 集群相當于 Consul 中以服務端模式運行的 Consul 集群,通常要求配置三個及以上節點(不要太多,3~5就夠了,以便可用性和性能上達到平衡),負責真正的請求處理 —— 服務注冊與發現,
在目前最新版本的 Etcd v3中,通過網關模式(gateway)取代了 V2 版本中的代理模式(proxy),
從服務發現的實作原理上來說,Consul 和 Etcd 的基本設計思路是一致的,Etcd 更簡單,Consul 則更像一個全堆疊的解決方案,功能比 Etcd 要更豐富,比如支持可視化的 Web UI 管理界面、支持多資料庫中心、安全層面除了 HTTPS 外還支持 ACL、更加全面的健康檢查功能、內置 DNS Server 等,這些都是 Etcd 所不具備的,但是更全面的功能往往意味著更高的復雜性,針對微服務的服務注冊和發現場景,Etcd 完全夠用了,
Spring Cloud 全家桶的簡介
Spring Cloud Config:配置管理工具包,讓你可以把配置放到遠程服務器,集中化管理集群配置,目前支持本地存盤、Git 以及 Subversion,
Spring Cloud Bus:事件、訊息總線,用于在集群(例如,配置變化事件)中傳播狀態變化,可與 Spring Cloud Config 聯合實作熱部署,
Eureka:云端服務發現,一個基于 REST 的服務,用于定位服務,以實作云端中間層服務發現和故障轉移,
Hystrix:熔斷器,容錯管理工具,旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力,
Zuul:Zuul 是在云平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架,Zuul 相當于是設備和 Netflix 流應用的 Web 網站后端所有請求的前門,
Archaius:配置管理 API,包含一系列配置管理 API,提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回呼機制等功能,
Consul:封裝了 Consul 操作,Consul 是一個服務發現與配置工具,與 Docker 容器可以無縫集成,
Spring Cloud for Cloud Foundry:通過 Oauth2 協議系結服務到 CloudFoundry,CloudFoundry 是 VMware 推出的開源 PaaS 云平臺,
Spring Cloud Sleuth:日志收集工具包,封裝了 Dapper 和 log-based 追蹤以及 Zipkin 和 HTrace 操作,為 Spring Cloud 應用實作了一種分布式追蹤解決方案,
Spring Cloud Data Flow:大資料操作工具,作為 Spring XD 的替代產品,它是一個混合計算模型,結合了流資料與批量資料的處理方式,
Spring Cloud Security:基于 Spring Security 的安全工具包,為你的應用程式添加安全控制,
Spring Cloud Zookeeper:操作 Zookeeper 的工具包,用于使用 Zookeeper 方式的服務發現和配置管理,
Spring Cloud Stream:資料流操作開發包,封裝了與 Redis、Rabbit、Kafka 等發送接收訊息,
Spring Cloud CLI:基于 Spring Boot CLI,可以讓你以命令列方式快速建立云組件,
Ribbon:提供云端負載均衡,有多種負載均衡策略可供選擇,可配合服務發現和斷路器使用,
Turbine:Turbine 是聚合服務器發送事件流資料的一個工具,用來監控集群下 Hystrix 的 Metrics 情況,
Feign:Feign 是一種宣告式、模板化的 HTTP 客戶端,
Spring Cloud Task:提供云端計劃任務管理、任務調度,
Spring Cloud Connectors:便于云端應用程式在各種 PaaS 平臺連接到后端,如:資料庫和訊息代理服務,
Spring Cloud Cluster:提供 Leadership 選舉,如:Zookeeper,Redis,Hazelcast,Consul 等常見狀態模式的抽象和實作,
Spring Cloud Starters:Spring Boot 式的啟動專案,為 Spring Cloud 提供開箱即用的依賴管理,
要點記錄,受益無窮,
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/325541.html
標籤:其他
