Docker的最佳實踐提出了“一個容器內只運行一個進程”之后，是否需要將應用拆分到多個容器中就成了一個熱門話題。本文以一個普通的Java應用作為討論，從軟件設計的角度來介紹為什么要將其拆分到多個容器中。
假設一個標準的Java Web應用包含以下兩部分：
基于Struts框架的前端應用; 基于Java EE的后端REST API服務;這兩部分通常運行在同一個容器（如Tomcat）中，相互之間基于REST接口進行交互。類似這種應用，我們應該將其拆分到不同的容器中運行嗎？
簡單的回答：我們應該將其拆分到不同的容器中，但這需要經過謹慎的考慮。
拋開一些“普適”的原則（如“一個容器只運行一個進程”），我們主要從應用本身和部署策略上進行考慮。
首先，我們拋開具體業務場景，做一些設計思考（Design Thinking）：
JVM本身支持多線程，因此通常的Java應用程序都運行在一個進程中，以多線程的方式進行并行處理。類似Tomcat這樣的容器本身也支持將多個Java應用程序運行在一個Java進程中。 事實上，很多已經容器化的應用，在容器中實際運行時也是多進程的,例如Apache的prefork模塊。同時，當前流行的網絡應用（如Nginx）大量使用事件驅動和反應器模式，這些設計的方向，都是將IO操作交給內核，將業務邏輯處理交給子進程（線程）。Linux內核非常善于調度子進程，但是這不是諸如Kubernetes、Swarm等容器調度工具擅長的地方。進程（線程）側重于內核資源的劃分，而容器側重于集群資源的劃分。 “一個容器只運行一個進程”的原則，更像一種哲學。作為工程師，我們應該從實際出發考慮技術架構和應用邏輯。同時這個“最佳實踐”甚至沒有獲得廣泛的贊同，它的傳播可能是因為對Unix運作原理缺乏了解導致的。 Linux容器（LXC）歷史上有很多種形式，其中很多是建議在一個容器中運行多個進程的。Linux容器實質上是clone系統調用、SELinux、cgroup等技術的組合，上層使用LXC或者Docker（libcontainer）對于這些底層技術是不相關的，因為最終都依賴于內核的隔離技術。 進程間交互有多種形式，如套接字、文件、網絡等，每種方式都有自己的優缺點。如果考慮將應用拆分到不同容器中，對應用程序內部組件之間的通信方式會有很大影響。 代碼、配置和數據的獨立性，也對是否能夠拆分到不同容器的重要考量。如果應用程序的代碼、配置和數據相互獨立性比較強，就能夠方便的將其拆分成獨立的組件，放置到獨立的容器中；反之，如果應用內部分層不清，拆分成本會非常高。值得注意的是，我們沒有必要為了容器化而對應用做過多的改造，只要能夠按照Docker鏡像的格式制作成鏡像，我們仍然能夠享受到Docker帶來的便利：方便的分發（利用Docker注冊中心）和運行（使用docker run命令）。上面總結了一些從系統層面看是否需要拆分到多個容器，回到我們的例子：
這兩個Java組件功能上相互獨立。一個是web前端，一個是API服務。由于它們是完全不同的服務，是否運行在一個JVM（Java進程）中對性能損耗非常小（當然，這只是相對的，因為它們將無法公用堆內存和垃圾回收）。 這兩個組件之間使用REST API進行交互，沒有使用傳統的進程間交互方式（套接字、共享內存等）。 web前端和API服務的使用場景不同，針對不同的場景，在運維層面可能需要獨立的進行擴容。例如除了web前端之外，API服務還能提供給其他組件使用，因此API服務可能會因為接入方的變化需要獨立擴容和縮容。這時候就是充分利用容器編排框架（如Kubernetes、Mesos、Swarm等）能力的時候了。基于上述三點考慮，我會將這個Java應用的兩個組件拆分到獨立的容器中。同時建議配合使用諸如Kubernetes的容器編排框架，將兩個服務關聯到一起。
總結一下我們的“最佳實踐”：
如果你的應用代碼、配置和數據相對獨立，并且有清晰的交互形式，將應用組件拆分到多個容器中是有意義的。
京公網安備 11010502049343號