容器化囧途——没上容器时好好的？

如果寿司店老板说，有一种人叫寿司人，寿司人的一切都是为了吃寿司，寿司人比别的人都厉害，你肯定会嗤之以鼻；云厂商提出了云原生概念，倒是拥趸甚多——这是因为云比寿司好吃多了，它提供的好处，足以让人铤而走险，削减脑袋挤上云计算的车，这也就是业务上云了。

从参与《Kubernetes 权威指南》第二版到现在已经好几年了，在几年的容器化、云原生的推动过程中，因为一直从事企业服务的勾当，这个小视野里的绝大多数应用，都是证明可以成功容器化的。有一句很著名的程序员语录：“在我机器上是好的”，在推动应用上云的过程中，我听到的最多的噪音就是：没上容器时候是好的。

”在我机器上是好的“的原因应该说是很清楚的——环境失控、或者应用没有适应能力。Kubernetes 和各种公有云都很成熟，就先不展开环境问题了，说说应用自身需要回答的几个很直白的问题。

你的应用敢重启吗

容器本身是易失的，而在微服务设计中也强调了一点——面向故障的设计，不敢重启的应用，一定意义上就意味着该应用并无应对故障的准备。容器的重启和漂移，对这种应用来说，会有灾难性后果。

你的应用依赖清晰么

从面向对象到微服务，都不断地在强调，高内聚、低耦合、面向契约等等等等，这些名词都在倡导一种有清晰边界，有明确接触方式的应用实现方法。没有明确依赖关系的应用，连正常的割接、移机、扩展都会有巨大风险，更不要说从主机环境迁移到容器云上了。

你了解应用的资源使用情况么

很多计算资源宽裕的企业，对应用运行过程中的资源使用毫不在意，这种情况在上容器时会造成巨大的困扰——毕竟一般不会提供一个 64G 内存的容器。CPU、内存、IO、网络等需求，在容器化的过程中，都需要有个清楚的摸查。

你的应用可观测么

完善的应用框架都会提供一系列的观测支持、包括调用跟踪、资源报表、日志输出、健康检查、服务监控等。不过也有不少应用并没有重视这方面的东西、或者错误使用。比如常见的把进程存活或者端口监听当做健康检查的标准、或者模糊不清的日志输出，这些观测性的缺憾，最终都会成为容器化的缺憾。

你的应用的可用性需求明确么

很多用户受到误导，以为上了云，会自动漂移的应用就能够 N 个 9 了，事实上容器平台或者公有云对应用高可用的支持也是有限度的，应用自身对高可用的需求、运行平台在高可用方面的支持应该有一个全面的了解，并据此相互配合达成可用性目标。

也算结论

容器不是拦路虎，它是照妖镜，从 Dockerfile 到 YAML，再到 DevOps 和不可变环境，都对应用提出了更高的要求。赶不上容器末班车的原因可能是——你太慢了。