吐槽文一篇。

契約的一些問題

在實踐前后端分離的這些年來，已經(jīng)誕生了一些技術(shù)與工具讓前后端進(jìn)行溝通：

• 契約的 Mock 服務(wù)（Mock Server）。用于模擬一個服務(wù)器，為特定的接口返回特定的值。
• 契約測試。對前后端協(xié)定的 API 進(jìn)行測試。
• 前后端膠水層。如 BFF （Backends for Frontends），根據(jù)客戶端的需要對 API 進(jìn)行聚合、適配、裁剪等。

而使用這些工具的時候，往往容易出現(xiàn)一些問題。

消費(fèi)者無法驅(qū)動的契約

消費(fèi)者驅(qū)動，顧名思義就是在我們協(xié)定契約的時候，按消費(fèi)者的業(yè)務(wù)實現(xiàn)角度，與生產(chǎn)者一起協(xié)定契約。在實踐上，往往由于后端在項目中的主導(dǎo)地位導(dǎo)致：協(xié)商的結(jié)果不會按消費(fèi)者需要，而是按生者需要來生成契約。造成這種結(jié)果的因素有很多：

后端才是實現(xiàn)方。所以，你常會聽見：『你行，你上』，笑~。

從實施成本考慮。諸如于跨服務(wù)調(diào)用的成本等等

后端的職級高——畢竟后端已經(jīng)有了幾十年歷史了。

為了更『美』的后端架構(gòu)——導(dǎo)致了更『差的』前端架構(gòu)。

我的意思并不是說，按生產(chǎn)者來主導(dǎo)有什么問題，而是配不上『消費(fèi)者驅(qū)動』這五個字。諸如于我們獲取某個 API 的時候，前端所需要的是相關(guān)的信息，而不是對應(yīng)的實體 ID。而后，再由前端去獲取對應(yīng)實體的信息。從邏輯上來說，由前端獲取或者后端獲取，從技術(shù)上來說，并沒有多大的問題。但是從用戶體驗上來說，并沒有那么友好。后端間的 API 調(diào)用，可以是幾十 ms 級別的；而前端多調(diào)用一個后端 API，在網(wǎng)絡(luò)上的傳輸時間，往往都是幾百 ms，乃至幾秒。

生產(chǎn)者的契約測試

所以，讓我們再看看各個團(tuán)隊所宣稱的消費(fèi)者驅(qū)動的契約測試。

消費(fèi)者驅(qū)動的契約測試（Consumer-Driven Contracts，簡稱CDC），是指從消費(fèi)者業(yè)務(wù)實現(xiàn)的角度出發(fā)，驅(qū)動出契約，再基于契約，對提供者驗證的一種測試方式。

如果你不是消費(fèi)者驅(qū)動的契約，而是后端一口氣定出來的接口，你怎么能叫『消費(fèi)者驅(qū)動的契約測試』？？？？按這樣的做法，它只能叫生產(chǎn)者的契約測試。

既然是生產(chǎn)者的契約測試，那么它就無法保證說：API 修改不影響消費(fèi)者使用——因為消費(fèi)者壓根就沒有參與到契約的制定，生產(chǎn)者可以按照自己的需要來修改契約。

所以，生產(chǎn)者到底是在給誰測試？又是在測試什么東西？

契約測試的契約作為 Mock Server——不行

在大部分的項目中，對于契約的使用存在問題，即模式錯了。契約測試需要圍繞業(yè)務(wù)流程施展，而不應(yīng)該相互隔離。如果契約的用例不豐富，便無法串起整個系統(tǒng)的流程。而作為 API 的提供方，應(yīng)該保證業(yè)務(wù)邏輯是可以串聯(lián)起來的。從用戶的登錄開始，到用戶獲取數(shù)據(jù)，展示列表頁，能進(jìn)入詳情頁等等。

我們做契約測試的目標(biāo)是，讓代碼修改不影響 API 輸出。后端需求一改，契約測試會掛，后端知道出現(xiàn)問題，會進(jìn)行修復(fù)。如果前端用的是契約測試的契約提供的 Mock Server，前端的測試也會掛，這樣問題就不會往后流。

所以，契約不應(yīng)當(dāng)給前端做本地開發(fā)和測試 。

