Soul網關由來?
Soul網關是我在任職某大型電商公司中間件技術部的時候所開發的。開源以後,針對不同的用戶需求,進行了功能的升級,比如 支持了springcloud
websocket
restful風格
get請求
,插件可以定製化開發等等,感謝開源。
當時我們面對什麼問題呢?
- 首先公司有很多語言,java,net,php,Python等等,相互之間的交互只能通過http,調用很不統一,尤其是java為主以後,php等語言要調用dubbo服務,dubbo服務者必須提供http服務出來,增加了java後端人員的工作量。
- 介面鑒權,限流,代理等等很多基本的需求,如果由每個業務系統開發人員開發,增加了成本,風險不可控。
- 所有的配置沒有統一化的管理頁面,不利於管理。
- 介面的性能沒有監控,不利於橫向擴展。
- 業務系統進行灰度發布,需要運維進行nginx負載,增加了運維的工作量。
- 等等很多很多的因素,我們需要一個可配置的,可視化,高性能的API網關,做為公司的公用服務。
當時我們怎麼解決的呢?
首先我們調研了市場上的一些API網關 zuul
kong
sc-gateway
zuul
是一個中間件產品,完全可以由業務系統自己去引入,性能沒達到我們的預期,沒有動態化的配置,不利於管理,和我們中間件技術部好像沒啥關係。
kong
kong確實是好,好到它的某些功能是收費的,而且它是lua語言開發,維護成本太高(其實就是hold不住lua)
sc-gateway
這個是基於webflux的,底層也是基於netty,性能可以,其缺點就是,沒有動態化的配置,而且也只是sc-cloud體系的,其他的業務系統怎麼接入? 怎麼做成公用服務?每次新上介面怎麼辦?動態調整介面的限流速率怎麼辦?等等很多問題。
so 基於以上問題,我們綜合考慮,決定自己干一個。我在做的時候,參考了kong的插件思想,sc-gateway的webflux思想,再結合公司的定製需求寫出了soul網關.
首先我們來看一張soul的架構圖,有利於加深它的運行原理