你們對網關的技術選型是怎么考慮的？能對比一下各種網關技術的優劣嗎？
網關的核心功能
(1)動態路由：新開發某個服務，動態把請求路徑和服務的映射關系熱加載到網關里去；服務增減機器，網關自動熱感知
(2)灰度發布
(3)授權認證
(4)性能監控：每個API接口的耗時、成功率、QPS
(5)系統日志
(6)數據緩存
(7)限流熔斷
幾種技術選型：
Kong、Zuul、Nginx+Lua（OpenResty）、自研網關
Kong：Nginx里面的一個基於lua寫的模塊，實現了網關的功能 Zuul：Spring Cloud來玩兒微服務技術架構，Zuul
Nginx+Lua（OpenResty）：課程目錄里面，有一個文檔，課程免費學習，億級流量系統架構的課程，詳細講解了Nginx+Lua的開發，基於lua自己寫類似Kong的網關。
Zuul：基於Java開發，核心網關功能都比較簡單，但是比如灰度發布、限流、動態路由之類的，很多都要自己做二次開發。
高並發能力不強，部署到一些機器上去，還要基於Tomcat來部署，Spring Boot用Tomcat把網關系統跑起來；
Java語言開發，可以直接把控源碼，可以做二次開發封裝各種需要的功能。
自研網關：自己來寫類似Zuul的網關，基於Servlet、Netty來做網關，實現上述所有的功能。
說說生產環境下，你們是怎么實現網關對服務的動態路由的？
方案1：數據庫。
如果映射關系寫死，每次路由關系更改，就需要重啟網關，影響會非常大，因此需要實現網關動態的更新路由關系。 可以使用第三方組件保存路由關系，然后在網關里面通過定時任務去定時刷新組件中保存的路由信息。 因此就可以基於mqsql去做路由關系的保存，然后通過后台管理系統去操作db，再由網關去定時查詢db更新路由表，實現動態效果。
Nginx（Kong、Nginx+Lua）：Nginx抗高並發的能力很強，少數幾台機器部署一下，就可以抗很高的並發，精通Nginx源碼，很難，c語言，很難說從Nginx內核層面去做一些二次開發和源碼定制。
方案2：Config配置。
將 Spring Cloud Zuul 的路由信息，配置在 Config Server 的 env.yml 中，將網關服務注冊為 Config Client，從 Config Server 獲取路由信息。
微服務架構的系統中，我們通常會使用輕量級的消息代理來構建一個共用的消息主題讓系統中所有微服務實例都連接上來，由於該主題中產生的消息會被所有實例監聽和消費，所以我們稱它為消息總線。
在總線上的各個實例都可以方便地廣播一些需要讓其他連接在該主題上的實例都知道的消息，例如配置信息的變更或者其他一些管理操作等。Bus 就是 Spring Cloud 中的消息總線。
其他方案，Apollo, Redis等。
如果網關需要抗每秒10萬的高並發訪問，你應該怎么對網關進行生產優化？
Zuul網關部署的是什么配置的機器，部署32核64G，對網關路由轉發的請求，每秒抗個小幾萬請求是不成問題的，幾台Zuul網關機器。
每秒是1萬請求，8核16G的機器部署Zuul網關，5台機器就夠了。
你們是如何基於網關實現灰度發布的？說說你們的灰度發布方案？
通過網關(Zuul, ZuulFilter)的發布開關，把少量流量導入到一兩台部署了新版本的服務器上，進行測試，這個就叫灰度發布。
開發流程：
1. 准備一個數據庫和一個表（也可以用Apollo配置中心、Redis、ZooKeeper，其實都可以），放一個灰度發布啟用表，存入具體uri以及是否灰度發布的一些信息，然后搞一張映射表。
2. 啟動1個線程每隔多少時間就去刷新灰度發布表的數據寫到ConcurrentHashMap里面。 接着搞一個filter繼承ZuulFilter，重寫里面幾個函數，其中shouldFilter根據返回值去判斷執不執行run。 因此再should里面遍歷map去看這次請求是否有開啟灰度發布，如果有就執行run里面的邏輯，就自定義一些分發邏輯，這里用的時通過version去判斷和分發。
灰度發布流程：
首先通過后台系統更改灰度發布標識，后台線程更新了map后，就會去執行根據version分發的策略，將少部分流量分發到new的服務上，然后監控和對應的后台，如果沒問題，就更改為current，全線上線，最后將灰度發布表示改回來。
說說你們一個服務從開發到上線，服務注冊、網關路由、服務調用的流程？
生產環境，微服務生產實踐：
開發了一個新的服務，線上部署，配合網關動態路由的功能，在網關里配置一下路徑和新服務的映射關系，此時請求過來直接就可以走到新的服務里去。
對已有服務進行迭代和開發，新版本，灰度發布，新版本部署少數幾台機器，通過一個界面，開啟這個服務的灰度發布，此時zuul filter啟用，按照你的規則，把少量的流量打入到新版本部署的機器上去。
觀察一下少量流量在新版本的機器上運行是否正常。
版本改成current，全量機器部署，關閉灰度發布功能，網關就會把流量均勻分發給那個服務了。
參考資料：
21天互聯網Java進階面試訓練營（分布式篇） -- 中華石杉