淺談微服務與接口網關

互聯網技術突飛猛進，項目架構不斷升級優化。隨着企業微服務的興起和第三方API的發展，API網關這一做爲微服務核心組件的產品也逐漸被愈來愈多的人認識。微服務如何演變而來？網關在微服務中如何發揮做用？本文將以此做爲話題，聊聊API網關如何影響企業技術架構的演變。

1、互聯網架構的演變

1. 單體架構

計算機發展初期，又或者不少初創公司爲了快速開發的時候，會將應用程序的業務處理與數據處理都放在一塊兒，總體打包成應用程序，這就是單體架構。

優勢：足夠簡單、易於開發。
缺點：耦合度很是高，不易維護。

2. MVC架構

Web應用的興起，讓界面部分在瀏覽器展現，數據處理在服務器進行，兩個地方使用的語言也不一樣，先後端分離應運而生。項目裏也能夠分爲表現層、業務層、持久層、數據庫等，演變爲咱們常說的MVC架構。

優勢：井井有條，結構簡單，可分層測試。
缺點：擴展性不夠強，隨着模塊的增長，應用會愈發臃腫，維護難度相應加大。

3. 多應用架構

隨着業務量與用戶規模增大，一臺主機上提供的資源是有限的，因而漸漸把應用和數據分離開，把原來的一個應用按照業務特色拆分紅多個應用，它們之間各自獨立，不互相調用。像是一個電商系統一般會分爲用戶系統、商品系統、訂單系統等。

優勢：資源分散，方便維護。
缺點：分割後的應用各自獨立，共同業務的代碼沒法複用。

4. 分佈式架構

多應用存在代碼難以複用的問題，此時能夠考慮將公共服務提取出來，獨立部署，這樣一來，模塊也更容易拓展與維護。系統從多個應用變成一個個模塊化的服務組件，這就是分佈式架構。

優勢：應用解耦，不一樣團隊負責不一樣模塊，服務間可通訊。
缺點：架構開始複雜。

5. 微服務架構

當一個服務組件的粒度細化到API級別，經過一個或一組API提供完整功能，就演變成如今的微服務架構。微服務之間相互獨立，使用者無需配置環境，直接調用API便可完成開發。

優勢：服務獨立、易於開發測試、易於維護。
缺點：要進行微服務治理，包括服務註冊發現、API監控、認證鑑權、負載均衡等。

2、微服務的實現

要實現微服務，網關是必不可少的一環，網關承載着流量控制、監控告警、鑑權、參數校驗、路由轉發、緩存、負載均衡等工做。

網關是一個要求高併發、高可用、高性能的項目，在沒有開源項目的支撐下，本身開發網關是一個很是大的工做量。

秉承着開源精神，eoLinker推出國內首款企業級開源的Go語言網關—— GoKu Gateway。eoLinker擁有全面的API管理產品，Goku Gateway做爲eoLinker旗下的開源API網關，可以幫助企業整理內部API資源，進行API服務治理與維護，實現諸如鑑權、請求過濾、流控等需求。

一個GoKu能夠新建多個網關，每一個網關下包含策略組、API與後端服務，其中策略組包含了網關大多數的處理操做，包括鑑權、限流、IP黑白名單等。

GoKu特性：

部署簡單：基於golang，僅需一個go環境便可運行使用。
多種鑑權方式：支持Basic認證、API Key認證、IP認證等方式。
權限管理：針對不一樣策略組設置流控控制策略，包括QPS、訪問總次數、訪問IP、訪問時間段等。
IP黑白名單：支持全局IP白名單、也可自定義某個接口的IP白名單。
數據整形：支持參數的轉換與綁定，支持formdata、raw、json、file參數。
……
GoKu剛開源不久，不少地方有待完善，歡迎你們加入咱們的用戶討論羣：725853895，給咱們提意見，跟咱們交流想法。

項目地址：

• github：https://github.com/eolinker/G...
• gitee: https://gitee.com/eoLinker-AP...