參考文章：
簡而言之，bff就是伺服器設計api時會考慮到不同裝置的需求，也就是為不同的裝置提供不同的api介面，雖然它們可能是實現相同的功能，但因為不同裝置的特殊性，它們對服務端的api訪問也各有其特點，需要區別處理。因此出現了類似下圖一種設計方式。
以上兩張圖有相似點，也有不同之處。客戶端都不是直接訪問伺服器的公共介面，而是呼叫bff層提供的介面，bff層再呼叫基層的公共服務，不同的客戶端擁有不同的bff層，它們定製客戶端需要的api。圖一和圖二的不同之處在於是否需要為相似的裝置人，如ios和android分別提供乙個bff，這個需要根據現實情況決定，不同的專案環境解決手段不一樣。
那麼採用bff架構與多端公用、單一的api有什麼優點了？最重要的一點在上文中已經提到了，它能夠滿足因不同客戶端特殊的互動引起的對新介面的要求，所以一開始就會針對相應的裝置設計好對應的介面。如果使用單
一、通用的api，我們一開始並沒有考慮到特殊需求，那麼有新的請求需要出現時，可能會出現以下問題：
(1)如果新增新的介面，這樣容易造成介面的不穩定；
(2)如果考慮在原有的介面上進行修改，可能需要會產生一些的耦合，破壞單一職責。
微服務架構 BFF和閘道器
bff backend for frontend 和閘道器gateway是微服務架構中的兩個重要概念，這兩個概念相對比較新，有些開發人員甚至是架構師都不甚理解。本文用假想的公司案例 圖示的方式，解釋bff和閘道器是什麼，它們是怎麼演化出來的。希望對架構師設計和落地微服務架構有所啟發。我們先把時間推回...
了解 Linux核心架構 2
程序,程序切換,排程 傳統上,unix作業系統下執行的應用程式,伺服器及其他程式都稱為程序 processes 每個程序都在cpu的虛擬記憶體中分配位址空間 各程序的位址空間是完全獨立的,因此程序並不會意識到彼此的存在 從程序的角度來看,它會認為自己是系統中唯一的程序 如果程序想要彼此通訊 例如交換...
初步了解架構師
我們通常定義架構有幾個層次，分業務架構 產品架構 應用架構和技術架構。有了架構方 我們通常可以根據架構方 的指導來設計和規劃架構，而不再依賴於架構師本身的經驗來設計架構，也不會把架構當做藝術來發揮，發揮好的時候設計出來的是好架構，發揮不好的時候設計出來的就是壞架構。於是，按照行之有效的方 來做架構的...