前言
隨着工作室的產品、項目越來越多，運維、開發成本極速增加，也冒出了許許多多的問題。
運維上，我們的項目，都是統一從portal機器調用，通過nginx轉發到後端應用服務器。
開發上，我們需要做用戶權限認證、流量監控……我們目前的方案是每個APP自己寫權限認證，自己寫監控……所以每一位加入工作室的同學，都需要完整的開發一次從用戶鑑權到數據返回全鏈路調試過程。現在細細一品，有好處的地方是，按這種模式開發出項目的同學，都會學到很多東西，但是壞處顯然易見，門檻高，尤其是當鑑權涉及到微信授權登錄時，這導致我們招核心同學很艱難。同學們會開心的進來，但很快被難搞的技術嚇跑，我覺得這一方面，我難辭其咎，因爲技術團隊在我手裏，可用的人數太少，導致我們團隊校園產品毫無產出，而我當時很多精力卻是花在維護學長們留下的老項目的深淵裏，當然，維護項目的接鍋人目前培養好，抽出身的我，遂希望能通過對一些系統基礎建設進行改革，以幫助團隊能擴大自己規模，讓更多人加入我們團隊學到東西。
綜上，我們需要實現一個技術，方便我們提高運維開發效率，API網關就是其中需要調研的一部分。通過接入Api網關服務層，可以釋放出Api層的開發與維護工作，減少每個業務的重複開發工作，可以更專注與業務/服務邏輯實現。
考慮過兩種方案，網關服務and中臺服務。
網關服務，api調用，第一入口，統一調用、流量攔截入口。
中臺服務，內部調用平臺，可通過調用該平臺的接口，實現用戶權限獲取等等接口，流量入口由應用本身去實現，中臺只做通用(重複的）功能技術支持。
目前來說，我們的用戶表比較單一（學號、姓名），系統基本只需要維護一個用戶表即可，主要是維護各應用的權限，所以綜上，我偏向做api網關
名詞解釋
portal：可以理解爲流量入口服務器，所有的外部請求都從該入口進；
ApiGateway：業務Api網關服務，文中業務Api接入層亦指此服務；
nginx：一種高性能的http服務器；
功能需求
根據先有技術需求，以及未來展望，需求特點如下：
-
平臺化：
-
業務註冊與管理，聯動LB/TLB location/upstream變更
-
參數及策略配置、規則引擎與策略生成
-
策略下發，及時生效
-
-
身份鑑權：
- 統一校驗用戶、鑑權分級策略、Session降級策略
-
流量調度
- 負載均衡：支持sharding/RR/WRR/Rand等策略
-
穩定性
- 監控報警：統一監控、報警
- 過載保護：後端服務過載保護
- 降級策略：靈活降級策略
-
緩存策略
- 內存緩存、proxy緩存
-
流量檢查與清洗
-
安全檢查：參數檢查與過濾、防攻擊、防重放
-
反作弊：頻率控制、非法來源控制
-
技術方案
方案一：Nginx+Lua => OpenResty => Kong
Nginx穩定、成熟以及高性能的代理性質，工作室目前的Potal機器就是使用的Nginx作爲負載均衡Web服務器，目前規範是每一個應用創建一個.conf文件，然後也是由於業務拓展，越來越多的.conf文件缺乏管理。由於Nginx支持拓展，Lua很好的被利用實現拓展功能，我當時實習（Tencent）部門，中臺網關，就是這種方案，Lua寫代碼邏輯，Mysql存儲網關配置（比如應用的轉發配置）
But，學習成本很高，但是試圖看公司中臺網關代碼，就被C編譯給整懵了，門檻很高，沒有C、Lua語言編程基礎，很難上手。
OpenResty是以Nginx爲核心的Web開發平臺，可以解析執行Lua腳本；OpenResty與Lua的關係類似於Jvm與Java
Kong是一個OpenResty應用，一個api gateway。