沒有契約的 Mock Server——不行

對于小團(tuán)隊來說，去采用原始的 API 方式反而更加有效率；對于大團(tuán)隊來說，這樣的方式并不可行。

既然，溝通那么麻煩，那么我們就分開吧。如果契約和 Mock Server 是分開的，那么維護(hù)前端 Mock Server 的人很很難識別到修改。相關(guān)的問題，在測試不及時的情況下，有可能在上線后才發(fā)現(xiàn)。

也因此，從理想情況來說，這個 Mock Server 是契約動態(tài)生成的，并能根據(jù)后端現(xiàn)有最新的契約更新。或者，后端在實現(xiàn)契約測試時，要做的是只測試部分?jǐn)?shù)據(jù)，而不是為了測試而測試。

只有 DDD 的微服務(wù)——不行

盡管 DDD 模型不一定非要與 API 綁定，但是由于種種原因，真正在實踐的時候，就不是這么一回事。我們可以看到在很多的項目里，DDD 返回的實體資源，最后可能與 API 的字段一致的。但是它并非是業(yè)務(wù)上想要返回的邏輯，各個客戶端（PC Web、小程序、Android 端、iOS 端等）還都需要進(jìn)行二次的處理。

這就是為什么，DDD + 微服務(wù)，一定要配合一下 BFF 的原因。

缺少前端、后端的 BFF——不行

實施 BFF，大家并沒有啥問題。可一誰來維護(hù)這一層膠水層的時候，大家都問題都來了——前后端都不愿意維護(hù)這個 BFF。對于前端來說，開發(fā)者只是 API 的消費(fèi)者，突然間又變身成為生產(chǎn)者；對于后端來說，開發(fā)者原本不需要了解顯示邏輯，現(xiàn)在也要涉及到這部分的內(nèi)容。

不過呢，我們可以保持一致的是：后端是 API 的生產(chǎn)者。而如果生產(chǎn)者沒有參與到 BFF 的開發(fā)，那么就會引發(fā)另外一個問題，API 發(fā)生變更的時候，可能沒有同步到 BFF——盡管每個項目都有自己的規(guī)范，但是只要是由人來執(zhí)行的，都可能會出現(xiàn)問題。

那么，我們就需要一個 BFF 的契約測試，那在第一時間知道 API 的變化。雖然感覺怪怪的，但是我們還是將客戶端的契約測試，前移至了 BFF 層。

所以，消費(fèi)者驅(qū)動的契約在哪里呢？

解決方案

BFF

大家都懂了。

前端為主寫 BFF

前端寫 BFF 并不是一件容易的事。你要懂微前端，要懂主流的微服務(wù)框架，如 Spring Cloud，要懂 Java。與此同時，還需要了解各個 API 的變化 情況。對于前后端分離團(tuán)隊而言，要做樣的工作太難了。

而盡管你可以采用 Node.js + TypeScript，但是它也意味著你要成為一個 Node.js 專家。如果讓我用 Node.js 寫 BFF，那我還是寧愿和以前的項目一樣，寫 Scala 來作為 BFF。

所以，我并不推薦使用 Node.js 作為 BFF。一來，沒有阿里巴巴強(qiáng)大的 Node.js 專家群；二來，我對于成為 Node.js 沒有興趣。用擅長于某一領(lǐng)域的語言去做某一領(lǐng)域的事，而非用擅長的語言去做每一領(lǐng)域的事——興趣和愛好除外。

GraphQL as BFF

大家都懂了。

前端防腐層

參考《整潔前端架構(gòu)》。

消費(fèi)者的契約測試

我們在諸多項目實現(xiàn)了：針對于生產(chǎn)者的契約測試。其中也包含了之前我寫的 mest 框架，它是通過結(jié)合 TypeScript 的 Interface 來驗證后端接口是否一致。

當(dāng)你沒有辦法的時候，這也是一個不那么差的做法。換個問題來思考的話，就是以生產(chǎn)者來解決這些問題。

直接轉(zhuǎn)換模型為 Java Class 和 TypeScript 是一種更簡單的做法。

結(jié)論

沒有銀彈。

總結(jié)

以上是生活随笔為你收集整理的驱动api_消费者驱动契约已死？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。