如何將傳統應用服務「直接遷移」至容器環境

已經準備好向容器遷移了嗎？若是你正考慮從現有非容器化的系統上將服務遷移到基於容器的環境中，那麼你必定想知道該如何實現它。有什麼正確的方法？有沒有最好的方法？或者說，有沒有某種直接遷移過程（lift-and-shift process）能夠適用於全部的應用程序？

一般來說，上述問題都有確定的答案。雖然因各公司的具體狀況不一樣，遷移到容器和微服務的具體細節會各有差別，可是對於實現應用程序從傳統基礎設施到容器環境的無縫遷移來講，仍是有一些普適性原則和最佳實踐經驗值得你們遵循。

這篇博文將簡要介紹成功將傳統應用程序遷移到容器的指導原則。

微服務——它們是什麼？

在處於項目遷移的最初規劃階段，關於容器化，最須要注意的是容器系統架構是基於（或應該基於）微服務的。那麼，微服務是什麼？

實際上，界定什麼是微服務、什麼不是微服務，這其間的標準是有些模糊的。這種狀況實際上是一種必然，由於不一樣的設計容器化應用程序的方法（咱們稍後會提到），正是基於不一樣的定義微服務的方法。

從整體上來講，微服務能夠描述爲一個基本的、功能分離的服務，它由應用程序的其餘部分調用。咱們能夠把從數據庫中檢索數據的服務看做是一個微服務，既能夠將數據發送到存儲設備，也能夠處理用戶輸入。

例如，在線上商店中，訪問庫存數據庫是由一個微服務處理，客戶的購物車由一個微服務更新，交易再由一個微服務完成，而且還有一個微服務處理信用卡的受權，而這些微服務都是獨立的。

而對於同一家店，能夠由多個微服務工做，一個微服務處理全部的數據庫訪問（庫存、客戶和銷售），一個微服務處理購物車和交易，而第三個微服務用作運輸物流。這種特定的微服務結構，在很大程度上是一種設計選擇，它取決於系統總體架構。

你當前的架構是什麼？

不過，在開始構建容器化應用程序以前，還須要着留意一下你當前的架構。宏觀上，非容器化的應用程序能夠大致分爲兩類：單體架構和SOA架構（服務導向架構）。當前架構不一樣，進行容器化重構的方法就不一樣，所以咱們先將它們區分開來，再討論設計選擇以及總體的重構策略。

單體架構

大多數傳統設計的應用程序都是單體架構。它們可能由單個包含了支持的庫、服務以及配置文件的程序，或者少許帶支持資源的程序組成。然而，在這兩種狀況下，大部分甚至所有的核心功能都包含在一個或幾個二進制文件中，其中服務就包含於這些在二進制文件定義的應用程序邊界內進行操做和通訊的功能中。桌面級的應用程序傳統上講是單體的，大多數基於網絡的應用程序也是如此。

在桌面或局域網環境中，單體架構一般是十分有效的。它的安裝和更新至關容易，而且單體的設計可以輕鬆地監控組件，並且桌面／LAN的使用通常不會對應用程序的資源形成太大的壓力。然而，在雲或互聯網的環境中，單體應用程序可能相對過於龐大、笨拙、緩慢，它們不只難以更新，且不可以處理大量的流量。另外，它們也不適用持續交付以及大多數構成DevOps的實踐。

若是想重構容器的單體架構應用，那可能須要在概念層面上進行全盤的從新設計。即使應用程序的架構已經至關清晰地定義了其內部服務，而且保證了它的離散性，實際拆分紅微服務時可能還須要對這些服務的邊界以及它們彼此通訊的方式進行大規模的更改。對於大多數的單體應用程序，許多服務都須要從新定義，甚至須要從頭開始定義。

SOA架構

有一些大型的非容器應用程序可能已經具備了基於服務的架構。例如，銷售點的應用程序可能包含了獨立的程序用來處理銷售、庫存、客戶記錄、訂單、運輸、差別、稅收、應收帳款以及應付帳款。每個模塊都是一個單獨的程序，具備明確的應用程序邊界，並且這種跨邊界的模塊間通訊和基於容器的應用程序十分類似。

若是有進行細分的須要，這種架構（假設它是使人滿意的）能夠做爲進一步分解成微服務的基礎。進一步分解能夠是基於現有的模塊分解成更小的服務，也能夠是基於抽象的廣義服務（好比訪問單個數據庫或打印收據的微服務），或者二者都是。另外一方面，若是現有模塊已是小容量、功能分散且組織良好的，那麼只須要進行極少的修改就能夠將其遷移到容器中。

對於單體應用你要怎麼作？

在這一點上，應該弄清楚的是，將單體應用程序分解成微服務一般是一個複雜而極具挑戰的工做。就像以前說的那樣，首先是根據微服務從新定義架構。這裏的從新定義以及實際細分紅微服務自己的過程一般稱爲分解（decomposition）。關於分解有一些基本的模式。在不少狀況下，瞭解這些模式的基礎和基本性質比選擇哪一種模式更重要，而在實際生產中，根據系統的功能要求，將單體應用程序分解成微服務時經常涉及到多種模式。

根據用例分解

用例是指用戶在執行任務時一般會採起的一組操做。用戶既能夠是實際的人，能夠是應用程序的另外一部分，也能夠是外部的應用程序。用例的關鍵要素是它是與任務相關聯的一組可定義的動做。在線上商店的例子中，一組客戶操做（如選擇和購買商品）就能夠是一個用例，單純的內部操做也能夠是用例，例如在銷售以後更新庫存、客戶信息以及交易數據庫。

根據功能分解

根據功能分解是分解的另外一種常見模式。例如，銷售交易能夠是一個由功能定義的單元，而信用受權能夠做爲由功能定義的另外一個服務。你能夠根據諸如差別跟蹤、運輸和自動補貨這些功能來定義功能域。功能分解和用例分解很是類似，不過它的定義更多的是由須要執行的行爲決定而非執行的對象。

根據資源分解

在多數狀況下，根據資源定義特定的微服務無疑是最好的方案。例如，你能夠定義一個單一的微服務來處理全部與具體某個數據庫或一組數據庫的交互，或者處理全部與持久存儲器的交互。在許多方面，設備驅動程序是基於資源的微服務。若是經過某種相似於設備驅動程序的通用服務來和資源進行交互是有意義的，那麼將該服務定義爲微服務也可能有實際價值。

分解途徑

肯定了分解單體應用的總體模式後，就能夠開始將其分解成微服務。你的最終目標應該是將整個應用程序縮成一組微服務層級的容器，它們和原始的單體應用同樣，提供相同的一組服務（可以根據須要添加或改進功能），能夠根據須要進行管理和部署，並且相比之下有更出色的速度、流量以及靈活性。

比較好的一點是，你並不須要一會兒把它拆散。能夠將前面說的大型SOA架構做爲中間階段。你能夠在開始的時候將單體應用程序拆成大型的基於服務的塊，而後再將其細分紅愈來愈小的服務，直到最終達到指望目標級別的微服務。而這裏還有另外一種方案，你能夠從定義明確的服務入手，先將這些服務拆分紅基於容器的微服務，而後再以相似先前的方法，分幾回拆分應用程序的其他部分。

不管採起哪一種方法，必定要牢記一點，那就是要明肯定義微服務，並且這些定義在應用程序的總體功能和架構上都應該是有實際意義的。只要你遵循了這些原則，相信你的遷移工做就會成功。