【微服務理論】API + BFF 再也不爲兼容和適配煩惱

​

 對於微服務，常見的架構模型就是API網關+服務。

• API網關實現鑑權、負載均衡、中間件等公共入口邏輯。
• 服務實現具體的業務功能。

那麼，API網關設計中又有什麼坑呢？

1.0版本

直接將服務穿透到外網。 API層只是套了殼，加了鑑權、中間件而已。具體返回值由服務定。

• 客戶端到微服務直接通訊，強耦合。根本不敢重構，一改結構客戶端就崩了。
• 須要屢次請求，客戶端聚合數據，工做量巨大，延遲高。
  • 若是一個頁面由多個服務組成，好比商品、優惠券、相關推薦、評價。客戶端要請求多個接口，命名規則還不同。
  • 有的接口成功，有的接口失敗，須要客戶端本身作降級。
• 協議不利於統一，各個部門間有差別，須要客戶端端來兼容。
• 面向「端」的API適配，耦合到了內部服務。
  • 每一個服務都要爲不一樣的設備作適配代碼。
• 多終端兼容邏輯複雜，每一個服務都須要處理。
• 統一邏輯沒法收斂，好比安全認證、限流。

這樣就致使了客戶端、服務端都累得要死，誰都不討好。

2.0版本

架構就是一層加一層。

添加了一個BFF層，backend for forntend，專門作適配。

針對頁面提供接口，好比商品頁面，就一個接口，而後BFF層去調用多個服務，在這裏作降級，好比優惠券服務沒有返回就不顯示就完了。

客戶端只用和BFF層溝通，什麼適配、協議、兼容、定製都是這一層來作。客戶端感受很爽。

服務端也只用提供基礎數據，不用關心業務邏輯，不用管適配，返回的接口是什麼結構。服務端也很爽。

BFF層只作了數據裁剪，兼容之類的邏輯，輕不輕鬆？也很輕鬆。

問題：

• BFF單點了。也就是全部的流量都會到這一層， 若是有流量洪峯或者代碼有bug，全盤宕機。

3.0版本

將BFF根據業務拆分，好比查看商品一個，訂單頁面一個。這樣一個掛不會影響全局。

問題

• 不少跨橫切面邏輯，好比安全認證，日誌監控，限流熔斷等。隨着時間的推移，代碼變得愈來愈複雜，技術債越堆越多。

有沒有發現：

分久必合、合久必分。 分開了就有不能統一的地方，合併了就會單點故障。

4.0版本

​

將通用邏輯作到了API網關層，BFF層專一於業務邏輯。

API層採用Nginx這種高可用的軟件，基本不會掛，掛了重啓便可，限流、負載等邏輯用模塊實現，方便部署。 這一層徹底和業務無關。

總結

當耦合性過高的時候，就加一層，做爲緩衝。 當合並有單點的時候，就分開。當分開有不能統一的時候，就合併。

儘可能讓專門的人作專門的事情。減小業務對技術的耦合。

 我知道你們必定有好久都沒有注意到基礎這個點了，平時的工做應該也不多涉及到這些底層知識吧，可是這些東西很重要。若是是想要跳槽加薪或者是應對即將到來的面試，這些都是不可忽視的知識。在這一點裏，須要重視的點有：

• Java基礎篇： 基礎語法+集合+異常+反射+IO+TCP+多線程
• Java web篇： MySQL數據庫+JDBC+Servlet
• 三大框架篇： Spring+SpringMVC+MyBatis+商城實戰項目
• SpringBoot+SpringCloud分佈式開發篇： 微服務入門+實戰
• 項目經驗篇： 秒殺系統設計+SpringBoot商城實戰

Java 學習資料，包含了 Java 工程師必學的四大開源框架–MyBatis、Spring、Spring MVC、Spring Boot，視頻資料、大廠面試題等，須要的同窗能夠點擊這裏免費領取。

Java基礎篇

​

三大框架篇

​

微服務入門+實戰篇

​

項目經驗篇（秒殺+SpringBoot實戰）

​

以上整套學習資料均免費分享，須要的小夥伴，點擊下方的藍色字體能夠獲取，歡迎來白嫖哈~

點擊這裏的藍色字體能夠直接獲取

​