如何將Weblogic從虛擬機遷移到容器

隨著PaaS和DevOps解決方案需求的增漲，我們可以看到那些運行在虛擬機上或直接運行在裸機上的遺留應用程序，在實踐時會遇到一系列的障礙。分解和遷移的過程復雜度非常高。通常，為了獲得PaaS或CaaS模式的好處，應用程序所有者必須去重新設計他們的應用架構。

在這個文章裡，我們將分析把運行在虛擬機上的Java 遺留應用程序遷移到基於容器平台上的具體挑戰。使用Oracle WebLogic Server做為案例，我們將展示分解過程的具體步驟和遷移的結果。

遷移到容器的動機

對比Java EE應用運行在裸機的時代，硬件虛擬化已經是一個很大的進步。它給了我們解決多個應用間隔離及提高硬件利用率的能力。然而，Hypervisors（虛擬機管理程序）在宿主機上會使用大量CPU和內存，且每個虛擬機都要求擁有完整的操作系統、TCP棧和文件系統。

每個虛擬機都有固定的內存，只有部分的虛擬機管理程序可以為通過內存膨脹（memory ballooning）機制的幫助為運行中的虛擬機重新分配內存。所以為了應用程序未來的規模，我們在每個虛擬機裡都會預留一些資源，但這些資源並沒有得到完全的利用。同時，由於在一個虛擬機內實例間缺乏適當的隔離，這些資源也不能被其他的程序共享。

而容器通過共享宿主機的OS kernel、TCP棧、文件系統和其他的系統資源，僅使用很少的資源和CPU就可以運行，進一步提高了性能和資源利用率。

這裡有兩種類型的容器——應用容器和系統容器。通常，一個應用容器運行時相當於一個單進程。而一個系統容器則像一個完整的操作系統，可以在一個單容器內執行操作系統所有的功能，比如systemd、SysVinit和通過openrc產生其他類似openssh、crond and syslogd的進程。兩種類型的容器在不同的使用場景都非常有用，而且在冗余管理進程上不浪費內存，通常消耗的內存比虛擬機少。然而，對於Java遺留應用程序的遷移只有使用系統容器可以不需要大量的應用重構。

不同於虛擬機，對於運行中實例的容器資源的不需要重啟就可以很容易修改限制。而且這些在限制邊界內沒有被消耗的資源自動與在同一個物理節點上的其他容器共享。

此外，容器對於開發而言也非常有用，在創建，打包，測試應用方面用一種敏捷的方式加快應用的開始進度和提高應用的可擴展性。

這些在物理機上沒有被利用的資源可以很容易彈性擴展或新應用的容器使用。考慮到提高容器的隔離，不同類型的應用可以運行在相同的物理節點而不相互影響。這些可以平均提高已存在的基礎設備資源利用率的3-10倍。

什麼是分解

在遷移過程中，程序分解是基本部分，它可以幫助把大的單塊應用分解成小的，按邏輯塊劃分的，和可以獨立運行程序。

以圖中顯示的是在從虛擬機遷移到容器時應用的一個簡單的分解過程：

在虛擬機中運行Java遺留應用程序

在軟件程序開發裡有句老話：遺留軟件是好的，只不過是還在運行的舊軟件。下面通過案例讓我們更精確的知道在Oracle Weblogic Server上它是怎麼工作的。

在虛擬機中Oracle Weblogic Server的結構

在虛擬機中運行時，Weblogic Server包含三種類型的實例：

• Administration Server.（管理服務器）
• Node Manager.（節點管理器）
• Managed Server.（被管理服務器）

管理服務器是中心節點，通過它可以配置和管理集群中的所有資源。它通過與節點管理器連接增加或刪除被管理節點。而被管理節點運行Web應用、EJBs、Web service和其他的資源。

通常，每個虛擬機上運行一個節點管理器和多個被管服務服務器，而一個管理服務器則管理所有虛擬機上的所有實例。

通過虛擬機擴展 WebLogic

現在想象一下遇到流量高峰期需要擴展集群，新的被管服務器將會被加入到虛擬機中用於處理增長的負載，直到沒有資源分配。

