微服務(wù)架構(gòu)，這個(gè)在幾年前還算比較前衛(wèi)的技術(shù)在如今遍地開(kāi)花。得益于開(kāi)源社區(qū)的支持，我們可以輕松地利用 Spring Cloud 以及 Docker 容器化快速搭建一個(gè)微服務(wù)架構(gòu)的原型。不管是成熟的互聯(lián)網(wǎng)公司、創(chuàng)業(yè)公司還是個(gè)人開(kāi)發(fā)者，對(duì)于微服務(wù)架構(gòu)的接納程度都相當(dāng)高，微服務(wù)架構(gòu)的廣泛應(yīng)用也自然促進(jìn)了技術(shù)本身更好的發(fā)展以及更多的實(shí)踐。本文將結(jié)合項(xiàng)目實(shí)踐，剖析在微服務(wù)的背景下，如何通過(guò)前后端分離的方式開(kāi)發(fā)移動(dòng)應(yīng)用。

[[226918]]

對(duì)于微服務(wù)本身，我們可以參考 Martin Fowler 對(duì) Microservice 的闡述。簡(jiǎn)單說(shuō)來(lái)，微服務(wù)是一種架構(gòu)風(fēng)格。通過(guò)對(duì)特定業(yè)務(wù)領(lǐng)域的分析與建模，將復(fù)雜的應(yīng)用分解成小而專一、耦合度低并且高度自治的一組服務(wù)。微服務(wù)中的每個(gè)服務(wù)都是很小的應(yīng)用，這些應(yīng)用服務(wù)相互獨(dú)立并且可部署。微服務(wù)通過(guò)對(duì)復(fù)雜應(yīng)用的拆分，達(dá)到簡(jiǎn)化應(yīng)用的目的，而這些耦合度較低的服務(wù)則通過(guò) API 形式進(jìn)行通信，所以服務(wù)之間對(duì)外暴露的都是 API，不管是對(duì)資源的獲取還是修改。

微服務(wù)架構(gòu)的這種理念，和前后端分離的理念不謀而合，前端應(yīng)用控制自己所有的 UI 層面的邏輯，而數(shù)據(jù)層面則通過(guò)對(duì)微服務(wù)系統(tǒng)的 API 調(diào)用完成。以 JSP (Java Server Pages) 為代表的前后端交互方式也逐漸退出歷史舞臺(tái)。前后端分離的迅速發(fā)展也得益于前端 Web 框架 (Angular, React 等) 的不斷涌現(xiàn)，單頁(yè)面應(yīng)用(Single Page Application)迅速成為了一種前端開(kāi)發(fā)標(biāo)準(zhǔn)范式。加之移動(dòng)互聯(lián)網(wǎng)的發(fā)展，不管是 Mobile Native 開(kāi)發(fā)方式，還是 React Native / PhoneGap 之流代表的 Hybrid 應(yīng)用開(kāi)發(fā)方式，前后端分離讓 Web 和移動(dòng)應(yīng)用成為了客戶端。客戶端只需要通過(guò) API 進(jìn)行資源的查詢以及修改即可。

一、BFF 概況及演進(jìn)

Backend for Frontends(以下簡(jiǎn)稱BFF) 顧名思義，是為前端而存在的后端(服務(wù))中間層。即傳統(tǒng)的前后端分離應(yīng)用中，前端應(yīng)用直接調(diào)用后端服務(wù)，后端服務(wù)再根據(jù)相關(guān)的業(yè)務(wù)邏輯進(jìn)行數(shù)據(jù)的增刪查改等。那么引用了 BFF 之后，前端應(yīng)用將直接和 BFF 通信，BFF 再和后端進(jìn)行 API 通信，所以本質(zhì)上來(lái)說(shuō)，BFF 更像是一種“中間層”服務(wù)。下圖看到?jīng)]有BFF以及加入BFF的前后端項(xiàng)目上的主要區(qū)別。

1. 沒(méi)有BFF 的前后端架構(gòu)

