隱藏細節 現實生活中有很多隱藏細節的案例，比如我們平時用的電腦，當我們按電源按鈕後電腦就自動開始啟動了，對用戶來講很簡單隻需要知道按按鈕就行。但電腦內部的工作原理其實是很複雜的一個流程，這裡不多說。 如果不隱藏細節會怎樣? 我想可能的結果就是電腦只能是特別特別的專業人員才能操作，永遠無法像現在一樣成 ...
隱藏細節
現實生活中有很多隱藏細節的案例，比如我們平時用的電腦，當我們按電源按鈕後電腦就自動開始啟動了，對用戶來講很簡單隻需要知道按按鈕就行。但電腦內部的工作原理其實是很複雜的一個流程，這裡不多說。
如果不隱藏細節會怎樣?
我想可能的結果就是電腦只能是特別特別的專業人員才能操作，永遠無法像現在一樣成為大家的必備工具。對大多數用戶來講他們根本不知道知道什麼CPU,記憶體，硬碟，顯卡相互之間是如何配合工作的，只關心打開電腦後能夠正常使用軟體完成他們的任務即可。
門面模式
在面向對象設計中，GOF有個門面模式就是對客戶端隱藏細節的一個典型應用，也可以看看我早幾年前的筆記：門面模式。
WEB API網關
通常WEB API網關是系統的唯一入口，它封裝了系統內部架構，為客戶端統一提供服務。有一些與業務無關的公共邏輯可以抽象到網關中實現，比如客戶端的認證，訪問控制，監控，緩存等，示意圖如下。
-
客戶端認證
無論是對內網還是外網的介面都是需要做用戶身份認證的，而用戶認證在一些規模大點的公司都會有統一的單點登錄系統，如果每個微服務系統都是做對接單點登錄系統的工作，那麼顯然比較浪費資源，開發效率低。可以將認證的部分抽取到網關層，然後微服務系統無需關註認證的邏輯只關註自身業務即可。 -
訪問控制
對一些特定的介面設置白名單，訪問次數，訪問頻率等各類設置。而這些非業務功能的配置以及變更不會影響微服務的實現可以在網關層單獨做操作。 -
負載均衡
可以靈活的在網關層制定負載均衡策略。 -
安全
可以統一在網關層增加一個額外的保護層來防止惡意攻擊，如果客戶端直連微服務的話，每個暴露的微服務都需要面臨安全問題。
WEB API網關在設計上與上面提供到門面模式是相當的，也是對客戶端隱藏細節。除了上面提供的那些常見公共功能外，還有如下一些實用的功能：
限流
對於大型互聯網項目還會有限流的需求。為了防止站點不被未知的大流量沖跨，有可能會採取限流的策略，網關配置一個閥值，當請求數超過閥值時就直接返回錯誤而不會走剩下的邏輯。
限流如何實現?限流的方案有很多:
- 在網關層可以利用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做反向代理去執行js，不懂APP，所以略過。
- Mobile API，H5以及APP唯一對接後端的入口，採用Spring MVC實現。裡面包含了所有前端需要用到的介面。
- 微服務，DUBBO實現的RPC,資料庫中間件mybatis。
- 緩存，基於Spring Cache+redis。
- 檢索系統，基於elasticsearch。
- 消息系統，RabbitMQ。上圖中沒有體現，是將業務數據更新到檢索系統的一個broker。
未用到限流，當時數據量太小，擔心的不是伺服器被沖跨是擔心沒人沖。
也不包含一些並行請求合併的高級用法，可以理解成一個高內聚的服務。
WEB API網關的優點
- 隱藏細節，對客戶端友好
- 簡化了客戶端開發複雜度
- 降低了客戶端與服務端交互交互
- 可統一做切麵任務，避免每個子系統各自為營，五花八門
- 使客戶端與服務端解耦，容易構造異構系統
WEB API網關的缺點
- 需要增加一個高可用伸縮性強的站點。
- WEB API網關項目在開發上是個串列任務，每暴露一個介面都需要去更新WEB API網關，如果同時有不同部門的需求去更新就會存在排隊更新的情況。
上面的缺點相對WEB API網關帶來的缺點是可以容忍的。