但是當流量還在不斷增長，而當前被管理服務的實例數量不足以處理負載時，則需要增加一個新的虛擬機去處理程序的進一步增長的業務規模。

典型的通過多個虛擬機對WebLogic進行擴展包括三個步驟：

1. 提供一個提前配置好 Weblogic Server 模板的新虛擬機
2. 在新的虛擬機上啟動一個節點管理器，並連接到管理服務器上
3. 添加一個新的被管理服務器處理部分增長的業務負載

然後，這個擴展的步驟重復，在新增加的虛擬啟動更多的被管理服務器直到資源限制。

在虛擬機中運行WebLogic的劣勢

這樣運行Oracle WebLogic是一種資源利用率非常低下的方式，這裡有幾個資源浪費或未使用的點：

1. 每個虛擬機要求擁有完整的操作系統，TCP 棧和文件系統，這些需要使用宿主機大量的 CPU 和內存。
2. 這些資源的分配並非高度微粒化，在某些場景，所有當我們只需要增加一個被管理服務器時也需要去准備一個完整的虛擬機。
3. 如果當一個虛擬機的資源不足時，添加額外的 CPU 或僅是增加內存也需要重啟整個虛擬機。
4. 每個虛擬機都需要節點管理器用來增加或刪除被管理節點，需要消耗額外的資源和增加額外復雜的配置。
5. 在同一個虛擬機裡運行的實例由於缺少隔離會相互影響，從而影響整個應用的性能。也出於這個原因，我們不能在同一個虛擬機上混合搭配運行不同的應用程序。
6. 虛擬機的可移植性受限於一個廠商，所以當我們想從一個雲遷移到另一個雲會有一系列的問題。
7. 在虛擬機上做模板打包和實施CI/CD會非常慢和過程復雜。

從虛擬機遷移到容器

這些天，我們找到多個設計用來在容器裡運行微服務的優秀應用服務器和框架，比如 Spring Boot、WildFly Swarm、Payara Micro等等。無論如何，有一系列的服務器設計運行在虛擬機，比如Oracle WebLogic Server，這種類型的實例遷移到容器裡的任務更加復雜。這就是為什麼我們更關注這個主題。

WebLogic Server的分解

這些天通過Docker容器的幫助這個分解是一個相當容易的任務。首先，我們需要准備一個有WebLogic Server的容器鏡像。（鏡像可從Oracle的官方倉庫獲得）。

當Docker模板已經准備好，我們規定每個實例在獨立的容器裡：一個管理服務器和需要數量的被管理服務器。

在這裡，我們放棄了用於增加和刪除被管理節點的節點管理器。

遷移到容器後，和直接使用管理節點一樣，通過容器編排平台和一系列WSLT腳本，被管理服務器實例可以被自動增加和刪除。

這樣，我們就得到了一個非常簡單的Weblogic Server Cluster結構。

因為容器比從頭開始配置或克隆更容易，這樣水平擴展過程變得非常細顆粒和平滑。還有，每個容器可以被快速啟動或停止，幾乎沒有停機時間。當和虛擬機對比時容器更加輕量，所以調度容器時比調度虛擬機使用更少的時間。

雖然將應用遷移到容器裡是一個挑戰，但是如果你知道怎麼管理它，可以獲得如下的好處：

1. 每個容器消除獨立的完整操作系統，TCP 棧和文件系統可以減少系統資源（ CPU 和內存）的使用。
2. 通過在集群拓撲裡刪除節點管理器可以簡化水平擴展。
3. 通過容器可以共享未使用資源的能力可以自動化垂直擴展，而且不需要重啟就可以重新配置，非常容易。
4. 通過在同一個物理機上使用獨立的容器隔離運行不同的應用，提高基礎設備的利用率。
5. 通過容器的可移植性解除在不同雲廠商的遷移約束。

可以使用相同的方式幫助分解應用的其他層，或應用其他的Java EE應用服務。在下一個主題，我們會通過一個特定的案例描述怎麼處理分解後數據的全過程。