遷移你的單體系統：最佳實踐和關注領域

假設有這樣一種情況：你有一個對你的業務十分重要的複雜單體系統，你已經閱讀過相關的文章，希望将這一系統遷移到更加先進的、使用微服務和容器的平台上，但又不知道從何入手。

如果你正面臨着這一問題，那麼這篇文章一定會幫到你。接下來，我将從最佳實踐以及需要關注的領域兩個方面，幫助你将單體應用程式演進為面向微服務的應用程式。

概述

毋庸置疑，完全從頭做起的、從基于容器的雲服務開始入手的“綠地開發模式（Greenfield Development）“是最理想的開發模式。然而，對大多數開發團隊而言，這并不現實。大多數開發團隊要為多個已經存在幾年的應用程式提供支援，并且需要利用現代工具集和平台對它們進行重構，這通常稱為”棕地模式開發（Brownfield Development）“。

并非所有的應用程式技術都可以輕松放入容器。我們可以通過一番工作讓現有的應用去适應容器，但疑問也随之而來：這樣做是否真的值得？例如，你确實可以将整個大規模的應用程式遷移到容器或者雲平台上，但這麼做真的可以明顯地提高靈活性或是降低成本嗎？

評估所有現有元件

對應用程式的目前狀态及其基礎堆棧進行評估，這聽起來并非一個革命性或創造性的想法，但是當你完整評估了所有的網絡和基礎架構元件之後，可以說你已經取得了階段性的成功。你未必必須直接涉及應用程式的核心，小而漸進式的步驟才是讓你的合作夥伴和支援團隊更輕松地使用容器的最佳方式。

舉一些容器友好的基礎架構元件案例：Web伺服器（如Apache HTTPD）、反向代理和負載均衡器（如haproxy）、高速緩存元件（如memcached）、甚至是隊列管理器（如IBM MQ）。

假如你處于這樣一種極端的情況：如果應用程式是Java編寫的，那麼可以讓更輕量的Java EE容器在Docker中運作而不需要拆分應用程式嗎？對這一問題，WebLogic、JBoss（Wildfly）和WebSphere Liberty是适用于Docker的Java EE容器的絕佳案例。

厘清現有應用元件

現在，基礎設施層的容器已經開始運作，現在可以在應用程式内部查找元件的邏輯分解。例如，使用者接口是否可以作為單獨的可部署應用程式分割出來？一部分的UI是否可以綁定到特定的後端元件并單獨地部署（比如帶有結算業務邏輯的計費界面）？

在将應用程式元件組合成為單獨的工件時，有兩個重要的注意事項：

1.

在單體應用程式中，總有一些共享庫，它們會在一個新的微服務模型中被多次部署。多次部署帶來的好處是每個微服務都可以遵循它自己的更新計劃。僅因為一個公共庫有新的特性，并不意味着每個人都需要它，且每個人都必須立即更新。

2.

除非有一種非常明顯的方式來分開資料庫（如多schemas）或者該特性跨越多個資料庫，不然的話就放棄它。單體應用程式傾向于交叉引用表，并建構典型的“屬于”一個或多個其他元件的自定義視圖，因為原始表是現成的，在時效上是公認的快。

下一步：業務改進

如果到這一步你已經完成，取得了一些進展，并且可能已經确定了可拆分成單獨可部署工件的應用程式元件，那麼現在是時候将業務改進作為你的首要發展道路，将應用程式重新設計為更小的基于容器的應用程式，這些最終将成為你的微服務。

如果你已将賬單作為想要從主應用程式拆分出來的第一個區域，那麼就需要完成與那些應用元件相關的所需增強功能和bug修複。一旦你已經準備好釋出，将它們部署上去，并且将分離包含在釋出版本中。

随着對應用程式的不斷剝離，你的團隊将會更加熟悉如何拆分元件，并且将它們放入自己的容器中。

結論

當将單體應用程式分解并部署為一系列使用容器的小型應用程式時，它将在效率上達到一個新高度。根據實際負載（而不是簡單的建構峰值負載）獨立擴充每個元件，更新單個元件（無需重新測試和重新部署所有内容）将大大縮短花費在QA上以及獲得變更管理的準許的時間。由此可見，在容器上運作不同功能的小型應用會是未來（更有效）的方式。

原文連結：http://rancher.com/moving-your-monolith/

3月22日晚微信技術群分享等你來哦~具體内容及參與方式如下：

微信号：RancherLabs