什么时候应该将应用程序切分为多个容器？
围绕着应该将应用程序的哪些部分切分为多个容器以及为什么要这样做，存在着很多困惑。我最近对Docker用户邮箱列表的回应促成了今天的文章。在这篇文章中我打算评估一个镜像化的Java应用程序，它历史上曾经运行在一个单一的Tomcat服务器里，并解释为什么我会把它切分为独立的容器。为了让事情有趣——我也旨在证明这个动作（比如将应用程序分割为独立的容器）和数据及（工程）逻辑，而不是简单地说“有一个原则”，即必须在所有时间都遵守。
让我们看一个Java应用程序示例，由以下两部分组成： 基于Struts Web框架构建的一个前端应用 基于Java
EE构建的一个后端REST API
如前所述，这个应用程序历史上曾经跑在一个Tomcat服务器里，两个组件是通过一个基于REST的API进行通信的，所以问题变成了：
我应该要将这个应用程序切分成多个容器吗?
答案是肯定的，我相信这个应用程序应该切分为两个不同的Docker容器，但这应该经过慎重考虑之后。
而不是“仅仅因为”将应用程序切分成多个容器或试图坚持一些新奇的原则（比如“每个容器只运行一个进程”）——我建议我们应该通盘考虑项目需求然后做出明智和聪明的决定。是否所有的应用程序都应该切分为多个容器？容器化通过提供一个更简单的部署策略至少会使你的软件生涯更便捷。
让我们在示例应用程序的分析上做些短暂的停留，做一些设计思考：
JVM是多线程的，所以没有必要运行多个Unix/Linux进程。事实上，我认为这是Java工程师理所当然的困惑。从历史上看，Java开发人员实际上喜欢在同一个JVM里边运行多个应用程序，在实践中，这样做可以节省相当多的内存。此外，Web应用服务器比如Tomcat是打从一开始就支持在单个JVM上运行多个应用程序。这实际上是运行一个简单的Java程序相对于Java
EE应用程序（这可能是由多个线程和多个不同的程序组成）的主要区别。 在现实中，许多应用在每个容器中使用多个进程，Apache
Web服务器的Prefork和MPM和模块都在同一个容器中使用多个进程。现代的Web应用具有事件驱动编程或反应器模式的特性（例如Nginx），实际衍生了许多子进程。我认为，FastCGI、AIO以及反应器模式的整个理念是将工作分担给其他进程（或线程），而让内核专注处理I/O。Linux内核是相当擅长子进程调度的，Kubernetes、Swarm和单个的Docker容器不太擅长干这活。进程（及线程）都是有关内核资源分配的，而容器涉及到了集群资源分配。
运行单容器单进程的“最佳实践”被广泛认为是“原则“，但听起来更多像哲学。作为一名工程师，我想要理解技术组件，并做出合乎逻辑的决定。我认为,这种”最佳实践“甚至不是普遍的共识，其控制应用程序根源于广泛缺乏了解的Unix是如何工作的。
Linux容器在历史上有许多种形式，许多实际推荐运行的是在单个容器里运行多个进程。什么使得Docker容器与众不同的呢？Linux容器本质上就是对于系统调用的克隆、SElinux和Cgroups，它们是否是LXC或者Docker（通过libcontainer）类型是无关紧要的，因为Linux内核自身就可以处理进程隔离。
在有效的时间之内通过Socket、文件或者网络等处理通信，每一个方法都有它各自的优点和缺点。给定应用程序的通信方式肯定会影响你是否想将您的应用程序切分成多个容器。
代码、配置和数据的分离也会影响您的应用程序切分为多个容器的能力。如果你的应用程序具有良好的代码、配置和数据的分离能力，将会非常容易切分为多个容器，如果你的应用代码非常古老，并且不太好理解，将会对于文件系统带来不必要的改变，并且非常难以作切分，注意，下面的方法是非常棒的！你不必重写你的应用来容器化，而可以通过将你的应用放入一个容器就可以享受Docker容器格式的好处。你可以轻松地移动（使用注册中心服务）和部署（执行docker
run命令）。 好的，有一些Unix应用遇到101错误了，让我们回到示例Java应用的分析：
如上所述的两个Java组件看起来做的都是不同的事情，一个组件是Web前端，另外一个是API服务器。既然这些组件做的是不同的事情（比如他们确实是不同的服务），几乎没有机会比在相同的JVM里有性能优势（当然了，没有实际的测试性能，我不能100%确定）。
这两个应用程序使用REST API来进行通信（而不是使用Socket、共享内存或文件等方式）。
一般来说，如果一个应用程序包含一个API层和一个前端层，对于独立地扩展这些应用就非常有用。比如说如果一个API也被一个移动应用所消费，根据用户负载进行动态伸缩就很有用，而基于Web的前端就不需要伸缩。相反，如果我扩展web前端，我可能还需要扩展API服务器的部分，但每五个Web前端我可能只需要再多一个API服务器。长话短说，伸缩逻辑复杂，借助于类似Kubernetes这样的工具进行独立的伸缩是非常有用的。
基于这三个单独的观察，我推荐将这两个组件切分为单独的容器，我还推荐使用容器编排工具比如Kubernets或者OpenShift来将这些服务连接在一起。我不会将这一决定基于所谓的“原则”或“最佳实践”，而是会基于它的应用架构和某种形式的信息推理。
这儿的事情变得疯狂，我提交（给你）一个新的“最佳实践”，请击鼓：
是的，如果您的应用程序/服务具有很好的代码、配置和数据的隔离，安装非常清晰（因为安装脚本会使整个过程变得困难），提供了一个非常清晰的通信模式，就非常有意义来切分/分配为单容器运行单个服务。
从根本上说，我建议我们所有人都应该开始更加理性地考虑如何把应用放入容器里，意识到容器化不仅仅是一个哲学理论，更是可以解决技术痛点问题的。我喜欢容器，并且在所有的时间都愿意使用它们，但是也是以一个睿智的方式。我确信人们对于容器化应用的意见和想法，我鼓励您在下面的评论栏中分享你的想法。
