上篇文章 《Eureka 緩存機制》 介紹了Eureka的緩存機制,相信大家對Eureka 有了進一步的了解,本文將詳細介紹API網(wǎng)關如何實現(xiàn)服務下線的實時感知。
在基于云的微服務應用中,服務實例的網(wǎng)絡位置都是動態(tài)分配的。而且由于自動伸縮、故障和升級,服務實例會經(jīng)常動態(tài)改變。因此,客戶端代碼需要使用更加復雜的服務發(fā)現(xiàn)機制。
目前服務發(fā)現(xiàn)主要有兩種模式:客戶端發(fā)現(xiàn)和服務端發(fā)現(xiàn)。
服務端發(fā)現(xiàn):客戶端通過負載均衡器向服務注冊中心發(fā)起請求,負載均衡器查詢服務注冊中心,將每個請求路由到可用的服務實例上。
客戶端發(fā)現(xiàn):客戶端負責決定可用服務實例的網(wǎng)絡地址,并且在集群中對請求負載均衡, 客戶端訪問服務登記表,也就是一個可用服務的數(shù)據(jù)庫,然后客戶端使用一種負載均衡算法選擇一個可用的服務實例然后發(fā)起請求。
客戶端發(fā)現(xiàn)相對于服務端發(fā)現(xiàn)大的區(qū)別是:客戶端知道(緩存)可用服務注冊表信息。如果Client端緩存沒能從服務端及時更新的話,可能出現(xiàn)Client 與 服務端緩存數(shù)據(jù)不一致的情況。
Netflix OSS 提供了一個客戶端服務發(fā)現(xiàn)的好例子。Eureka Server 為注冊中心,Zuul 相對于Eureka Server來說是Eureka Client,Zuul 會把 Eureka Server 端服務列表緩存到本地,并以定時任務的形式更新服務列表,同時zuul通過本地列表發(fā)現(xiàn)其它服務,使用Ribbon實現(xiàn)客戶端負載均衡。
正常情況下,調(diào)用方對網(wǎng)關發(fā)起請求即刻能得到響應。但是當對生產(chǎn)者做縮容、下線、升級的情況下,由于Eureka這種多級緩存的設計結(jié)構(gòu)和定時更新的機制,LoadBalance 端的服務列表B存在更新不及時的情況(由上篇文章 《Eureka 緩存機制》 可知,服務消費者最長感知時間將無限趨近240s),如果這時消費者對網(wǎng)關發(fā)起請求,LoadBalance 會對一個已經(jīng)不存在的服務發(fā)起請求,請求是會超時的。
生產(chǎn)者下線后,最先得到感知的是 Eureka Server 中的 readWriteCacheMap,最后得到感知的是網(wǎng)關核心中的 LoadBalance。但是 loadBalance 對生產(chǎn)者的發(fā)現(xiàn)是在 loadBalance 本地維護的列表中。
所以要想達到網(wǎng)關對生產(chǎn)者下線的實時感知,可以這樣做:首先生產(chǎn)者或者部署平臺主動通知 Eureka Server, 然后跳過 Eureka 多級緩存之間的更新時間,直接通知 Zuul 中的 Eureka Client,最后將 Eureka Client 中的服務列表更新到 Ribbon 中。
但是如果下線通知的邏輯代碼放在生產(chǎn)者中,會造成代碼污染、語言差異等問題。
借用一句名言:
“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決”
Gateway-SynchSpeed 相當于一個代理服務,它對外提供REST API來負責響應調(diào)用方的下線請求,同時會將生產(chǎn)者的狀態(tài)同步到 Eureka Server 和 網(wǎng)關核心,起著 狀態(tài)同步 和 軟事物 的作用。
思路 :在生產(chǎn)者做 縮容、下線、升級 前,spider 平臺(spider為容器管理平臺)會主動通知 Gateway-SynchSpeed 某個生產(chǎn)者的某個實例要下線了,然后 Gateway-SynchSpeed 會通知 Eureka Server 生產(chǎn)者的某個實例下線了;如果Eureka Server 下線成功,Gateway-SynchSpeed 會直接通知 網(wǎng)關核心。
設計特點
無侵入性、方便使用。不用關心調(diào)用方的基于何種語言實現(xiàn),調(diào)用者只要對 Gateway-SynchSpeed 發(fā)起一個http rest請求即可,真正的實現(xiàn)邏輯不用侵入到調(diào)用方而是交給這個代理來實現(xiàn)。
原子性。調(diào)用方先在Eureka Server下線,然后在所有相關網(wǎng)關核心中下線為最小工作執(zhí)行單元,Gateway-SynchSpeed 相當于一個"軟事物",保證服務下線的某種程度上原子特性。
步驟說明
第一步:在生產(chǎn)者做 縮容、下線、升級 前,spider平臺會以http請求的形式通知到 Gateway-SynchSpeed 服務,通知的粒度為服務實例所在的容器IP。
第二步:Gateway-SynchSpeed 接受到請求后,先校驗IP的可用性,然后通知Eureka Server。
第三步:Eureka Server 將 Producer 置為失效狀態(tài),并返回處理結(jié)果(Eureka 下線形式分為兩種,一種是直接從服務注冊列表直接剔除,第二種是狀態(tài)下線,即是將 Producer 的狀態(tài)置為
OUT_OF_SERVICE
。 如果是以第一種形式下線,Spider平臺發(fā)出下線請求后,不能保證Producer進程立刻被kill,如果這期間 Producer 還有心跳同步到 Eureka Server,服務會重新注冊到 Eureka Server)。
第四步:Gateway-SynchSpeed 得到上一步結(jié)果,如果結(jié)果為成功,則執(zhí)行下一步;反之,則停止。
第五步:Gateway-SynchSpeed 為Eureka Client。Gateway-SynchSpeed 通過 IP 到本地服務注冊列表中得到 Producer 的 Application-Name。
第六步:Gateway-SynchSpeed 通過 Application-Name 到網(wǎng)關核心庫中查詢所有與下線服務相關的
網(wǎng)關組名字
。
第七步:Gateway-SynchSpeed 通過
網(wǎng)關組名字
到本地服務列表中查找網(wǎng)關組下所有的服務地址 ipAddress(ip : port)。
第八步:Gateway-SynchSpeed 異步通知所有相關網(wǎng)關節(jié)點。
第九步:Gateway-Core 收到通知后,對 Producer 做狀態(tài)下線,同時記錄所有狀態(tài)下線成功的實例信息到緩存 DownServiceCache 中。
第十步:Gateway-Core 更新本地 Ribbon 服務列表。
Eureka 提供了一種安全保護機制。Eureka Client 從 Eureka Server 更新服務列表前,會校驗相關Hash值是否改變( Client 服務列表被修改,hash值會改變),如果改變,更新方式會從增量更新變成全量更新,(由 《Eureka 緩存機制》 可知這30s內(nèi) readOnlyCacheMap 和 readWriteCacheMap 的數(shù)據(jù)可能存在差異),如果Client端緩存列表被readOnlyCacheMap 覆蓋,最終會導致 Ribbon 端服務列表與 readWriteCacheMap 數(shù)據(jù)不一致。
針對 Eureka 這種機制,引入監(jiān)聽器 EurekaEventListener 作為補償機制,它會監(jiān)聽 Eureka Client 全量拉取事件,對于緩存中未超過30s的服務,將其狀態(tài)重新設置成
OUT_OF_SERVICE
。
考慮到系統(tǒng)的安全性問題,如果被人惡意訪問,可能會使生產(chǎn)者在Eureka Server中無故下線,導致消費者無法通過 Eureka Server 來發(fā)現(xiàn)生產(chǎn)者。
使用黑白名單做安全過濾,基本流程如下:
對 Gateway-Synchspeed 中設置白名單網(wǎng)段(IP網(wǎng)段)
在 Gateway-Synchspeed 加入過濾器,對下線請求方進行IP校驗,如果請求端IP在網(wǎng)段中,則放行;反之,過濾。
由于 Gateway-SynchSpeed 和 Gateway-Core 是部署在 Docker 容器中,如果容器重啟,會導致日志文件全部丟失。所以需要將 Gateway-SynchSpeed 和 Gateway-Core 中相關日志寫入到 Elasticsearch ,最終由 Kibana 負責查詢 Elasticsearch 的數(shù)據(jù)并以可視化的方式展現(xiàn)。
Gateway-SynchSpeed 做狀態(tài)同步
EurekaEventListener 處理緩存數(shù)據(jù)
目前網(wǎng)關實現(xiàn)對服務下線的實時感知中,使用的 Zuul 和 Eureka 版本為 Spring Cloud Zuul 1.3.6.RELEASE 、Spring Cloud Eureka 1.4.4.RELEASE。
目前網(wǎng)關實現(xiàn)的是對網(wǎng)關下游服務的實時感知,而且需滿足以下條件:
生產(chǎn)者需部署在 kubernetes 容器管理平臺
生產(chǎn)者做正常的 下線、升級或者縮容 操作。如果是由于容器資源不足,導致服務異常宕機等非正常下線,不支持。
網(wǎng)關服務下線實時感知是網(wǎng)關對業(yè)務方提供的一種可選的解決方案,在 spider 平臺中默認是沒有開啟此功能,是否開啟此功能由業(yè)務方根據(jù)本身系統(tǒng)要求決定,具體如何配置可參考 API網(wǎng)關接入指南 中 《網(wǎng)關實時感知在spider上配置文檔說明》。
作者:謝國輝
新聞名稱:程序員筆記|API網(wǎng)關如何實現(xiàn)對服務下線實時感知-創(chuàng)新互聯(lián)
轉(zhuǎn)載來于:http://sd-ha.com/article18/ddoddp.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁設計公司、軟件開發(fā)、關鍵詞優(yōu)化、網(wǎng)站制作、面包屑導航、網(wǎng)站改版
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)