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

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

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

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

你的应用敢重启吗

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

你的应用依赖清晰么

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

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

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

你的应用可观测么

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

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

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

也算结论

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

Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

comments powered by Disqus
下一页
上一页