如何用微服務重構應用程式

在決定使用微服務之後，為了将微服務付諸實踐，也許你已經開始重構你的應用程式或把重構工作列入了待辦事項清單。

無論是哪種情況，如果這是你第一次重構應用程式，那麼您和您的團隊必将在某個時刻面臨一個顯而易見的問題：如何重構應用程式以實作微服務？

這也正是這篇文章要思考和探讨的。

重構基礎

在讨論如何将重構轉化為微服務之前，退後一步，仔細觀察微服務的内容和時間是很重要的。以下兩個要點将會對任何微服務重構政策産生重大影響。

重構=重新設計

将一個單體式的應用程式重構為微服務，與重新設計一個基于微服務的應用程式, 有着本質差別。也許您更傾向于摒棄舊的應用程式（特别是面對雜亂無序的舊應用程式，這些應用程式在更新檔修改和加強補充方面帶來了沉重的技術債負擔），制定一套新的需求, 并從零開始建立一個全新的應用程式，直接在微服務級别工作。

通過現有的單體式應用程式，您可能會清楚地了解各種元件如何協同工作，以及應用程式如何作為一個整體運作的。而令人驚奇的是，從單體式的應用程式開始，您可以更深入地了解微服務之間的界限。通過觀察他們是如何協作的，您可以更容易地看到，某個微服務能夠獨立于另一個微服務。

重構并不通用

對于重構，不存在一種适用一切的通用性方法，您所做的設計選擇，從整體架構到代碼級，都應考慮到應用程式的功能、運作條件以及開發平台和程式設計語言等因素。例如，您可能需要考慮代碼打包—如果您正在使用Java，則可能涉及從大型企業應用程式存檔（EAR）檔案（每個檔案可能包含多個Web應用程式存檔（WAR）軟體包）轉移到單獨的 WAR檔案。

一般重構政策

以上是我們介紹的高層次考慮因素，現在讓我們來看看重構的實作政策。對于現有的單體式應用程式進行重構，有三種基本方法。

增量

通過此政策，您可以逐個重構應用程式。随着時間的推移，這些元件通常是大規模的服務或相關服務組。要成功做到這一點，首先需要确立應用程式中的大範圍邊界，然後針對這些邊界定義的單元進行重構，一次一個單元。您将持續不斷地把每個大區域移動到微服務中，直到最終沒有原始應用程式為止。

大變小

“大到小”政策在許多方面都是對增量重構基本主題的變體。然而，在大到小的重構中，您首先要将應用程式重構為單獨的、大規模的、“粗粒度的”(使用Fowler的術語)塊，然後逐漸将它們分解成更小的單元，直到整個應用程式被重構為真正的微服務。

此政策的主要優點是，它允許您穩定重構單元之間的互動，然後将它們分解為下一級，并在您開始下一輪重構之前，讓您更清晰地了解較低層服務之間的邊界和互動。

批量替換

通過批發更換，您可以一次性重構整個應用程式，直接從單體式轉移到一組微伺服器。它的優勢在于，它允許您從頂層架構下進行重新設計，為重構作準備。雖然這一政策與微服務不一樣，但它确實與微服務有着相同的風險，特别是當它涉及到廣泛的重新設計時。

重構中的基本步驟

那麼，将一個單體式應用程式重構為微服務的基本步驟是什麼？有幾種方法可以打破這個流程，但對于大多數重構項目來說，以下五個步驟是（或應該）通用的。

（1）準備工作

迄今為止我們所讨論的大部分是準備工作。要牢記的要點是，在重構現有的單體式應用程式之前，大架構以及要進行重構的基于微服務的版本的功能應已就緒。在重構時試圖修複功能失調的應用程式，這隻會使兩項工作更加困難。

（2）設計：微服務域

在大規模、應用廣泛的架構之下，您需要在重構之前制定（并應用）一些設計決策。特别是，您需要考慮哪種微服務組織形式最适合您的應用程式。組織微服務最自然的方式通常是進入基于通用功能、使用或資源通路的域：

功能域。相同功能域内的微服務執行一組相關功能，或具有相關性的職責。例如，購物車和結帳服務可以包含在相同的功能域中，而庫存管理服務将占用另一個域。

使用域。如果您通過使用破解您的微伺服器，那麼每個域将圍繞一個用例，或者更常見的，一組互相關聯的用例。用例通常圍繞使用者（個人或其他應用程式）采取的一組相關行動，例如選擇購買商品或輸入付款資訊。

資源域。通路相關資源組（如資料庫、存儲或外部裝置）的微服務也可以形成不同的域。這些微服務通常會處理這些資源與所有其他域和服務的互動。

請注意，在給定的應用程式中，三種組織形式都可能都存在。如果有一個總體規則，那麼簡單地說，您應該在它們最适合的時間和地點應用它們。

（3）設計：基礎設施和部署

此步驟非常重要，但卻很容易被視作事後再來考慮的問題。您正在将一個應用程式轉換為一種非常動态的微服務群，通常在容器或虛拟機中，并由可能由多個應用程式組合的基礎架構部署、編排和監控。此基礎架構是您應用程式架構的一部分; 它可能（并且可能會）接管以前在單體式應用程式中由進階架構處理的一些職責。

（4）重構

這是您将應用程式代碼實際重構為微服務的一個重點。确立微服務邊界，識别每個微服務候選項的依賴關系，在代碼和單元架構級别上進行必要的更改，以便它們可以作為獨立的微服務來容納，并将其封裝在容器或VM中。這不會是一個沒有問題的過程，因為在主要應用程式的規模上重寫代碼非常不易，但是，隻要準備充分，您遇到的問題就更有可能局限于現有的代碼問題。

（5）測試

當您進行測試時，您需要在基礎架構（包括容器/ VM部署和資源使用）級别以及整體應用級别上查找微服務和微服務互動級别的問題。通過使用基于微服務的應用程式，所有這些都很重要，每個應用程式都可能需要自己的一套測試/監視工具和資源。當您發現問題時，了解什麼級别的問題應該被處理是非常重要的。

結論

對微服務的重構可能需要下些功夫，但這并不難。隻要您能做好準備，并清楚地了解所涉及的問題，您就能有效地重構您的微服務應用，而無需從頭到尾重新設計。

本文轉自 RancherLabs 51CTO部落格，原文連結:http://blog.51cto.com/12462495/1946982