如何將傳統(tǒng)應(yīng)用服務(wù)“直接遷移”至容器環(huán)境

YPHP 發(fā)布于2019-06-28 16:03 / 855人閱讀

摘要：已經(jīng)準(zhǔn)備好向容器遷移了嗎如果你正考慮從現(xiàn)有非容器化的系統(tǒng)上將服務(wù)遷移到基于容器的環(huán)境中，那么你一定想知道該如何實(shí)現(xiàn)它。這篇博文將簡(jiǎn)要介紹成功將傳統(tǒng)應(yīng)用程序遷移到容器的指導(dǎo)原則。單體架構(gòu)大多數(shù)傳統(tǒng)設(shè)計(jì)的應(yīng)用程序都是單體架構(gòu)。

已經(jīng)準(zhǔn)備好向容器遷移了嗎？如果你正考慮從現(xiàn)有非容器化的系統(tǒng)上將服務(wù)遷移到基于容器的環(huán)境中，那么你一定想知道該如何實(shí)現(xiàn)它。有什么正確的方法？有沒有最好的方法？或者說(shuō)，有沒有某種直接遷移過程（lift-and-shift process）可以適用于所有的應(yīng)用程序？

通常來(lái)講，上述問題都有肯定的答案。雖然因各公司的具體情況不同，遷移到容器和微服務(wù)的具體細(xì)節(jié)會(huì)各有差異，但是對(duì)于實(shí)現(xiàn)應(yīng)用程序從傳統(tǒng)基礎(chǔ)設(shè)施到容器環(huán)境的無(wú)縫遷移來(lái)說(shuō)，還是有一些普適性原則和最佳實(shí)踐經(jīng)驗(yàn)值得大家遵循。

這篇博文將簡(jiǎn)要介紹成功將傳統(tǒng)應(yīng)用程序遷移到容器的指導(dǎo)原則。

微服務(wù)——它們是什么？

在處于項(xiàng)目遷移的最初規(guī)劃階段，關(guān)于容器化，最需要注意的是容器系統(tǒng)架構(gòu)是基于（或應(yīng)該基于）微服務(wù)的。那么，微服務(wù)是什么？

實(shí)際上，界定什么是微服務(wù)、什么不是微服務(wù)，這其間的標(biāo)準(zhǔn)是有些模糊的。這種情況其實(shí)是一種必然，因?yàn)椴煌脑O(shè)計(jì)容器化應(yīng)用程序的方法（我們稍后會(huì)提到），正是基于不同的定義微服務(wù)的方法。

從總體上來(lái)說(shuō)，微服務(wù)可以描述為一個(gè)基本的、功能分離的服務(wù)，它由應(yīng)用程序的其他部分調(diào)用。我們可以把從數(shù)據(jù)庫(kù)中檢索數(shù)據(jù)的服務(wù)看作是一個(gè)微服務(wù)，既可以將數(shù)據(jù)發(fā)送到存儲(chǔ)設(shè)備，也可以處理用戶輸入。

例如，在線上商店中，訪問庫(kù)存數(shù)據(jù)庫(kù)是由一個(gè)微服務(wù)處理，客戶的購(gòu)物車由一個(gè)微服務(wù)更新，交易再由一個(gè)微服務(wù)完成，并且還有一個(gè)微服務(wù)處理信用卡的授權(quán)，而這些微服務(wù)都是獨(dú)立的。

而對(duì)于同一家店，可以由多個(gè)微服務(wù)工作，一個(gè)微服務(wù)處理所有的數(shù)據(jù)庫(kù)訪問（庫(kù)存、客戶和銷售），一個(gè)微服務(wù)處理購(gòu)物車和交易，而第三個(gè)微服務(wù)用做運(yùn)輸物流。這種特定的微服務(wù)結(jié)構(gòu)，在很大程度上是一種設(shè)計(jì)選擇，它取決于系統(tǒng)整體架構(gòu)。

你當(dāng)前的架構(gòu)是什么？

