在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮、故障和公升級，服務例項會經常動態改變。因此，客戶端**需要使用更加複雜的服務發現機制。
目前服務發現主要有兩種模式：客戶端發現和服務端發現。
客戶端發現相對於服務端發現最大的區別是：客戶端知道（快取）可用服務登錄檔資訊。如果client端快取沒能從服務端及時更新的話，可能出現client 與 服務端快取資料不一致的情況。
netflix oss 提供了乙個客戶端服務發現的好例子。eureka server 為註冊中心，zuul 相對於eureka server來說是eureka client,zuul 會把 eureka server 端服務列表快取到本地，並以定時任務的形式更新服務列表，同時zuul通過本地列表發現其它服務，使用ribbon實現客戶端負載均衡。
正常情況下，呼叫方對閘道器發起請求即刻能得到響應。但是當對生產者做縮容、下線、公升級的情況下，由於eureka這種多級快取的設計結構和定時更新的機制，loadbalance 端的服務列表b存在更新不及時的情況(由上篇文章《eureka 快取機制》可知，服務消費者最長感知時間將無限趨近240s），如果這時消費者對閘道器發起請求，loadbalance 會對乙個已經不存在的服務發起請求，請求是會超時的。
生產者下線後，最先得到感知的是 eureka server 中的 readwritecachemap，最後得到感知的是閘道器核心中的 loadbalance。但是 loadbalance 對生產者的發現是在 loadbalance 本地維護的列表中。
所以要想達到閘道器對生產者下線的實時感知，可以這樣做：首先生產者或者部署平台主動通知 eureka server, 然後跳過 eureka 多級快取之間的更新時間，直接通知 zuul 中的 eureka client,最後將 eureka client 中的服務列表更新到 ribbon 中。
但是如果下線通知的邏輯**放在生產者中，會造成**汙染、語言差異等問題。
借用一句名言：
「電腦科學領域的任何問題都可以通過增加乙個間接的中間層來解決」
gateway-synchspeed 相當於乙個**服務，它對外提供rest api來負責響應呼叫方的下線請求，同時會將生產者的狀態同步到 eureka server 和 閘道器核心，起著 狀態同步 和 軟事物 的作用。
思路：在生產者做縮容、下線、公升級前，spider 平台（spider為容器管理平台）會主動通知 gateway-synchspeed 某個生產者的某個例項要下線了，然後 gateway-synchspeed 會通知 eureka server 生產者的某個例項下線了；如果eureka server 下線成功，gateway-synchspeed 會直接通知 閘道器核心。
設計特點
步驟說明
eureka 提供了一種安全保護機制。eureka client 從 eureka server 更新服務列表前，會校驗相關hash值是否改變( client 服務列表被修改，hash值會改變)，如果改變，更新方式會從增量更新變成全量更新,（由《eureka 快取機制》可知這30s內 readonlycachemap 和 readwritecachemap 的資料可能存在差異），如果client端快取列表被readonlycachemap 覆蓋，最終會導致 ribbon 端服務列表與 readwritecachemap 資料不一致。
針對 eureka 這種機制，引入*** eurekaeventlistener 作為補償機制，它會監聽 eureka client 全量拉取事件,對於快取中未超過30s的服務，將其狀態重新設定成out_of_service。
考慮到系統的安全性問題，如果被人惡意訪問，可能會使生產者在eureka server中無故下線，導致消費者無法通過 eureka server 來發現生產者。
使用黑白名單做安全過濾，基本流程如下：
由於 gateway-synchspeed 和 gateway-core 是部署在 docker 容器中，如果容器重啟，會導致日誌檔案全部丟失。所以需要將 gateway-synchspeed 和 gateway-core 中相關日誌寫入到 elasticsearch ，最終由 kibana 負責查詢 elasticsearch 的資料並以視覺化的方式展現。
gateway-synchspeed 做狀態同步
eurekaeventlistener 處理快取資料
目前閘道器實現對服務下線的實時感知中，使用的 zuul 和 eureka 版本為 spring cloud zuul 1.3.6.release 、spring cloud eureka 1.4.4.release。
目前閘道器實現的是對閘道器下游服務的實時感知，而且需滿足以下條件：
閘道器服務下線實時感知是閘道器對業務方提供的一種可選的解決方案，在 spider 平台中預設是沒有開啟此功能，是否開啟此功能由業務方根據本身系統要求決定，具體如何配置可參考api閘道器接入指南中 《閘道器實時感知在spider上配置文件說明》。
API閘道器如何實現對服務下線實時感知
上篇文章 eureka 快取機制 介紹了eureka的快取機制，相信大家對eureka 有了進一步的了解，本文將詳細介紹api閘道器如何實現服務下線的實時感知。在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮 故障和公升級，服務例項會經常動態改變。因此，客戶端 需要使用更加...
API閘道器如何實現對服務下線實時感知
在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮 故障和公升級，服務例項會經常動態改變。因此，客戶端 需要使用更加複雜的服務發現機制。目前服務發現主要有兩種模式 客戶端發現和服務端發現。客戶端發現相對於服務端發現最大的區別是 客戶端知道 快取 可用服務登錄檔資訊。如果cli...
微服務API閘道器
微服務api閘道器 api閘道器是乙個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。api閘道器封裝了系統內部架構，為每個客戶端提供乙個定製的api。它可能還具有其它職責，如身份驗證 監控 負載均衡 快取 請求分片與管理 靜態響應處理。api閘道器方式的核心要點是，所有的客戶端...