在线观看一级毛片,成人久久18网站,国产真实伦视频在线观看

圖 1：微服務架構中的模擬 API

API 模擬案例學習

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

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

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

回報率計算模型

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

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

在圖 3 中，用戶輸入是藍色的，計算結果是黃色的。

圖 3 的用戶輸入包括：

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

在關鍵路徑上使用 API 模擬

我們已經看到 API 模擬適用于有兩個開發團隊相互依賴的場景，對于需要多個團隊一起開發新產品或新功能的項目，也同樣適用。

通過 API 模擬來并行化開發工作——以簡單的兩個團隊為例

團隊 A 的新功能在發布到生產環境之前需要依賴團隊 B 的東西。

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

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

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

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

通過 API 模擬來并行化開發工作——以多團隊合作為例

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

團隊 A 負責開發手機號轉移功能，他們依賴了手機號客戶服務 API，該 API 由團隊 B 負責。團隊 B 的 API 依賴了手機號查詢功能，該功能由團隊 C 負責。團隊 C 依賴了團隊 D，團隊 D 負責手機號的第三方服務集成。

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

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

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

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

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

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

盡管這個模型做了一些關鍵性的假設，但它所傳達的要點在于在采用 API 優先開發模式時如何通過 API 模擬來并行化團隊的開發工作。

并行開發的回報率計算

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

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

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

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

如何開始采用 API 模擬

采用 API 優先的開發模式和 API 模擬可以先從一個團隊開始。讓整個組織都采用這種方法確實是有好處的，但這并不妨礙你先從其中的一個團隊開始，設定一個容易實現的目標。

在選擇第一個采用 API 優先開發模式和 API 模擬的團隊時，可以先確定業務關鍵特性，在甘特圖上列出所有涉及的團隊，并選擇在進行并行開發時對項目截止日期影響最大的那個團隊。

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

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

作者簡介：

Wojciech Bulaty專攻企業軟件開發和測試架構。他在寫作中融入了十多年的親身編程和領導經驗。他現在是 Traffic Parrot 團隊的一員，通過提供 API 模擬和服務虛擬化工具幫助微服務開發團隊加速交付、提高質量并縮短發布時間。你可以在推特上關注 Wojciech，也可以在LinkedIn上聯系他。

原文鏈接：

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

本文轉載自《用 API 優先和 API 模擬打破軟件交付關鍵路徑上的依賴》，譯者：屠靈