在傳統(tǒng)的前后端設(shè)計(jì)中，通常是 App 或者 Web 端直接訪問(wèn)后端服務(wù)，后臺(tái)微服務(wù)之間相互調(diào)用，然后返回最終的結(jié)果給前端消費(fèi)。對(duì)于客戶端(特別是移動(dòng)端)來(lái)說(shuō)，過(guò)多的 HTTP 請(qǐng)求是很昂貴的，所以開(kāi)發(fā)過(guò)程中，為了盡量減少請(qǐng)求的次數(shù)，前端一般會(huì)傾向于把有關(guān)聯(lián)的數(shù)據(jù)通過(guò)一個(gè) API 獲取。在微服務(wù)模式下，意味著有時(shí)為了迎合客戶端的需求，服務(wù)器常會(huì)做一些與UI有關(guān)的邏輯處理。

2. 加入了BFF 的前后端架構(gòu)

加入了BFF的前后端架構(gòu)中，最大的區(qū)別就是前端(Mobile, Web) 不再直接訪問(wèn)后端微服務(wù)，而是通過(guò) BFF 層進(jìn)行訪問(wèn)。并且每種客戶端都會(huì)有一個(gè)BFF服務(wù)。從微服務(wù)的角度來(lái)看，有了 BFF 之后，微服務(wù)之間的相互調(diào)用更少了。這是因?yàn)橐恍︰I的邏輯在 BFF 層進(jìn)行了處理。

二、BFF 和 API Gateway

從上文對(duì) BFF 的了解來(lái)看，BFF 既然是前后端訪問(wèn)的中間層服務(wù)，那么 BFF 和 API Gateway 有什么區(qū)別呢?我們首先來(lái)看下 API Gateway 常見(jiàn)的實(shí)現(xiàn)方式。(API Gateway 的設(shè)計(jì)方式可能很多，這里只列舉如下三種)

1. API Gateway 的第一種實(shí)現(xiàn)：一個(gè) API Gateway 對(duì)所有客戶端提供同一種 API

單個(gè) API Gateway 實(shí)例，為多種客戶端提供同一種API服務(wù)，這種情況下，API Gateway 不對(duì)客戶端類型做區(qū)分。即所有 /api/users的處理都是一致的，API Gateway 不做任何的區(qū)分。如下圖所示：

2. API Gateway 的第二種實(shí)現(xiàn)：一個(gè) API Gateway 對(duì)每種客戶端提供分別的 API

單個(gè) API Gateway 實(shí)例，為多種客戶端提供各自不同的API。比如對(duì)于 users 列表資源的訪問(wèn)，web 端和 App 端分別通過(guò) /services/mobile/api/users, /services/web/api/users服務(wù)。API Gateway 根據(jù)不同的 API 判定來(lái)自于哪個(gè)客戶端，然后分別進(jìn)行處理，返回不同客戶端所需的資源。

3. API Gateway 的第三種實(shí)現(xiàn)：多個(gè) API Gateway 分別對(duì)每種客戶端提供分別的 API

在這種實(shí)現(xiàn)下，針對(duì)每種類型的客戶端，都會(huì)有一個(gè)單獨(dú)的 API Gateway 響應(yīng)其 API 請(qǐng)求。所以說(shuō) BFF 其實(shí)是 API Gateway 的其中一種實(shí)現(xiàn)模式。

三、GraphQL 與 REST

GraphQL 作為一種 API 查詢語(yǔ)句，于2015年被 Facebook 推出，主要是為了替代傳統(tǒng)的 REST 模式，那么對(duì)于 GraphQL 和 REST 究竟有哪些異同點(diǎn)呢?我們可以通過(guò)下面的例子進(jìn)行理解。

按照 REST 的設(shè)計(jì)標(biāo)準(zhǔn)來(lái)看，所有的訪問(wèn)都是基于對(duì)資源的訪問(wèn)(增刪查改)。如果對(duì)系統(tǒng)中 users 資源的訪問(wèn)，REST 可能通過(guò)下面的方式訪問(wèn)：

