閱讀對象
傳統企業正在做微服務架構轉型的開發人員或者架構師，希望本文對您能起到一定的引導作用。
API網關介紹
網關一詞較早出現在網絡設備裡面，比如兩個相互獨立的局域網段之間通過路由器或者橋接設備進行通信， 這中間的路由或者橋接設備我們稱之為網關。
相應的API網關將各系統對外暴露的服務聚合起來，所有要調用這些服務的系統都需要通過API網關進行訪問，基於這種方式網關可以對API進行統一管控，例如：認證、鑑權、流量控制、協議轉換、監控等等。
API網關的流行得益於近幾年微服務架構的興起，原本一個龐大的業務系統被拆分成許多粒度更小的系統進行獨立部署和維護，這種模式勢必會帶來更多的跨系統交互，企業API的規模也會成倍增加，API網關（或者微服務網關）就逐漸成為了微服務架構的標配組件。
如下是我們整理的API網關的幾種典型應用場景：
1、面向Web或者移動App
這類場景，在物理形態上類似前後端分離，前端應用通過API調用後端服務，需要網關具有認證、鑑權、緩存、服務編排、監控告警等功能。
2、面向合作伙伴開放API
這類場景，主要為了滿足業務形態對外開放，與企業外部合作伙伴建立生態圈，此時的API 網關注重安全認證、權限分級、流量管控、緩存等功能的建設。
3、企業內部系統互聯互通
對於中大型的企業內部往往有幾十、甚至上百個系統，尤其是微服務架構的興起系統數量更是急劇增加。系統之間相互依賴，逐漸形成網狀調用關係不便於管理和維護，需要API網關進行統一的認證、鑑權、流量管控、超時熔斷、監控告警管理，從而提高系統的穩定性、降低重複建設、運維管理等成本。
設計目標
純Java實現；
-
支持插件化，方便開發人員自定義組件；
支持橫向擴展，高性能；
避免單點故障，穩定性要高，不能因為某個API故障導致整個網關停止服務；
管理控制檯配置更新可自動生效，不需要重啟網關；
應用架構設計
說明：
1、網關核心子系統通過HAProxy或者Nginx進行負載均衡，為避免正好路由的LB節點服務不可用，可以考慮在此基礎上增加Keepalived來實現LB的失效備援，當LB Node1停止服務，Keepalived會將虛擬IP自動飄移到LB Node2，從而避免因為負載均衡器導致單點故障。DNS可以直接指向Keepalived的虛擬IP。
2、網關除了對性能要求很高外，對穩定性也有很高的要求，引入Zookeeper及時將Admin對API的配置更改同步刷新到各網關節點。
3、管理中心和監控中心可以採用類似網關子系統的高可用策略，如果嫌麻煩管理中心可以省去Keepalived，相對來說管理中心沒有這麼高的可用性要求。
4、理論上監控中心需要承載很大的數據量，比如有1000個API，平均每個API一天調用10萬次，對於很多互聯網公司單個API的量遠遠大於10萬，如果將每次調用的信息都存儲起來太浪費，也沒有太大的必要。可以考慮將API每分鐘的調用情況彙總後進行存儲，比如1分鐘的平均響應時間、調用次數、流量、正確率等等。
5、數據庫選型可以靈活考慮，原則上網關在運行時要儘可能減少對DB的依賴，否則IO延時會嚴重影響網關性能。可以考慮首次訪問後將API配置信息緩存，Admin對API配置更改後通過Zookeeper通知網關刷新，這樣一來DB的訪問量可以忽略不計，團隊可根據自身偏好靈活選型。
非阻塞式HTTP服務
管理和監控中心可以根據團隊的情況採用自己熟悉的Servlet容器部署，網關核心子系統對性能的要求非常高，考慮採用NIO的網絡模型，實現純HTTP服務即可，不需要實現Servlet容器，推薦Netty框架（設計優雅，大名鼎鼎的Spring Webflux默認都是使用的Netty，更多的優勢就不在此詳述了），內部測試在相同的機器上分別通過Tomcat和Netty生成UUID，Netty的性能大約有20%的提升，如果後端服務響應耗時較高的話吞吐量還有更大的提升。（補充：Netty4.x的版本即可，不要採用5以上的版本，有嚴重的缺陷沒有解決）
採用Netty作為Http容器首先需要解決的是Http協議的解析和封裝，好在Netty本身提供了這樣的Handler
閱讀更多 Java進階架構師 的文章
