亚洲国产成人精品91久久久,一级一级一级毛片免费毛片,色综合色综合色综合

圖 1：微服務(wù)架構(gòu)中的模擬 API

API 模擬案例學(xué)習(xí)

一家 InsurTech 初創(chuàng)公司使用 Golang 和 Python 開發(fā)微服務(wù)，并部署在 Kubernetes 的 Docker 中。他們使用基于 gRPC 的 API 實現(xiàn)微服務(wù)之間的通信。一個開發(fā)團(tuán)隊必須等待其他團(tuán)隊先完成 gRPC API 才能開始自己的開發(fā)工作，導(dǎo)致團(tuán)隊之間發(fā)生時間線堵塞，初創(chuàng)公司無法以客戶需要的節(jié)奏交付產(chǎn)品。工程副總裁很清楚，他們需要找到一個解決方案，能夠讓團(tuán)隊實現(xiàn)獨立開發(fā)。

通過使用模擬 gRPC API，他們消除了團(tuán)隊之間的時間線阻塞。與開源替代方案不同，它提供了復(fù)雜的消息模式特性以及最新的協(xié)議特性支持。

開發(fā)團(tuán)隊使用模擬 API 并行開發(fā)他們的 gRPC API，不需要等待服務(wù)器端代碼就緒就可以測試客戶端代碼。他們在 CI 構(gòu)建代理上運行自動化測試套件，模擬 API 就運行在代理上的 Docker 容器中。

回報率計算模型

我們基于上述的例子創(chuàng)建了一個電子表格，你可以用它計算出采用 API 模擬所獲得的回報率。

請單擊鏈接下載這個表格。

在圖 3 中，用戶輸入是藍(lán)色的，計算結(jié)果是黃色的。

圖 3 的用戶輸入包括：

團(tuán)隊完成功能開發(fā)需要做多少工作？
團(tuán)隊因為等待 API 就緒被阻塞了多少天？
定義 API 需要多長時間？（通常是 2 天）
熟悉 API 模擬工具需要多長時間？（通常是 4 天）
創(chuàng)建模擬 API 需要多長時間？（通常是 2 天）
如果 API 發(fā)生變化，同步模擬 API 需要多長時間？
真實 API 就緒之后需要多長時間進(jìn)行集成？針對這個模型，我們做了一些關(guān)鍵性的假設(shè)：
如果依賴的 API 不就緒，其他團(tuán)隊就沒辦法進(jìn)行并行開發(fā)，他們需要真實 API 或模擬 API 才能繼續(xù)開發(fā)工作；
生產(chǎn)者團(tuán)隊和消費者團(tuán)隊都可以定義 API（通過 Swagger、Proto、WSDL，等等）；
開發(fā)團(tuán)隊采用看板開發(fā)模式（沒有 Sprint 或迭代）；
開發(fā)人員正在編寫自動化測試；
API 模擬由 API 消費者團(tuán)隊（而不是 API 生產(chǎn)者團(tuán)隊）創(chuàng)建；
API 定義是穩(wěn)定的，不會發(fā)生重大變更。如果發(fā)生次要的變更，需要在團(tuán)隊之間傳達(dá)；
當(dāng)真實 API 就緒時，可以立即用它們進(jìn)行集成測試；
開發(fā)團(tuán)隊可以使用該電子表格中的其他表格來實現(xiàn)更多的 API 模擬（例如加快構(gòu)建速度、處理更多的故障場景，等等），但出于簡單起見，我們不把它們納入到這個模型。如果這些假設(shè)與你的開發(fā)流程相匹配，我們很愿意一起討論一下，并為你們創(chuàng)建合適的模型。

在關(guān)鍵路徑上使用 API 模擬

我們已經(jīng)看到 API 模擬適用于有兩個開發(fā)團(tuán)隊相互依賴的場景，對于需要多個團(tuán)隊一起開發(fā)新產(chǎn)品或新功能的項目，也同樣適用。

通過 API 模擬來并行化開發(fā)工作——以簡單的兩個團(tuán)隊為例

團(tuán)隊 A 的新功能在發(fā)布到生產(chǎn)環(huán)境之前需要依賴團(tuán)隊 B 的東西。