Request:

GET http://localhost/api/users 

Response:

[ 
  { 
    "id": 1, 
    "name": "abc", 
    "avatar": "http://cdn.image.com/image_avatar1" 
  }, 
  ... 
] 

對(duì)于同樣的請(qǐng)求如果用 GraphQL 來(lái)訪問(wèn)，過(guò)程如下：

Request:

POST http://localhost/graphql 

Body:

query {users { id, name, avatar } } 

Response:

{ 
  "data": { 
    "users": [ 
      { 
        "id": 1, 
        "name": "abc", 
        "avatar": "http://cdn.image.com/image_avatar1" 
      }, 
      ... 
    ] 
  } 
} 

關(guān)于 GraphQL 更詳細(xì)的用法，我們可以通過(guò)查看文檔以及其他文章更加詳細(xì)的去了解。相比于 REST 風(fēng)格，GraphQL 具有如下特性：

1. 定義數(shù)據(jù)模型：按需獲取

GraphQL 在服務(wù)器實(shí)現(xiàn)端，需要定義不同的數(shù)據(jù)模型。前端的所有訪問(wèn)，最終都是通過(guò) GraphQL 后端定義的數(shù)據(jù)模型來(lái)進(jìn)行映射和解析。并且這種基于模型的定義，能夠做到按需索取。比如對(duì)上文 /users 資源的獲取，如果客戶端只關(guān)心 user.id, user.name 信息。那么在客戶端調(diào)用的時(shí)候，query 中只需要傳入 users {id \n name}即可。后臺(tái)定義模型，客戶端只需要獲取自己關(guān)心的數(shù)據(jù)即可。

2. 數(shù)據(jù)分層

查詢一組users數(shù)據(jù)，可能需要獲取 user.friends, user.friends.addr等信息，所以針對(duì) users 的本次查詢，實(shí)際上分別涉及到對(duì) user, frind, addr 三類數(shù)據(jù)。GraphQL 對(duì)分層數(shù)據(jù)的查詢，大大減少了客戶端請(qǐng)求次數(shù)。因?yàn)樵?REST 模式下，可能意味著每次獲取 `user` 數(shù)據(jù)之后，需要再次發(fā)送 API 去請(qǐng)求 friends 接口。而 GraphQL 通過(guò)數(shù)據(jù)分層，能夠讓客戶端通過(guò)一個(gè) API獲取所有需要的數(shù)據(jù)。這也就是 GraphQL(圖查詢語(yǔ)句 Graph Query Language)名稱的由來(lái)。

{ 
  user(id:1001) { // 第一層 
    name, 
    friends { // 第二層 
      name, 
      addr { // 第三層 
        country, 
        city 
      } 
    } 
  } 
} 

3. 強(qiáng)類型

const Meeting = new GraphQLObjectType({ 
  name: 'Meeting', 
  fields: () => ({ 
    meetingId: {type: new GraphQLNonNull(GraphQLString)}, 
    meetingStatus: {type: new GraphQLNonNull(GraphQLString), defaultValue: ''} 
  }) 
}) 

GraphQL 的類型系統(tǒng)定義了包括 Int, Float, String, Boolean, ID, Object, List, Non-Null 等數(shù)據(jù)類型。所以在開(kāi)發(fā)過(guò)程中，利用強(qiáng)大的強(qiáng)類型檢查，能夠大大節(jié)省開(kāi)發(fā)的時(shí)間，同時(shí)也很方便前后端進(jìn)行調(diào)試。

4. 協(xié)議而非存儲(chǔ)

