目的
- 避免讓客戶端感知微服務(wù)邊界的存在
- 不同的后端、前端團隊需要統(tǒng)一的接口設(shè)計、接入規(guī)范
思路
- API網(wǎng)關(guān)是請求進入系統(tǒng)的唯一節(jié)點
- API網(wǎng)關(guān)負(fù)責(zé)服務(wù)請求路由及協(xié)議轉(zhuǎn)換
- 它可能還具有其它職責(zé)，如身份驗證、權(quán)限控制、負(fù)載均衡、“請求整形”與管理
參考鏈接
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
功能
-
協(xié)議解析
以透明的方式實現(xiàn)Http到Rpc調(diào)用的轉(zhuǎn)換：
http請求到rpc調(diào)用實例的映射；
無類型的參數(shù)轉(zhuǎn)換為帶類型的參數(shù)；
api register
api request process
- 服務(wù)代理
-
組合調(diào)用
dubbo attachement提供了一種從consumer到provider的隱式傳參機制
attachement機制
dubbo notification機制
是擴展的從provider向consumer的旁路消息機制。
變更DubboCodec中encodeResponseData，增加notification寫入；
變更DecodeableRpcResult中decode，增加notification解析；
不同于attachement的傳遞屬性，默認(rèn)notification只傳遞給服務(wù)consumer不再向上傳遞，對于特定的notification需要一直向上傳遞我們通過DubboFilter機制實現(xiàn)copy and write隱式的完成特定notfication的連續(xù)傳播
notificaton機制
- 安全驗證
目的：api gateway作為外部訪問api的唯一入口，需要盡可能的攔截掉非正常請求，解析出真實的設(shè)備/用戶信息，再向微服務(wù)發(fā)起調(diào)用。
主要手段：設(shè)備識別；數(shù)字簽名； - 集中式日志與監(jiān)控
ELK:Elasticsearch(日志檢索引擎,OLAP)，Logstash(日志采集) Kibana(數(shù)據(jù)可視化)
Zabbix（系統(tǒng)監(jiān)控和通知）
使用es數(shù)據(jù)源，按照服務(wù)、錯誤碼等維度聚合錯誤 - 敏捷開發(fā)工具
靈感：SOAP使用WSDL進行stub生成
實現(xiàn)：ApiParser解析得到了完備的接口信息，基于這個信息我們采用模板技術(shù)(xslt/velocity/handlerbars)，生成出java/oc/js的客戶端調(diào)用代碼，以及在線文檔； - 熱發(fā)布(scan變?yōu)殡x線操作,推送ApiMethodInfo+Interface至apigateway，并動態(tài)創(chuàng)建新的代理實例，進行熱替換)
附圖
在項目啟動的時候，會連上zookeeper,進入docker，下載docker項目中的Jar包，并解析內(nèi)容
apigw代碼結(jié)構(gòu)分析
apigw一次http請求調(diào)用多個api時序圖
