成功遷移到微服務的 5 個關鍵要素

作者 | Beyang Liu

譯者 | Sambodhi

策劃 | 閆園園

啊，微服務。

黑格爾的辯證法已經在程序員中形成了一種傳統——即 React 與 Angular、Emacs 與 Vim、Tabs 與 Spaces——關於微服務與單體的大辯論還在繼續。

一般而言，在初始階段就 “做微服務” 是過早的抽象化。所以，大部分的微服務架構都是由單體架構遷移而來。這樣的遷移往往是軟件企業成功與否的關鍵。如果你的應用能夠很好地遷移，那麼當你的應用能夠滿足更多的用戶時，你就有望保持快速的能力。如果你的應用不能很好地遷移，那麼你的整個工程團隊將會在幾個月甚至幾年裏停滯不前，陷入無休止的工作中，無法實現關鍵的特性，也會影響到你的擴展能力。

在 Sourcegraph，我們很榮幸地與全球最優秀的工程組織一起工作，並且在很多不同的行業中完成了重要的架構遷移。在這篇文章中，我們將分享一個共同的模板，這是我們在見證哪些是行得通的，哪些不管用的之後發現的。

下面是 5 個成功的大規模架構遷移的關鍵要素：

1、指定單個所有者並確定所有利益相關者。

2、定義什麼是成功，什麼不是成功。

3、在不突破的大變化和突破的小變化之間交替。

4、人機迴圈的自動化。

5、跟蹤進展。

1 指定單個所有者並確定所有利益相關者

確定一個團隊或者個人來負責推進遷移。通常的做法是選擇開發人員體驗團隊的領導者。他必須理解，眼前的工作並不只是一項技術工作，更應該是各利益相關者之間的協調與溝通。他們會推動改變，這些改變會對很多團隊的工作產生影響。重要的是，他們有能力，並且願意協助這些團隊瞭解改變的重要性，並且在這項工作中尋求他們的合作。

從策略上講，所有者應該及早地確定出所有需要投入的利益相關者。這樣做可以保證，所有的利益相關者都會對這項工作表示支持，這樣才能保證利益相關者能夠支持他們所做的工作，而不會覺得自己沒有付出就會被強制執行。利益相關者名單中應當包含所有需要修改的代碼所有者。在這個過程中，你的編輯器或者代碼瀏覽器的 “查找引用” 這一特性就是你的得力助手！

找到代碼中所有需要改變的位置，並確定它們的所有者。接下來，把你需要批准的所有者的名單或電子表格列出來。

2 定義成功

爲遷移的最終狀態設定一個明確的願景，並把它和你希望達到的目標相關聯。很多大規模的遷移之所以會拖延，是因爲最初的目標沒有明確定義。如果遷移被拖延，並且不清楚終點線有多遠，那麼遷移也可能被拋棄。

定義最終狀態還能幫助你證實需要進行更大的改變，從而帶來真正的改變。避免漸進主義的慣性，選擇一個能反映出你真正的架構目標的期望的最終狀態。比如，如果你的目的是將單體的主要組件進行模塊化，那麼一些相當大的變化就有必要。如果你想把自己限制在局部的、保守的變化，就不可能實現你的目標。

下面是從某些大規模遷移計劃文檔中的範例中得到的模板：

一個示例架構圖，顯示了正在實施的高級更改。

與你在步驟 1 中創建的利益相關者名單分享這份文檔。反饋目標有二：

1、反饋將通過指出某人無法預見的困難來改進建議。

2、反饋會增強利益相關者的認同感，因此可以跟蹤整個代碼庫上的變更。

3 在不突破的大變化和突破的小變化之間交替

一旦你確定了最終狀態，就可以將它分解成更易於管理的中間裏程碑。在你的路線圖中，要避免做出大的、破壞性的、不可逆的變化。這些類型的變化會擾亂開發，或在很長一段時間內降低生產環境。

一種常見的模式是，在保留 BackCompat 時，交替地做出大規模的變化和突破性的、小規模的、原子性的變化（最好是可逆的）。將按下列步驟循環完成很多工作：

