BFF — Backends For Frontends 前计。在后來的學(xué)習(xí)和工作經(jīng)驗(yàn)累積中逐步的加深了對(duì) BFF 的理解，這個(gè)模式它具有更加確切的一些使用場(chǎng)景以及解決的是一些更加特定的問題。本篇小作文中肉迫，從找到 BFF 的起源開始弄跌，回到 BFF 模式誕生的大背景下，去探索那個(gè)特殊環(huán)境下遇到了什么樣的問題催生出了這個(gè)在微服務(wù)系統(tǒng)中出鏡率極高的模式虏两。
尋找源頭
首先愧旦，從技術(shù)雷達(dá)（https://www.thoughtworks.com/radar/techniques/bff-backend-for-frontends）中 BFF 的條目上，可以找到一些蛛絲馬跡定罢。條目的發(fā)布時(shí)間是 2015 年 11 月10 日笤虫。接著，我們?cè)诠雀杷阉麝P(guān)鍵字Backend for Frontend 以及將時(shí)間范圍限定在 2015 年 1 月 1 日到 2015 年 11 月 10 日祖凫。
接下來琼蚯，對(duì)比搜索結(jié)果的時(shí)間，我找到最早出現(xiàn) Backend for Frontend 詞條的文章（https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html）蝙场。
文中提到凌停，BFF 這個(gè)名字是被當(dāng)時(shí)團(tuán)隊(duì) TechLeader Nick Fisher（https://twitter.com/spadgos）提出的，并最后在團(tuán)隊(duì)投票后被采納售滤。為了萬(wàn)無(wú)一失罚拟，找到其他的交叉證據(jù)，我才能更加確定這個(gè)結(jié)果完箩。非常幸運(yùn)的是赐俗，在洞見文章（https://www.thoughtworks.com/insights/blog/bff-soundcloud）也提到了相同的結(jié)論。由此弊知，我們可以說 BFF 模式是在 SoundCloud（https://zh.wikipedia.org/zh-hans/SoundCloud） 首次出現(xiàn)阻逮。接著，讓我們一起回到BFF 第一次發(fā)揮威力的現(xiàn)場(chǎng)吧秩彤。
問題初現(xiàn)
為了更有條理的了解當(dāng)年SoundCloud 遇到了什么樣的挑戰(zhàn)叔扼，我通過分類分項(xiàng)的方式來列舉情況和分析。
-
背景：
SoundCloud（https://blog.sellfy.com/make-more-money-on-soundcloud/）
主要是通過付費(fèi)訂閱與廣告進(jìn)行盈利（也就是說漫雷，越多的曝光渠道瓜富，會(huì)給SoundCloud 帶來更多的盈利機(jī)會(huì)）SoundCloud 是一個(gè)單體系統(tǒng)，通過暴露共享 API 的方式為 Web 客戶端降盹、Android 和 iOS 應(yīng)用程序以及互聯(lián)網(wǎng)与柑、合作伙伴等提供服務(wù)。這些共享 API 隨著功能和特性一起增長(zhǎng)，最終變成了平臺(tái)與客戶端之間的集成點(diǎn)价捧。
將 2007 年開始運(yùn)行的 SoundCloud 從單體模式轉(zhuǎn)變至微服務(wù)模式 （具體改造過程：https://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html）丑念。
此時(shí)，單體服務(wù)已經(jīng)被拆分為多個(gè)微服務(wù)结蟋。-
支持在 IOS 平臺(tái)上新增的應(yīng)用程序（原來的產(chǎn)品主要是在 Web 端提供服務(wù)）
Public.png
- 主要?jiǎng)訖C(jī)：
- 減少產(chǎn)品發(fā)布上線的時(shí)間
- 支持 IOS 平臺(tái)的新應(yīng)用程序脯倚，隔離其不同用戶體驗(yàn)和交互模式帶來的風(fēng)險(xiǎn)
-
挑戰(zhàn)：
為了讓第三方開發(fā)人員能更自由的集成，需要設(shè)計(jì)出不對(duì)數(shù)據(jù)的使用方式做出任何假設(shè)的 API椎眯。 所以挠将，即便是呈現(xiàn)很簡(jiǎn)單的體驗(yàn)，也需要許多的 HTTP API 來提供服務(wù)编整。導(dǎo)致了構(gòu)建一個(gè)簡(jiǎn)單的頁(yè)面的數(shù)據(jù)需要上百個(gè) API 請(qǐng)求來獲取舔稀。
每次團(tuán)隊(duì)需要更改現(xiàn)有API 時(shí)，都需要確保更改不會(huì)破壞我們現(xiàn)有的任何客戶端（包括重要的第三方集成）掌测。每當(dāng)添加新內(nèi)容内贮，都必須投入大量時(shí)間來確保新功能不會(huì)過度用于特定客戶端，以便所有客戶都可以輕松使用新功能汞斧。 所有這些協(xié)調(diào)使日常工作變得比應(yīng)有的困難得多夜郁，也就導(dǎo)致了新功能發(fā)布緩慢。
開始準(zhǔn)備開發(fā)新 iOS 應(yīng)用程序粘勒， 新平臺(tái)上的應(yīng)用程序的用戶體驗(yàn)會(huì)全部被重塑
通過分析上面的各種情況竞端，可以得出當(dāng)時(shí)SoundCloud 后端團(tuán)隊(duì)面對(duì)的如下幾個(gè)問題：
問題一：難以為每個(gè)第三方客戶提供合適粒度的 API，導(dǎo)致了 API 數(shù)據(jù)粒度過細(xì)庙睡，想完成一個(gè)業(yè)務(wù)服務(wù)需要請(qǐng)求的 API 太多事富。
問題二：現(xiàn)有的對(duì)外 API 與消費(fèi)方耦合嚴(yán)重，維護(hù)成本高乘陪，時(shí)間長(zhǎng)统台，新功能發(fā)布緩慢。
-
問題三：IOS平臺(tái)新客戶端更進(jìn)了用戶體驗(yàn)和交互方式啡邑，需要隔離新App帶來的風(fēng)險(xiǎn)贱勃，并且還要找到與多個(gè)客戶端團(tuán)隊(duì)更好的合作方式。
看上去谤逼，這三個(gè)問題在通常后端團(tuán)隊(duì)在完成微服務(wù)改造中往往也會(huì)遇到贵扰。讓我們一起看看，他們是如何一步步見招拆招解決問題流部，并且找到《BFF》這個(gè)內(nèi)功心法的戚绕。
Backends For Frontends 初成
SoundCloud 后端團(tuán)隊(duì)在面對(duì)上面復(fù)雜的問題時(shí)顯得非常的專業(yè)。他們一開始便決定了贵涵，通過對(duì)不同客戶端提供不同的 API 來各個(gè)擊破列肢。避免重蹈覆轍，多個(gè)客戶端依賴同一套 API宾茂，繼而耦合需求重合瓷马，無(wú)法進(jìn)行靈活變更。同時(shí)跨晴，后端 Tech Lead Nick Fisher 創(chuàng)造了 BFF 這個(gè)縮寫欧聘，也在團(tuán)隊(duì)內(nèi)通過投票被認(rèn)可。BFF 終于出現(xiàn)在技術(shù)世界的舞臺(tái)之上端盆，當(dāng)時(shí)的架構(gòu)如下圖所示怀骤。
你會(huì)發(fā)現(xiàn)與現(xiàn)在使用 BFF 模式的架構(gòu)圖有些細(xì)微的差別。沒錯(cuò)焕妙，現(xiàn)在 BFF 還沒真正的進(jìn)化到成熟模式蒋伦。接下來讓我們看看它是在什么契機(jī)之下發(fā)生了進(jìn)化。
后續(xù)的的研發(fā)中客戶端團(tuán)隊(duì)意識(shí)到焚鹊。由于他們擁有 API痕届， 他們可以提取對(duì)不同服務(wù)進(jìn)行多次調(diào)用的所有邏輯，并將它們混合到后端的用戶配置文件中末患。這將簡(jiǎn)化代碼并提高性能研叫。不是對(duì)后端服務(wù)多次不同的調(diào)用，而是客戶端對(duì)單個(gè)資源簡(jiǎn)單請(qǐng)求璧针，例如：
-
GET /user-profile/123.json
當(dāng)后端團(tuán)隊(duì)進(jìn)一步試驗(yàn)這個(gè)方式時(shí)嚷炉，他們發(fā)現(xiàn)了自己在 BFF 中編寫了很多 Presentation Model。 在這個(gè)時(shí)候探橱，他們突然意識(shí)到 BFF 不只是被客戶端使用的 API 申屹，而是 BFF 本身就是申請(qǐng)的一部分。BFF 新的形態(tài)出現(xiàn)了走搁，具體如下圖所示：
滴答滴答独柑，時(shí)鐘在前進(jìn)，SoundCloud 的 BFF 也在持續(xù)增加私植。這時(shí)忌栅，他們已經(jīng)在生產(chǎn)環(huán)境同時(shí)維護(hù)著 5 個(gè) BFF 了。為了進(jìn)一步提高生產(chǎn)力曲稼，減少不必要的重復(fù)索绪。 User Profile 從每個(gè)不同的微服務(wù)中抽取出來，變成一個(gè)獨(dú)立的在 service 與 BFF 之間的應(yīng)用服務(wù)贫悄。隨著時(shí)間的推移瑞驱，他們發(fā)現(xiàn)了越來越多這樣的情況。現(xiàn)在 SoundCloud 的 BFF 顯然隨著時(shí)間的推移而增長(zhǎng)窄坦，這種橫向增長(zhǎng)再不會(huì)引起任何問題了唤反。最終凳寺，BFF 模式的架構(gòu)變成下圖：
結(jié)論
BFF 模式為我們?cè)谑褂梦⒎?wù)時(shí)，針對(duì)多客戶端開發(fā)的問題彤侍，提供了一種很好的方法肠缨。使我們?cè)跇?gòu)建面向客戶端的后端團(tuán)隊(duì)能夠掌控自己的命運(yùn)。 這種自主性對(duì)于快速迭代客戶端應(yīng)用程序并快速提供良好的體驗(yàn)至關(guān)重要盏阶。 通過支持持續(xù)的演進(jìn)和變化晒奕，通過這種模式可以將消費(fèi)者的行為限制在一個(gè)可控范圍，會(huì)使他們變的更容易合作和改變名斟。并且脑慧，更好滿足不同客戶端不同的特性需求。如果砰盐，在系統(tǒng)建立一開始便希望所有東西都是可復(fù)用的闷袒，會(huì)給系統(tǒng)的維護(hù)和協(xié)調(diào)帶來巨大的挑戰(zhàn)。特別是在面對(duì)需要維護(hù)多個(gè)客戶端或消費(fèi)者的場(chǎng)景下岩梳。在考慮通用用法之前霜运，請(qǐng)專注于您的功能和特定用例。再在了解情況的基礎(chǔ)上逐步進(jìn)行低成本和合理的通用和復(fù)用蒋腮。