圖 2 給出了一個描述此種情況的甘特圖。團(tuán)隊 B 在開發(fā)新功能，他們的 API 在第 20 天才能提供，團(tuán)隊 A 開發(fā)的新功能在第 35 天就緒，然后開始做集成測試。最后，新功能在第 37 天部署到生產(chǎn)環(huán)境。

假設(shè)這兩個團(tuán)隊決定采用 API 優(yōu)先的開發(fā)模式，開始定義團(tuán)隊之間的業(yè)務(wù)契約。他們定義系統(tǒng)之間的 API，并使用了 API 模擬，新功能在第 26 天部署到生產(chǎn)環(huán)境。對于這種場景，在團(tuán)隊 B 的部分成員已經(jīng)開始開發(fā)新功能的同時，其他成員和團(tuán)隊 A 的部分成員在幾天內(nèi)定義好系統(tǒng)的 API。通常，團(tuán)隊 A 可以開始培訓(xùn)如何使用 API 模擬，并在大概 4 天的時間里創(chuàng)建好模擬 API。團(tuán)隊 A 有了模擬 API 就可以開發(fā)他們的新功能，并在開發(fā)完成之后與團(tuán)隊 B 集成，這可能比使用真實 API 要多花一天時間，畢竟模擬 API 不可能完全精確地模擬真實系統(tǒng)，要與真實 API 順暢集成，需要做一些細(xì)小的改動。

要想加快速度，還有另一種選項，就是將模擬 API 外包給第三方供應(yīng)商。如果模擬 API 外包出去，那么新功能就可以在第 20 天完成。

因為采用了 API 模擬和 API 優(yōu)先的開發(fā)模式，我們加快了發(fā)版速度，可以在第 20 天發(fā)版，而不是第 37 天。

通過 API 模擬來并行化開發(fā)工作——以多團(tuán)隊合作為例

我們對上面的例子做一個擴(kuò)展，將兩個團(tuán)隊擴(kuò)展到四個團(tuán)隊。在這個例子中，我們有團(tuán)隊 A、B、C 和 D，它們一起為公司開發(fā)一個復(fù)雜的功能。

團(tuán)隊 A 負(fù)責(zé)開發(fā)手機(jī)號轉(zhuǎn)移功能，他們依賴了手機(jī)號客戶服務(wù) API，該 API 由團(tuán)隊 B 負(fù)責(zé)。團(tuán)隊 B 的 API 依賴了手機(jī)號查詢功能，該功能由團(tuán)隊 C 負(fù)責(zé)。團(tuán)隊 C 依賴了團(tuán)隊 D，團(tuán)隊 D 負(fù)責(zé)手機(jī)號的第三方服務(wù)集成。

團(tuán)隊 A 要等到第 70 天交付他們負(fù)責(zé)的部分，但他們感到壓力很大，他們要等到第 61 天才能開始他們的開發(fā)工作，因為團(tuán)隊 B 的功能要在那天才能完成。見圖 4。

在看了項目計劃之后，團(tuán)隊 A 決定提早開始開發(fā)工作。他們找到團(tuán)隊 B，與他們一起定義 API。他們創(chuàng)建了模擬 API，在第 43 天就開始開發(fā)，而不是第 61 天。見圖 5。

這樣團(tuán)隊 A 就有了更多的喘息時間，因為他們在第 66 天就完成了開發(fā)工作，而不是第 70 天。如果其他團(tuán)隊出了什么差錯，他們有更多的糾錯余地。

在看了更新過的項目計劃之后，團(tuán)隊 B 意識到自己是離交付截止日期最近的。他們本來有 10 天時間（距離第 70 天），但現(xiàn)在只有 6 天（距離第 66 天）。他們決定開始與團(tuán)隊 C 并行開發(fā)。在與團(tuán)隊 B 溝通過后，團(tuán)隊 C 意識到他們也可以與團(tuán)隊 D 并行開發(fā)。這么看來，這個功能應(yīng)該可以在第 30 天交付，而不是第 70 天。見圖 6。

