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

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

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

概述

毋庸置疑，徹底從頭作起的、從基於容器的雲服務開始入手的「綠地開發模式（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/