1、構建一個新的服務而不需要更改現有的系統。

2、在新舊代碼路徑之間進行條件化的轉換。（這會導致新接口或者特性切換，或者僅僅是一個簡單的 if 語句）。

3、進行一些小規模的、突破性的變化。（例如，切換接口的實現或者翻轉特性的切換）。最理想的情況是，你已經設計好了，當發生錯誤時，你可以輕鬆的進行回滾。

4、清理不再使用的舊代碼。

在遷移的過程中，這個循環可能會重複一至數十次。如果單體規模足夠大，足夠複雜，整個遷移過程要花費數年才能完成，這種情況並不少見。如果是這樣的話，你一定會想要更短期的中間裏程碑，讓開發環境和生產環境都處於工作狀態。

特性標記是一種常見的方法，可以使突破性的變化變得很小，而且具有原子性。

4 人機迴圈的自動化

遷移循環中的第 2 步（添加條件切換）和第 4 步（清理舊代碼）通常涉及在整個代碼庫中進行大規模的簡單重構。你會希望將那些步驟自動化，不然將會成爲一件令人厭煩的事情。

首先，嘗試在一兩個地方手動進行必要的改動，以瞭解哪些地方需要自動化。

然後，在整個代碼庫中擴展這一變化。

重要的是，你使用的工具可以提供反饋和調整，因爲總是會出現你沒有預見到的邊緣情況。

在微服務遷移中，經常會有很多地方需要做一些簡單的改動。自動化能幫你做一些繁瑣的工作，但重要的是要保持人機迴圈，因爲有時候這些改變會有細微的差別，或者你要和那些已經更新代碼的團隊進行交流。

以下是我們所見過的用於指導這種大規模遷移的工具：

• 專門的腳本，克隆受影響的倉庫，並使用命令行代碼修改工具（如 sed、codemod 或 Comby）來應用變化。

• 內部工具，如谷歌的 Rosie。

• Sourcegraph 的 Batch Changes。

5 跟蹤進展

最後，跟蹤最終目標的進展。工程領導、在代碼庫中工作的開發人員，以及來自產品、銷售和其他部門的利益相關者都想知道遷移的進展情況，特別是如果它阻礙了他們關心的其他產品開發工作。

你會希望在兩個層面上跟蹤進展：

1、每一箇中間裏程碑的進展，每一個里程碑都可能涉及許多代碼審查，所有受變化集影響的團隊都必須批准。

2、總體最終目標的進展，這可能需要幾個月或幾年的時間。如果你不清楚地定義這個進展表，你將浪費大量時間向越來越質疑的利益相關者解釋和溝通進展。

跟蹤遷移進展的一種方法是使用燃盡圖。

燃盡圖可以跟蹤單個變更活動的進展，但許多微服務遷移會被分解成多個里程碑。爲了跟蹤實現目標架構的總體進展，在代碼中繪製指示使用舊架構和新架構的模式的出現情況可能會很有幫助。

6 這與旅程無關

當涉及大規模重構和遷移時，真正的問題是定義你的目的地，並儘快到達那裏——得到所有利益相關者的支持。好消息是，許多組織已經進行了這種遷移。這 5 個成功的單體到微服務遷移的要素來自我們所合作的一些最好的工程組織的集體經驗。很明顯，他們已經喫過不少苦頭。讓我們從中汲取教訓。

作者介紹：

Beyang Liu，Sourcegraph 的首席技術官和聯合創始人，Sourcegraph 是開發團隊的代碼智能平臺，讓更多的人可以使用編碼。在加入 Sourcegraph 之前，Beyang 是 Palantir Technologies 的軟件工程師，爲財富 500 強公司開發新的數據分析軟件。Beyang 在斯坦福大學學習計算機科學，他在斯坦福大學人工智能實驗室發表了概率圖模型和計算機視覺方面的研究論文。

原文鏈接：

https://about.sourcegraph.com/blog/monolith-microservices-migration/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9Mp4BA4MOkVrobP9q7u4cg