值得一提的是，如果有必要，各個團(tuán)隊使用模擬 API 的順序是可以調(diào)換的。例如，如果團(tuán)隊 C 率先使用了模擬 API 并提前幾天交付功能，這樣就可以降低團(tuán)隊 B 和團(tuán)隊 A 的風(fēng)險，為后續(xù) API 定義的變動騰出了一些緩沖時間。

由于不可預(yù)見的復(fù)雜性，計劃的時間越長，里程碑延后的風(fēng)險就越大——你可以盡早使用 API 模擬開始開發(fā)工作，將里程碑向左移，并盡早識別出關(guān)鍵風(fēng)險。

盡管這個模型做了一些關(guān)鍵性的假設(shè)，但它所傳達(dá)的要點在于在采用 API 優(yōu)先開發(fā)模式時如何通過 API 模擬來并行化團(tuán)隊的開發(fā)工作。

并行開發(fā)的回報率計算

正如上面的甘特圖表所示，這個功能現(xiàn)在可以提前 40 天交付。我們可以在“RESULTS”部分看到這個。

這對那些為初創(chuàng)公司工作的高管來說很重要，因為他們已經(jīng)向股東或投資者承諾某個功能將在指定日期前準(zhǔn)備好。這個模型可以降低交付時間方面的風(fēng)險，并幫他們實現(xiàn)承諾。

這個電子表格計算出了在 12 個月內(nèi)沒有采用并行開發(fā)所造成的延遲成本。

這也可以估算出延遲在企業(yè)中采用 API 模擬所造成的價值損失。對于圖 7 所示的情況，我們假設(shè)當(dāng)新功能對客戶可用時，公司每天應(yīng)該多賺 5000 美元。我們把 40 天乘以 5000 美元，也就是說，如果他們不采用 API 模擬，公司將損失 20 萬美元。假設(shè)該公司決定每年花 1 萬美元購買付費解決方案，延遲成本也只下降到 19 萬美元。在本例中，我們假設(shè)公司不只開發(fā)這一個功能，相反，在未來 12 個月內(nèi)將開發(fā)三個功能。在這種情況下，由于沒有采用 API 模擬和 API 優(yōu)先的開發(fā)模式來交付這些功能，他們可能會損失 59 萬美元。

如何開始采用 API 模擬

采用 API 優(yōu)先的開發(fā)模式和 API 模擬可以先從一個團(tuán)隊開始。讓整個組織都采用這種方法確實是有好處的，但這并不妨礙你先從其中的一個團(tuán)隊開始，設(shè)定一個容易實現(xiàn)的目標(biāo)。

在選擇第一個采用 API 優(yōu)先開發(fā)模式和 API 模擬的團(tuán)隊時，可以先確定業(yè)務(wù)關(guān)鍵特性，在甘特圖上列出所有涉及的團(tuán)隊，并選擇在進(jìn)行并行開發(fā)時對項目截止日期影響最大的那個團(tuán)隊。

或者，如果你是團(tuán)隊負(fù)責(zé)人，面臨著交付截止日期的壓力，就像上述例子中的團(tuán)隊 A，你可以主動讓團(tuán)隊采用 API 優(yōu)先的開發(fā)模式和 API 模擬，以此來減輕團(tuán)隊正在承受的壓力。

這個Wiki頁提供了一個對團(tuán)隊十分有用的 API 模擬工具清單。

作者簡介：

Wojciech Bulaty專攻企業(yè)軟件開發(fā)和測試架構(gòu)。他在寫作中融入了十多年的親身編程和領(lǐng)導(dǎo)經(jīng)驗。他現(xiàn)在是 Traffic Parrot 團(tuán)隊的一員，通過提供 API 模擬和服務(wù)虛擬化工具幫助微服務(wù)開發(fā)團(tuán)隊加速交付、提高質(zhì)量并縮短發(fā)布時間。你可以在推特上關(guān)注 Wojciech，也可以在LinkedIn上聯(lián)系他。

原文鏈接：

Using API-First Development and API Mocking to Break Critical Path Dependencies

本文轉(zhuǎn)載自《用 API 優(yōu)先和 API 模擬打破軟件交付關(guān)鍵路徑上的依賴》，譯者：屠靈