不過，在開始構(gòu)建容器化應(yīng)用程序之前，還需要著留意一下你當(dāng)前的架構(gòu)。宏觀上，非容器化的應(yīng)用程序可以大體分為兩類：?jiǎn)误w架構(gòu)和SOA架構(gòu)（服務(wù)導(dǎo)向架構(gòu)）。當(dāng)前架構(gòu)不同，進(jìn)行容器化重構(gòu)的方法就不同，因此我們先將它們區(qū)分開來(lái)，再討論設(shè)計(jì)選擇以及整體的重構(gòu)策略。

單體架構(gòu)

大多數(shù)傳統(tǒng)設(shè)計(jì)的應(yīng)用程序都是單體架構(gòu)。它們可能由單個(gè)包含了支持的庫(kù)、服務(wù)以及配置文件的程序，或者少量帶支持資源的程序組成。然而，在這兩種情況下，大部分甚至全部的核心功能都包含在一個(gè)或幾個(gè)二進(jìn)制文件中，其中服務(wù)就包含于這些在二進(jìn)制文件定義的應(yīng)用程序邊界內(nèi)進(jìn)行操作和通信的功能中。桌面級(jí)的應(yīng)用程序傳統(tǒng)上講是單體的，大多數(shù)基于網(wǎng)絡(luò)的應(yīng)用程序也是如此。

在桌面或局域網(wǎng)環(huán)境中，單體架構(gòu)通常是十分有效的。它的安裝和更新相當(dāng)容易，并且單體的設(shè)計(jì)能夠輕松地監(jiān)控組件，而且桌面／LAN的使用一般不會(huì)對(duì)應(yīng)用程序的資源造成太大的壓力。然而，在云或互聯(lián)網(wǎng)的環(huán)境中，單體應(yīng)用程序可能相對(duì)過于龐大、笨拙、緩慢，它們不僅難以更新，且不能夠處理大量的流量。另外，它們也不適用持續(xù)交付以及大多數(shù)構(gòu)成DevOps的實(shí)踐。

如果想重構(gòu)容器的單體架構(gòu)應(yīng)用，那可能需要在概念層面上進(jìn)行全盤的重新設(shè)計(jì)。即便應(yīng)用程序的架構(gòu)已經(jīng)相當(dāng)清晰地定義了其內(nèi)部服務(wù)，并且保證了它的離散性，實(shí)際拆分成微服務(wù)時(shí)可能還需要對(duì)這些服務(wù)的邊界以及它們彼此通信的方式進(jìn)行大規(guī)模的更改。對(duì)于大多數(shù)的單體應(yīng)用程序，許多服務(wù)都需要重新定義，甚至需要從頭開始定義。

SOA架構(gòu)

有一些大型的非容器應(yīng)用程序可能已經(jīng)具有了基于服務(wù)的架構(gòu)。例如，銷售點(diǎn)的應(yīng)用程序可能包含了獨(dú)立的程序用來(lái)處理銷售、庫(kù)存、客戶記錄、訂單、運(yùn)輸、差異、稅收、應(yīng)收賬款以及應(yīng)付賬款。每一個(gè)模塊都是一個(gè)多帶帶的程序，具有明確的應(yīng)用程序邊界，而且這種跨邊界的模塊間通信和基于容器的應(yīng)用程序十分相似。

如果有進(jìn)行細(xì)分的需要，這種架構(gòu)（假設(shè)它是令人滿意的）可以作為進(jìn)一步分解成微服務(wù)的基礎(chǔ)。進(jìn)一步分解可以是基于現(xiàn)有的模塊分解成更小的服務(wù)，也可以是基于抽象的廣義服務(wù)（比如訪問單個(gè)數(shù)據(jù)庫(kù)或打印收據(jù)的微服務(wù)），或者兩者都是。另一方面，如果現(xiàn)有模塊已經(jīng)是小容量、功能分散且組織良好的，那么只需要進(jìn)行極少的修改就可以將其遷移到容器中。

對(duì)于單體應(yīng)用你要怎么做？

