SpringCloud是目前比較主流的分布式微服務架構。 且應用都是通過叢集部署的。
是以，灰階釋出是一種必然的趨勢。 新應用上線之後，需要通過灰階測試通過之後，才能正式上線。
本文就是基于上述思考， 通過對SpringCloud的元件進行适當封裝，實作應用的灰階釋出，且對業務代碼無浸入。
實作過程
概述
首先，SpringCloud的簡單調用過程如下：
所有應用向eureka注冊中心注冊， 然後URL請求調用Zuul網關的時候，通過負載均衡方式調用背景服務應用。
基于上述過程，我們調整架構，如下：
第一步 引入Redis
首先，引入Redis，作為存儲灰階服務的緩存資料庫。通過Redis管理服務應用的位址資訊。
第二步 Eureka封裝
在服務注冊到eureka的時候， eureka增加@EventListener監聽應用注冊。
在監聽到新應用注冊的時候，在redis中，增加新應用IP位址，端口，serverName等資訊，且該記錄标記狀态為灰階。
在監聽到新應用下線的時候，在redis中，将應用的狀态标記為下線。
第三步 Zuul封裝
1. URL請求到達zuul網關的時候， zuul在pre階段，進行過濾操作。zuul在pre階段，過濾邏輯如下：
2. 查詢redis中是否有該請求的灰階應用位址。
3. 如果有， 則通過redisTemplate方式，直接調用灰階釋出的位址擷取資訊，并傳回給前端。如果灰階位址有多個，則可以自定義負載均衡政策，來實作負載轉發。
4. 如果沒有，則不攔截， 使用ribbon，進行轉發後端應用。（并重寫IRule方法，過濾掉灰階伺服器和下線伺服器）
第四部 背景管理系統
1. 可通過系統的背景管理系統，對應用進行管理。通路redis擷取所有應用的狀态。
2. 然後通過背景管理系統，更改redis中應用的标記狀态（從灰階标記為上線，表示灰階測試通過，可以上線使用了； 或者從上線改為灰階，将對應應用服務切到灰階測試版本）
基于上述構想，則可以實作應用的灰階釋出。
後續思考
1. 灰階測試的時候，我們想隻有特定手機号才能通路灰階位址， 其他手機号都是通路非灰階的位址，進而無需修改代碼，實作灰階測試。
2. 細化灰階的粒度， 之前是基于應用的灰階釋出。 如何實作基于URL的灰階？