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

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

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

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

重構基礎

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

重構=從新設計

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

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

經過現有的單體式應用程序，您可能會清楚地瞭解各類組件如何協同工做，以及應用程序如何做爲一個總體運行的。而使人驚奇的是，從單體式的應用程序開始，您能夠更深刻地瞭解微服務之間的界限。經過觀察他們是如何協做的，您能夠更容易地看到，某個微服務可以獨立於另外一個微服務。

重構並不通用

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

通常重構策略

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

增量

經過此策略，您能夠逐個重構應用程序。隨着時間的推移，這些組件一般是大規模的服務或相關服務組。要成功作到這一點，首先須要確立應用程序中的大範圍邊界，而後針對這些邊界定義的單元進行重構，一次一個單元。您將持續不斷地把每一個大區域移動到微服務中，直到最終沒有原始應用程序爲止。

大變小

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

此策略的主要優勢是，它容許您穩定重構單元之間的交互，而後將它們分解爲下一級，並在您開始下一輪重構以前，讓您更清晰地瞭解較低層服務之間的邊界和交互。

批量替換

經過批發更換，您能夠一次性重構整個應用程序，直接從單體式轉移到一組微服務器。它的優點在於，它容許您從頂層架構下進行從新設計，爲重構做準備。雖然這一策略與微服務不同，但它確實與微服務有着相同的風險，特別是當它涉及到普遍的從新設計時。

重構中的基本步驟

那麼，將一個單體式應用程序重構爲微服務的基本步驟是什麼？有幾種方法能夠打破這個流程，但對於大多數重構項目來講，如下五個步驟是（或應該）通用的。

（1）準備工做

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

（2）設計：微服務域

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

• 功能域。相同功能域內的微服務執行一組相關功能，或具備相關性的職責。例如，購物車和結賬服務能夠包含在相同的功能域中，而庫存管理服務將佔用另外一個域。
• 使用域。若是您經過使用破解您的微服務器，那麼每一個域將圍繞一個用例，或者更常見的，一組相互關聯的用例。用例一般圍繞用戶（我的或其餘應用程序）採起的一組相關行動，例如選擇購買商品或輸入付款信息。
• 資源域。訪問相關資源組（如數據庫、存儲或外部設備）的微服務也能夠造成不一樣的域。這些微服務一般會處理這些資源與全部其餘域和服務的交互。

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

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

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

（4）重構

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

（5）測試

當您進行測試時，您須要在基礎架構（包括容器/ VM部署和資源使用）級別以及總體應用級別上查找微服務和微服務交互級別的問題。經過使用基於微服務的應用程序，全部這些都很重要，每一個應用程序均可能須要本身的一套測試/監視工具和資源。當您發現問題時，瞭解什麼級別的問題應該被處理是很是重要的。

結論

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

---

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

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

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