GraphQL 本身并不直接提供后端存儲(chǔ)的能力，它不綁定任何的數(shù)據(jù)庫(kù)或者存儲(chǔ)引擎。它利用已有的代碼和技術(shù)進(jìn)行數(shù)據(jù)源的管理。比如作為在 BFF 層使用 GraphQL, 這一層的 BFF 并不需要任何的數(shù)據(jù)庫(kù)或者存儲(chǔ)媒介。GraphQL 只是解析客戶端請(qǐng)求，知道客戶端的“意圖”之后，再通過(guò)對(duì)微服務(wù)API的訪問(wèn)獲取到數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行一系列的組裝或者過(guò)濾。

5. 無(wú)須版本化

const PhotoType = new GraphQLObjectType({ 
  name: 'Photo', 
  fields: () => ({ 
    photoId: {type: new GraphQLNonNull(GraphQLID)}, 
    file: { 
      type: new GraphQLNonNull(FileType), 
      deprecationReason: 'FileModel should be removed after offline app code merged.', 
      resolve: (parent) => { 
        return parent.file 
      } 
    }, 
    fileId: {type: new GraphQLNonNull(GraphQLID)} 
  }) 
}) 

GraphQL 服務(wù)端能夠通過(guò)添加 deprecationReason，自動(dòng)將某個(gè)字段標(biāo)注為棄用狀態(tài)。并且基于 GraphQL 高度的可擴(kuò)展性，如果不需要某個(gè)數(shù)據(jù)，那么只需要使用新的字段或者結(jié)構(gòu)即可，老的棄用字段給老的客戶端提供服務(wù)，所有新的客戶端使用新的字段獲取相關(guān)信息。并且考慮到所有的 graphql 請(qǐng)求，都是按照 POST /graphql 發(fā)送請(qǐng)求，所以在 GraphQL 中是無(wú)須進(jìn)行版本化的。

四、GraphQL 與 REST

對(duì)于 GraphQL 和 REST 之間的對(duì)比，主要有如下不同：

• 數(shù)據(jù)獲取：REST 缺乏可擴(kuò)展性， GraphQL 能夠按需獲取。GraphQL API 調(diào)用時(shí)，payload 是可以擴(kuò)展的;
• API 調(diào)用：REST 針對(duì)每種資源的操作都是一個(gè) endpoint, GraphQL 只需要一個(gè) endpoint( /graphql), 只是 post body 不一樣;
• 復(fù)雜數(shù)據(jù)請(qǐng)求：REST 對(duì)于嵌套的復(fù)雜數(shù)據(jù)需要多次調(diào)用，GraphQL 一次調(diào)用, 減少網(wǎng)絡(luò)開(kāi)銷;
• 錯(cuò)誤碼處理：REST 能夠精確返回HTTP錯(cuò)誤碼，GraphQL 統(tǒng)一返回200，對(duì)錯(cuò)誤信息進(jìn)行包裝;
• 版本號(hào)：REST通過(guò) v1/v2 實(shí)現(xiàn)，GraphQL 通過(guò) Schema 擴(kuò)展實(shí)現(xiàn);

五、微服務(wù) + GraphQL + BFF 實(shí)踐

在微服務(wù)下基于 GraphQL 構(gòu)建 BFF，我們?cè)陧?xiàng)目中已經(jīng)開(kāi)始了相關(guān)的實(shí)踐。在我們項(xiàng)目對(duì)應(yīng)的業(yè)務(wù)場(chǎng)景下，微服務(wù)后臺(tái)有近 10 個(gè)微服務(wù)，客戶端包括針對(duì)不同角色的4個(gè) App 以及一個(gè) Web 端。對(duì)于每種類型的 App，都有一個(gè) BFF 與之對(duì)應(yīng)。每種 BFF 只服務(wù)于這個(gè) App。BFF 解析到客戶端請(qǐng)求之后，會(huì)通過(guò) BFF 端的服務(wù)發(fā)現(xiàn)，去對(duì)應(yīng)的微服務(wù)后臺(tái)通過(guò) CQRS 的方式進(jìn)行數(shù)據(jù)查詢或修改。

1. BFF 端技術(shù)棧

[[226920]]

