1.API-gateway(含義)
所有API的調用統一接入API網關層，由網關層負責接入和輸出。
API Gateway是一個服務器，也可以說是進入系統的唯一節點。這跟面向對象設計模式中的Facade模式很像。API Gateway封裝內部系統的架構，並且提供API給各個客戶端.
2.gateway功能
一個API網關的基本功能包含了統一接入、協議適配、流量管理與容錯、以及安全防護，這四大基本功能構成了網關的核心功能。
1)統一接入 系統中所有請求，都走該網關
2)協議適配 將請求的協議轉換成內部的協議接口，如用戶發起請求的接口是HTTP，但是下游的接口類型卻為RPC或者JSF。
3)流量管理和容錯 在調用過程中限流、降級、熔斷等方式來保護網關的整體穩定
4)安全防護 防刷控制、黑白名單等措施
3.為何要用網關?
舉個栗子
下面的圖展示了你在淘寶客戶端上滑動產品最終頁時看到的信息
雖然這是一個智能手機應用，這個產品最終頁展示了非常多的信息。例如，不僅這里有產品基本信息（名字、描述和價格），還有以下內容：
- 購物車中的物品數
- 下單歷史
- 用戶評論
- 低庫存警告
- 快遞選項
- 各式各樣的推薦，包括經常跟這個物品一起被購買的產品、購買該物品的其他顧客購買的產品以及購買該產品的顧客還瀏覽了哪些產品。
- 可選的購物選項
當采用一個單體式應用架構，一個移動客戶端將會通過一個REST請求（GET api.company.com/productdetails/productId）來獲取這些數據。一個負載均衡將請求分發到多個應用實例之一。應用將查詢各種數據庫並返回請求給客戶端。
相對的，若是采用微服務架構，最終頁上的數據會分布在不同的微服務上。下面列舉了可能與產品最終頁數據有關的一些微服務：
- 購物車服務 -- 購物車中的物品數
- 下單服務 -- 下單歷史
- 分類服務 -- 基本產品信息，如名字、圖片和價格
- 評論服務 -- 用戶評論
- 庫存服務 -- 低庫存警告
- 快遞服務 -- 快遞選項、截止時間、來自不同快遞API的成本計算
- 推薦服務 -- 推薦產品
客戶端到微服務直接通信
如上圖所示，如果用戶想展示次頁面，需要請求客戶端需要7次單獨請求。在更復雜的場景中，可能會需要更多次請求。雖然一個客戶端可以通過LAN發起很多個請求，但是在公網上這樣會很沒有效率，這個問題在移動互聯網上尤為突出。總之就是客戶端單獨請求多個服務賊費勁。
另一個存在的問題是客戶端直接請求微服務的協議可能並不是web友好型。一個服務可能是用Thrift的RPC協議，而另一個服務可能是用AMQP消息協議。它們都不是瀏覽或防火牆友好的，並且最好是內部使用。應用應該在防火牆外采用類似HTTP或者WEBSocket協議。總之就是用戶訪問協議不友好，不同應用端提供協議不統一。
這個方案的另一個缺點是它很難重構微服務。隨着時間的推移，我們可能需要改變系統微服務目前的切分方案。例如，我們可能需要將兩個服務合並或者將一個服務拆分為多個。但是，如果客戶端直接與微服務交互，那么這種重構就很難實施。無論是對以后的研發重構難度，還是對於用戶灰度體驗都極差。
采用一個API Gateway
基於以上種種原因，網關方式誕生了。
1.客戶端的請求多個服務，我直接在網關處統一封裝，返回統一結果集，就用戶而言請求一次或者少幾次。暴漏粗粒度接口給前端。
2.用戶可以直接http訪問，不同項目里協議轉換，轉換成跟客戶端兼容的協議。
4.API-Gateway基礎架構
1）網關運行良好的環境還包括注冊中心（比如：ZK讀取已發布的API接口的動態配置）
2）為了實現高性能，將數據全部異構到緩存（如：Redis）中，同時還可以配合本地緩存來進一步提高網關系統的性能
3) 為了提高網關的吞吐率，可以使用NIO+Servlet 3 異步的方式，還可以利用Servlet 3 的異步特性將請求線程與業務線程分開，為后續的線程池隔離做好基本的支撐
4) 訪問日志的存儲我們可以放到Hbase中
5) 開放網關使用，那么需要一個支持OAuth2.0的授權中心
6) 還可以引入Nginx + lua的方式將一些基本的校驗判斷放到應用系統之上，這樣可以更輕量化的處理接入的問題
5.網關的技術選型
- SpringCloud-Zuul : 社區活躍,基於 SrpingCloud 完整生態, 是構建微服務體系前置網關服務的最佳選型.
- Kong : 基於OpenResty的 API 網關服務和網關服務管理層.
- 自建網關服務: 如 談談基於 OpenResty 的接口網關設計
感謝博主：
https://cloud.tencent.com/developer/article/1440628