理解WEB API閘道器

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

如果不隱藏細節會怎樣?

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

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

通常web api閘道器是系統的唯一入口，它封裝了系統內部架構，為客戶端統一提供服務。有一些與業務無關的公共邏輯可以抽象到閘道器中實現，比如客戶端的認證，訪問控制，監控，快取等，示意圖如下。

對於大型網際網路專案還會有限流的需求。為了防止站點不被未知的大流量衝跨，有可能會採取限流的策略，閘道器配置乙個閥值，當請求數超過閥值時就直接返回錯誤而不會走剩下的邏輯。

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

比如有些服務是soap，基於二進位制的thrift,還有dubbo這類rpc實現，可以統一轉換成http來對外提供。

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

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

前端系統如何呼叫微服務？

按上面的微服務組成，前端系統想拿到產品的所有資料需要呼叫眾多的微服務，這在要求效能的網際網路專案上是不太可行的，光http請求就比之前增加多倍，而且也會增加客戶端的複雜度，它需要知道所有這些微服務的詳細資訊。

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

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

架構簡要說明：

微服務，dubbo實現的rpc,資料庫中介軟體mybatis。

快取，基於spring cache+redis。

檢索系統，基於elasticsearch。

訊息系統，rabbitmq。上圖中沒有體現，是將業務資料更新到檢索系統的乙個broker。

未用到限流，當時資料量太小，擔心的不是伺服器被衝跨是擔心沒人衝。

也不包含一些並行請求合併的高階用法，可以理解成乙個高內聚的服務。