理解WEB API Gateway，webapi網關

理解WEB API Gateway，webapi網關
隱藏細節

現實生活中有很多隱藏細節的案例，比如我們平時用的電腦，當我們按電源開關後電腦就自動開始啟動了，對使用者來講很簡單只需要知道按按鈕就行。但電腦內部的工作原理其實是很複雜的一個流程，這裡不多說。

如果不隱藏細節會怎樣?

我想可能的結果就是電腦只能是特別特別的專業人員才能操作，永遠無法像現在一樣成為大家的必備工具。對大多數使用者來講他們根本不知道知道什麼CPU,記憶體，硬碟，顯卡相互之間是如何配合工作的，只關心開啟電腦後能夠正常使用軟體完成他們的任務即可。

門面模式

在物件導向設計中，GOF有個門面模式就是對用戶端隱藏細節的一個典型應用，也可以看看我早幾年前的筆記：門面模式。

WEB API Gateway

通常WEB API Gateway是系統的唯一入口，它封裝了系統內部架構，為用戶端統一提供服務。有一些與業務無關的公用邏輯可以抽象到網關中實現，比如用戶端的認證，存取控制，監控，緩衝等，如下。

• 用戶端認證
  無論是對內網還是外網的介面都是需要做使用者身份認證的，而使用者認證在一些規模大點的公司都會有統一的單點登入系統，如果每個微服務系統都是做對接單點登入系統的工作，那麼顯然比較浪費資源，開發效率低。可以將認證的部分抽取到網關層，然後微服務系統無需關注認證的邏輯只關注自身業務即可。

• 存取控制
  對一些特定的介面設定白名單，訪問次數，訪問頻率等各類設定。而這些非業務功能的配置以及變更不會影響微服務的實現可以在網關層單獨做操作。

• 負載平衡
  可以靈活的在網關層制定負載平衡策略。

• 安全
  可以統一在網關層增加一個額外的保護層來防止惡意攻擊，如果用戶端直連微服務的話，每個暴露的微服務都需要面臨安全問題。

WEB API Gateway在設計上與上面提供到門面模式是相當的，也是對用戶端隱藏細節。除了上面提供的那些常見公用功能外，還有如下一些實用的功能：

限流

對於大型互連網項目還會有限流的需求。為了防止網站不被未知的大流量沖跨，有可能會採取限流的策略，網關配置一個閥值，當請求數超過閥值時就直接返回錯誤而不會走剩下的邏輯。

限流如何??限流的方案有很多:

• 在網關層可以利用hystrix來實現。
• 如果是針對待定的用戶端也可以利用nginx的限流。
• guava提供了一個RateLimiter，它是基於令牌桶的演算法實現，以固定的速率往隊列中放令牌，可以結合它自己實現限流可以結合它自己實現限流。

可相容更多的協議

比如有些服務是SOAP，基於二進位的Thrift,還有DUBBO這類RPC實現，可以統一轉換成HTTP來對外提供。

微服務帶來的問題

隨著業務的發展，原來簡單的系統會變得越來越複雜，一個團隊變成多個團隊，多個團隊同時在一個系統中開發會存在各種各樣的問題，資料量的增長也會使單庫的效能越來越慢，所以隨其自然的會按業務對系統進行垂直劃分，比如：

• 產品系統
• 價格系統
• 促銷系統
• 訂單系統
• 庫存系統
• 評論系統
• 推薦系統
• 使用者系統

這些系統當下比較流行的是以微服務的形式存在，暴露一批細粒度的介面給其它系統調用。

前端系統如何調用微服務？

比如使用者查看一個產品的明細頁面，它會包含產品基本資料，價格資訊，促銷資訊，推薦資訊，評論資訊等，按上面的微服務組成，前端系統想拿到產品的所有資料需要調用眾多的微服務，這在要求效能的互連網項目上是不太可行的，光http請求就比之前增加多倍，而且也會增加用戶端的複雜度，它需要知道所有這些微服務的詳細資料。

不要讓前端知道微服務的存在

即使系統從業務領域的層次上被劃分成多個獨立的微服務，但對於前端系統還是應該隱藏細節，提供粗粒度的介面。

系統架構

這裡回顧下以前我參與的一個跨境電商系統，從架構來看還是做的比較標準的。前端是APP以及H5，對接一個mobile api，mobile api內部包含各類子服務。

其實我們是針對項目的，電商系統對接mobile api，另外一個線下店的APP對接的新開發的store api。這兩個api是完全獨立的，並不是一個公司一個web api，所以說我們這兩web api是項目層級的網關，而有些公司可能會提供公司層級的網關。

架構簡要說明：

• 前端是APP+H5
• H5網站是通過Nginx做反向 Proxy去執行js，不懂APP，所以略過。
• Mobile API，H5以及APP唯一對接後端的入口，採用Spring MVC實現。裡麵包含了所有前端需要用到的介面。
• 微服務，DUBBO實現的RPC,資料庫中介軟體mybatis。
• 緩衝，基於Spring Cache+redis。
• 檢索系統，基於elasticsearch。
• 訊息系統，RabbitMQ。中沒有體現，是將業務資料更新到檢索系統的一個broker。

未用到限流，當時資料量太小，擔心的不是伺服器被沖跨是擔心沒人沖。
也不包含一些並行請求合并的進階用法，可以理解成一個高內聚的服務。

WEB API Gateway的優點

• 隱藏細節，對用戶端友好
• 簡化了用戶端開發複雜度
• 降低了用戶端與服務端互動互動
• 可統一做切面任務，避免每個子系統各自為營，五花八門
• 使用戶端與服務端解耦，容易構造異構系統

WEB API Gateway的缺點

• 需要增加一個高可用伸縮性強的網站。
• WEB API Gateway項目在開發上是個串列任務，每暴露一個介面都需要去更新WEB API Gateway，如果同時有不同部門的需求去更新就會存在排隊更新的情況。

上面的缺點相對WEB API Gateway帶來的缺點是可以容忍的。