在當(dāng)前的系統(tǒng)架構(gòu)中，微服務(wù)架構(gòu)大行其道，在微服務(wù)架構(gòu)中一個很重要的組件就是API網(wǎng)關(guān)。
API網(wǎng)關(guān)是一個服務(wù)器，是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的API。它可能還具有其它職責(zé)，如身份驗證、監(jiān)控、負(fù)載均衡、緩存、請求分片與管理、靜態(tài)響應(yīng)處理。 --百度
微服務(wù)本身當(dāng)然需要有效的監(jiān)控管理，而API作為微服務(wù)對外提供的核心能力，同樣需要進行細致、高效的管控。
一個強大、高效、可靠、可控的API網(wǎng)關(guān)可以極大的提升對整個系統(tǒng)架構(gòu)下的微服務(wù)API的梳理、管控能力，使得API用的放心，管的舒心。
目前業(yè)界也有多款成熟的API網(wǎng)關(guān)可用:Kong、Zuul、Traefik、Spring
Cloud Gateway等等
- Kong
基于Nginx+Lua開發(fā)，性能高，穩(wěn)定，有多個可用的插件(限流、鑒權(quán)等等)可以開箱即用。
問題：只支持Http協(xié)議；二次開發(fā)，自由擴展困難；提供管理API，缺乏更易用的管控、配置方式。 - Zuul
Netflix開源，功能豐富，使用JAVA開發(fā)，易于二次開發(fā)；需要運行在web容器中，如Tomcat。
問題：缺乏管控，無法動態(tài)配置；依賴組件較多；處理Http請求依賴的是Web容器，性能不如Nginx； - Traefik
Go語言開發(fā)；輕量易用；提供大多數(shù)的功能：服務(wù)路由，負(fù)載均衡等等；提供WebUI
問題：二進制文件部署，二次開發(fā)難度大；UI更多的是監(jiān)控，缺乏配置、管理能力； - Spring Cloud Gateway & Zuul2
開發(fā)完善中，期待一下。。。
綜合比較一番后，除了常規(guī)的API網(wǎng)關(guān)應(yīng)有的能力外，（我的）理想中的API網(wǎng)關(guān)要有哪些能力呢？
- 協(xié)議轉(zhuǎn)換
上游服務(wù)多種多樣，雖然現(xiàn)在流行Spring Cloud架構(gòu)，直接提供Http協(xié)議的服務(wù)API，但是毫無疑問，還是后端系統(tǒng)間采用RPC調(diào)用的較多，如果API網(wǎng)關(guān)可以對此類服務(wù)進行協(xié)議轉(zhuǎn)換，對外將其適配為HTTP接口，對內(nèi)仍為RPC調(diào)用，這無疑可以極大的提升系統(tǒng)整體性能，同時不用約束上游系統(tǒng)的實現(xiàn)方式，雙贏！ - 動態(tài)配置
API網(wǎng)關(guān)必然需要和多個系統(tǒng)打交道，一些配置工作如:路由映射，超時配置，服務(wù)地址，權(quán)重調(diào)整等等是必不可少的了，動態(tài)配置，動態(tài)加載，實時生效是一個提升穩(wěn)定性的有效手段。 - 管控平臺
API網(wǎng)關(guān)是一個承前啟后的重要節(jié)點，其管理著大量的來自不同系統(tǒng)的API，每時每刻都會有大量的請求通過API網(wǎng)關(guān)到達不同的上游系統(tǒng)服務(wù)，同樣有大量的響應(yīng)從上游回到API網(wǎng)關(guān)，并最終發(fā)送給調(diào)用者，除非所有服務(wù)的API永不出錯，否則一個高效的管控平臺必不可少！更重要的是不但要監(jiān)控，更可以管理！
腦海中的Pampas
腦洞開一開，我需要的API網(wǎng)關(guān)大概應(yīng)該是這個樣_
image.png
造出來
把想法實現(xiàn)出來是一件有意思的事。
附上github項目地址……
PAMPAS@github
PAMPAS-UI@github
歡迎貢獻Idea和Code