我們使用 GraphQL-express 框架構(gòu)建項(xiàng)目的 BFF 端，然后通過(guò) Docker 進(jìn)行部署。BFF 和微服務(wù)后臺(tái)之間，還是通過(guò) registrator 和 Consul 進(jìn)行服務(wù)注冊(cè)和發(fā)現(xiàn)。

addRoutes () { 
   this.express.use('/graphql', this.resolveFromRequestScopeAndHandle('GraphqlHandler')) 
   this.serviceNames.forEach(serviceName => { 
     this.express.use(`/api/${serviceName}`, this.routers.apiProxy.createRouter(serviceName)) 
   }) 
 } 

在 BFF 的路由設(shè)置中，對(duì)于客戶端的處理，主要有 /graphql 和 /api/${serviceName}兩部分。/graphql 處理的是所有 GraphQL 查詢請(qǐng)求，同時(shí)我們?cè)?BFF 端增加了 /api/${serviceName} 進(jìn)行 API 透?jìng)鳎瑢?duì)于一些沒(méi)有必要進(jìn)行 GraphQL 封裝的請(qǐng)求，可以直接通過(guò)透?jìng)髟L問(wèn)到相關(guān)的微服務(wù)中。

2. 整體技術(shù)架構(gòu)

整體來(lái)看，我們的前后端架構(gòu)圖如下，三個(gè) App 客戶端分別使用 GraphQL 的形式請(qǐng)求對(duì)應(yīng)的 BFF。BFF 層再通過(guò) Consul 服務(wù)發(fā)現(xiàn)和后端通信。

關(guān)于系統(tǒng)中的鑒權(quán)問(wèn)題：

用戶登錄后，App 直接訪問(wèn) KeyCloak 服務(wù)獲取到 id_token，然后通過(guò) id_token 透?jìng)髟L問(wèn) auth-api 服務(wù)獲取到 access_token, access_token 以 JWT (Json Web Token) 的形式放置到后續(xù) http 請(qǐng)求的頭信息中。

在我們這個(gè)系統(tǒng)中 BFF 層并不做鑒權(quán)服務(wù)，所有的鑒權(quán)過(guò)程全部由各自的微服務(wù)模塊負(fù)責(zé)。BFF 只提供中轉(zhuǎn)的功能。BFF 是否需要集成鑒權(quán)認(rèn)證，主要看各系統(tǒng)自己的設(shè)計(jì)，并不是一個(gè)標(biāo)準(zhǔn)的實(shí)踐。

3. GraphQL + BFF 實(shí)踐

通過(guò)如下幾個(gè)方面，可以思考基于 GraphQL 的 BFF 的一些更好的特質(zhì)：

(1) GraphQL 和 BFF 對(duì)業(yè)務(wù)點(diǎn)的關(guān)注

從業(yè)務(wù)上來(lái)看，PM App(使用者：物業(yè)經(jīng)理)關(guān)注的是property，物業(yè)經(jīng)理管理著一批房屋，所以需要知道所有房屋概況，對(duì)于每個(gè)房屋需要知道有沒(méi)有對(duì)應(yīng)的維修申請(qǐng)。所以 PM App BFF 在定義數(shù)據(jù)結(jié)構(gòu)是，maintemamceRequests 是 property 的子屬性。

同樣類似的數(shù)據(jù)，Supplier App(使用者：房屋維修供應(yīng)商)關(guān)注的是 maintenanceRequest(維修工單)，所以在 Supplier App 獲取的數(shù)據(jù)里，我們的主體是maintenanceRequest。維修供應(yīng)商關(guān)注的是 workOrder.maintenanceRequest。

