在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮、故障和公升級，服務例項會經常動態改變。因此，客戶端**需要使用更加複雜的服務發現機制。
目前服務發現主要有兩種模式：客戶端發現和服務端發現。
客戶端發現相對於服務端發現最大的區別是：客戶端知道（快取）可用服務登錄檔資訊。如果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值會改變)，如果改變，更新方式會從增量更新變成全量更新，如果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閘道器如何實現對服務下線實時感知
在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮 故障和公升級，服務例項會經常動態改變。因此，客戶端 需要使用更加複雜的服務發現機制。目前服務發現主要有兩種模式 客戶端發現和服務端發現。客戶端發現相對於服務端發現最大的區別是 客戶端知道 快取 可用服務登錄檔資訊。如果cli...
API閘道器如何實現對服務下線實時感知
上篇文章 eureka 快取機制 介紹了eureka的快取機制，相信大家對eureka 有了進一步的了解，本文將詳細介紹api閘道器如何實現服務下線的實時感知。在基於雲的微服務應用中，服務例項的網路位置都是動態分配的。而且由於自動伸縮 故障和公升級，服務例項會經常動態改變。因此，客戶端 需要使用更加...
對微服務API服務閘道器的理解
目錄 微服務專字段址 目錄1.簡介 2.什麼是api閘道器 3.為什麼需要api閘道器 4.api閘道器在微服務架構體系中處於什麼位置 4.1 呼叫者眼中的api閘道器 4.2 所處的位置 5.閘道器技術實現有哪些 6.zuul閘道器工作原理是什麼樣的 6.1 整體處理流程圖 6.2 請求生命週期 ...