摘要：以下兩個要點將會對任何微服務重構策略產生重大影響。批量替換通過批發更換，您可以一次性重構整個應用程序，直接從單體式轉移到一組微服務器。如果您通過使用破解您的微服務器，那么每個域將圍繞一個用例，或者更常見的，一組相互關聯的用例。

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

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

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

在討論如何將重構轉化為微服務之前，退后一步，仔細觀察微服務的內容和時間是很重要的。以下兩個要點將會對任何微服務重構策略產生重大影響。

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

正如Martin Fowler在這篇文章中所指出，在微服務級設計一個新的應用程序可能不是一個好主意。Fowler的分析中最重要的一點是，在移動到基于微服務的架構時，從現有的單體式應用程序開始可以真正發揮微服務的優勢。

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

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

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

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

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

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

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

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

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

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

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

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

資源域。訪問相關資源組（如數據庫、存儲或外部設備）的微服務也可以形成不同的域。這些微服務通常會處理這些資源與所有其他域和服務的交互。

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

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

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

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

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

9月27日，北京海航萬豪酒店，容器技術大會Container Day 2017即將舉行。

CloudStack之父、海航科技技術總監、華為PaaS部門部長、恒豐銀行科技部總經理、阿里云PaaS工程總監、民生保險CIO······均已加入豪華講師套餐！

11家已容器落地企業，15位真·云計算大咖，13場純·技術演講，結合實戰場景，聚焦落地經驗。免費參會+超高規格，詳細議程及注冊鏈接請戳