所以不同的客戶端，因?yàn)榇嬖谥煌氖褂脠?chǎng)景，所以對(duì)于同樣的數(shù)據(jù)卻有著不同的關(guān)注點(diǎn)。BFF is pary of Application。從這個(gè)角度來(lái)看，BFF 中定義的數(shù)據(jù)結(jié)構(gòu)，就是客戶端所真正關(guān)心的。BFF 就是為客戶端而生，是客戶端的一部分。需要說(shuō)明的是，對(duì)于“業(yè)務(wù)的關(guān)注”并不是說(shuō)，BFF會(huì)處理所有的業(yè)務(wù)邏輯，業(yè)務(wù)邏輯還是應(yīng)該由微服務(wù)關(guān)心，BFF 關(guān)注的是客戶端需要什么。

(2) GraphQL 對(duì)版本化的支持

假設(shè) BFF 端已經(jīng)發(fā)布到生產(chǎn)環(huán)境，提供了 inspection 相關(guān)的 tenants 和 landlords 的查詢。現(xiàn)在需要將圖一的結(jié)構(gòu)變更為圖二的結(jié)構(gòu)，但是為了不影響老用戶的 API 訪問(wèn)，這時(shí)候我們的 BFF API 必須進(jìn)行兼容。如果在 REST 中，可能會(huì)增加 api/v2/inspections進(jìn)行 API 升級(jí)。但是在 BFF 中，為了向前兼容，我們可以使用圖三的結(jié)構(gòu)。這時(shí)候老的 APP 使用黃色區(qū)域的數(shù)據(jù)結(jié)構(gòu)，而新的 APP 則使用藍(lán)色區(qū)域定義的結(jié)構(gòu)。

(3) GraphQL Mutation 與 CQRS

mutation { 
  area { 
    create (input: { 
      areaId:"111",  
      name:"test",  
    }) 
  } 
} 

如果你詳細(xì)閱讀了 GraphQL 的文檔，可以發(fā)現(xiàn) GraphQL 對(duì) query 和 mutation 進(jìn)行了分離。所有的查詢應(yīng)該使用 query { ...}，相應(yīng)的 mutaition 需要使用 mutation { ... }。雖然看起來(lái)像是一個(gè)convention，但是 GraphQL 的這種設(shè)計(jì)和后端 API 的 讀寫(xiě)職責(zé)分離(Command Query Responsibility Segregation)不謀而合。而實(shí)際上我們使用的時(shí)候也遵從這個(gè)規(guī)范。所以的 mutation 都會(huì)調(diào)用后臺(tái)的 API，而后端的 API 對(duì)于資源的修改也是通過(guò) SpringBoot EventListener 實(shí)現(xiàn)的 CQRS 模式。

六、如何做好測(cè)試

在引入了 BFF 的項(xiàng)目，我們的測(cè)試仍然使用金字塔原理，只是在客戶端和后臺(tái)之間，需要添加對(duì) BFF 的測(cè)試。

• Client 的 integration-test 關(guān)心的是 App 訪問(wèn) BFF 的連通性，App 中所有訪問(wèn) BFF 的請(qǐng)求都需要進(jìn)行測(cè)試;
• BFF 的 integration-test 測(cè)試的是 BFF 到微服務(wù) API 的連通性，BFF 中依賴的所有 API 都應(yīng)該有集成測(cè)試的保障;
• API 的 integration-test 關(guān)注的是這個(gè)服務(wù)對(duì)外暴露的所有 API，通常測(cè)試所有的 Controller 中的 API。

七、結(jié)語(yǔ)

微服務(wù)下基于 GraphQL 構(gòu)建 BFF 并不是銀彈，也并不一定適合所有的項(xiàng)目，比如當(dāng)你使用 GraphQL 之后，你可能得面臨多次查詢性能問(wèn)題等，但這不妨礙它成為一個(gè)不錯(cuò)的嘗試。你也的確看到 Facebook 早已經(jīng)使用 GraphQL，而且 Github 也開(kāi)放了 GraphQL 的API。而 BFF， 其實(shí)很多團(tuán)隊(duì)也都已經(jīng)在實(shí)踐了，在微服務(wù)下等特殊場(chǎng)景下，GraphQL + BFF 也許可以給你的項(xiàng)目帶來(lái)驚喜。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文