一加Ace2 Pro真機揭曉 鈦空灰配色質感拉滿
終于，在經過了幾波預熱之后，一加Ace2 Pro的外觀真機圖在網上出現了。還是博主數碼閑聊站曝光的，這次的外觀設計還是延續了一加11的方案，只是細節上有了調整，例如新加入了鈦空灰
在我們之前設計的一個供應鏈系統中，它包含了商品、銷售訂單、加盟商、門店運營、門店工單等服務，涉及了各種用戶角色，比如總部商品管理、總部門店管理、加盟商員工、門店人員等，而且每個部門的角色還會進行細分。而且這個系統中還包含了兩個客戶端 App：一個面向客戶，另一個面向公司員工和加盟商。
此時，整個供應鏈系統的架構如下圖所示：
上圖中的網關層主要負責路由、認證、監控、限流熔斷等工作。
此時，我們的架構看起來是不是挺完美？且市面上標準的 Spring Cloud 架構都是這樣做的。不過，這個架構會出現一些問題，下面我們先通過幾個例子來看看。
在這個供應鏈系統中，很多界面都需要顯示多個服務數據，比如在一個 App 首頁中，針對門店運營人員，需要顯示工單數量、最近的工單、銷售訂單數據、最近待處理的訂單、低于庫存安全值的商品等信息。
此時第一個問題來了，在接口設計過程中，我們經常糾結將兩個客戶端 App 調用的接口存放在哪個服務中？以至于決策效率低下，而且還會出現職責劃分不統一的情況。
最終我們決定將第一個接口存放在門店服務中，此時調用關系如下圖所示：
并將第二個接口存放在工單服務中，此時調用關系如下圖所示：
一個用戶的提交操作常常需要修改多個服務數據，比如一個提交工單的操作，我們需要修改庫存、銷售訂單狀態、工單等數據。
此時第二個問題出現了，因為這樣的需求非常多，所以服務經常被其他多個服務調來調去，導致服務之間的依賴非常混亂，最終服務調用關系如下圖所示：
通過上圖，我們發現服務間的依賴問題給技術迭代帶來了地獄般的體驗，關于這點我們已經在 15 講中進行了細致講解，這里就不過多贅述。
為了解決這 2 個問題，最終我們決定抽象一個 API 層。
一般來說，客戶端的接口需要滿足聚合、分布式調用、裝飾這三種需求。
因此，我們決定在客戶端與后臺服務之間增加一個新的 API 層，專門用來滿足上面的三點需求，此時整個架構如下圖所示。
從圖中我們發現，所有請求經過網關后，全部交由一個共用的 API 層進行處理，而該 API 層沒有自己的數據庫，它的主要職責是調用其他后臺服務。
通過這樣的設計方案后，以上兩個問題就得到了很多地解決。
此時，我們的設計方案完美了吧？別高興得太早，還會出現新的問題。
在這個供應鏈系統中，一系列的接口主要供各種客戶端（比如 App、H5、PC 網頁、小程序等）進行調用，此時的調用關系如下圖所示：
不過，這種設計方案會存在三個問題：
這時該如何解決呢？我們就可以考慮使用 BFF 了。
BFF 不是一個架構，而是一個設計模式，它的主要職責是為前端設計出優雅的后臺服務，即一個 API。一般而言，每個客戶端都有自己的 API 服務，此時整個架構如下圖所示：
從上圖可以看到：不同的客戶端請求經過同一個網關后，它們都將分別重定向到為對應客戶端設計的 API 服務中。因為每個 API 服務只能針對一種客戶端，所以它們可以對特定的客戶端進行專門優化。而去除了兼容邏輯的 API 顯得更輕便，響應速度還比通用的 API 服務更快（因為它不需要判斷不同客戶端的邏輯）。
除此之外，每種客戶端還可以實現自己發布，不需要再跟著其他客戶端一起排期。
此時的方案挺完美了吧？還不完美，因為上面的方案屬于一個通用架構。在實際業務中，我們還需要結合實際業務來定，下面我們深入說明一下實際業務需求。
前面我們列出了 5 種服務，實際上，整個供應鏈系統將近有 100 種服務。因為它是一個非常龐大的系統，且整個業務鏈條的所有工作都包含在這個系統中，比如新零售、供應鏈、財務、加盟商、售后、客服等，，這就需要幾百號研發人員同時進行維護。
因為我們共同維護一個 App、PC 界面、新零售、售后、加盟商，還有各自的小程序和 H5，所以為了實現業務解耦和分開排期，每個部門需要各自維護自己的 API 服務，而且 App 與 PC 前端也需要根據部門實現組件化，此時的架構如下圖所示。
針對以上需求，我們如何在技術架構上進行實現呢？下面具體來看看。
我們的整套架構還是基于 Spring Cloud 設計的，如下圖所示：
下面我們簡單介紹下圖中網關、API服務、后臺服務的作用。
此時的方案看著很完美了，不過它會出現 API 之間代碼重復問題。此時我們該如何解決？且往下看。
雖然 H5 與小程序的布局不同，但是頁面中很多功能一致，也就是說重復的代碼邏輯主要存在 PC API 和 App API 中。
然而，針對重復代碼的問題，不同部門在設計時會呈現 3 種不同的邏輯：
假如某些 API 服務提供接口的出入參與后臺服務的一致，此時該怎么辦？ 此時 API 服務的接口無須做任何事情，因為它只是一個簡單的代理層。
于是，有同事提出：“每次一看到這些純代理的 API 接口就不爽，我們能不能想辦法把它們去掉。”辦法倒是有幾個，我們一起來看看。
網關直接繞過 API 服務調用后臺服務，不過這樣就會破壞分層，所以很快被否掉了。
在 API 服務層做一個攔截器，如果 URI 找不到對應 API 服務中的 controller mapping，就會直接通過 URI 找后臺服務并進行調用。不過這種方式將大大增加系統的復雜度，出問題時調查起來更麻煩且收益不大。而寫這些無腦代碼不僅成本低，整體的接口列表還更可控。
綜合考慮后，最終我們決定保留無腦的代碼。
最后我們是這樣分工的：專門的 API 開發團隊負責 API 服務，而后臺服務需要根據領域再劃分小組的職責。
這種劃分方式的好處在于 API 團隊能對所有服務有個整體認識，且不會出現后臺服務劃分不清晰、工作重復的情況。而壞處在于 API 團隊整體業務邏輯偏簡單，長久留不住人。
本文鏈接：http://www.www897cc.com/showinfo-26-85542-0.html如何處理好微服務之間千絲萬縷的關系？到BFF大顯身手了
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： C# 讀寫 JSON 配置文件詳解
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號