在這一點(diǎn)上，應(yīng)該弄清楚的是，將單體應(yīng)用程序分解成微服務(wù)通常是一個(gè)復(fù)雜而極具挑戰(zhàn)的工作。就像之前說(shuō)的那樣，首先是根據(jù)微服務(wù)重新定義架構(gòu)。這里的重新定義以及實(shí)際細(xì)分成微服務(wù)本身的過程通常稱為分解（decomposition）。關(guān)于分解有一些基本的模式。在很多情況下，了解這些模式的基礎(chǔ)和基本性質(zhì)比選擇哪種模式更重要，而在實(shí)際生產(chǎn)中，根據(jù)系統(tǒng)的功能要求，將單體應(yīng)用程序分解成微服務(wù)時(shí)常常涉及到多種模式。

根據(jù)用例分解

用例是指用戶在執(zhí)行任務(wù)時(shí)通常會(huì)采取的一組操作。用戶既可以是實(shí)際的人，可以是應(yīng)用程序的另一部分，也可以是外部的應(yīng)用程序。用例的關(guān)鍵要素是它是與任務(wù)相關(guān)聯(lián)的一組可定義的動(dòng)作。在線上商店的例子中，一組客戶操作（如選擇和購(gòu)買商品）就可以是一個(gè)用例，單純的內(nèi)部操作也可以是用例，例如在銷售之后更新庫(kù)存、客戶信息以及交易數(shù)據(jù)庫(kù)。

根據(jù)功能分解

根據(jù)功能分解是分解的另一種常見模式。例如，銷售交易可以是一個(gè)由功能定義的單元，而信用授權(quán)可以作為由功能定義的另一個(gè)服務(wù)。你可以根據(jù)諸如差異跟蹤、運(yùn)輸和自動(dòng)補(bǔ)貨這些功能來(lái)定義功能域。功能分解和用例分解非常相似，不過它的定義更多的是由需要執(zhí)行的行為決定而非執(zhí)行的對(duì)象。

根據(jù)資源分解

在多數(shù)情況下，根據(jù)資源定義特定的微服務(wù)無(wú)疑是最好的方案。例如，你可以定義一個(gè)單一的微服務(wù)來(lái)處理所有與具體某個(gè)數(shù)據(jù)庫(kù)或一組數(shù)據(jù)庫(kù)的交互，或者處理所有與持久存儲(chǔ)器的交互。在許多方面，設(shè)備驅(qū)動(dòng)程序是基于資源的微服務(wù)。如果通過某種類似于設(shè)備驅(qū)動(dòng)程序的通用服務(wù)來(lái)和資源進(jìn)行交互是有意義的，那么將該服務(wù)定義為微服務(wù)也可能有實(shí)際價(jià)值。

分解途徑

確定了分解單體應(yīng)用的整體模式后，就可以開始將其分解成微服務(wù)。你的最終目標(biāo)應(yīng)該是將整個(gè)應(yīng)用程序縮成一組微服務(wù)層級(jí)的容器，它們和原始的單體應(yīng)用一樣，提供相同的一組服務(wù)（能夠根據(jù)需要添加或改進(jìn)功能），可以根據(jù)需要進(jìn)行管理和部署，而且相比之下有更出色的速度、流量以及靈活性。

比較好的一點(diǎn)是，你并不需要一下子把它拆散。可以將前面說(shuō)的大型SOA架構(gòu)作為中間階段。你可以在開始的時(shí)候?qū)误w應(yīng)用程序拆成大型的基于服務(wù)的塊，然后再將其細(xì)分成越來(lái)越小的服務(wù)，直到最終達(dá)到期望目標(biāo)級(jí)別的微服務(wù)。而這里還有另一種方案，你可以從定義明確的服務(wù)入手，先將這些服務(wù)拆分成基于容器的微服務(wù)，然后再以類似先前的方法，分幾次拆分應(yīng)用程序的其余部分。

無(wú)論采取哪種方法，一定要牢記一點(diǎn)，那就是要明確定義微服務(wù)，而且這些定義在應(yīng)用程序的整體功能和架構(gòu)上都應(yīng)該是有實(shí)際意義的。只要你遵循了這些原則，相信你的遷移工作就會(huì)成功。