容器化囧途——没上容器时好好的？
source link: http://mp.weixin.qq.com/s?__biz=MzIxMDY5ODM1OA%3D%3D&%3Bmid=2247485138&%3Bidx=1&%3Bsn=ca36ccfd3512d78ca1ff7b6c87ed6a4b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
如果寿司店老板说，有一种人叫寿司人，寿司人的一切都是为了吃寿司，寿司人比别的人都厉害，你肯定会嗤之以鼻；云厂商提出了云原生概念，倒是拥趸甚多——这是因为云比寿司好吃多了，它提供的好处，足以让人铤而走险，削减脑袋挤上云计算的车，这也就是业务上云了。
从参与《Kubernetes 权威指南》第二版到现在已经好几年了，在几年的容器化、云原生的推动过程中，因为一直从事企业服务的勾当，这个小视野里的绝大多数应用，都是证明可以成功容器化的。有一句很著名的程序员语录：“在我机器上是好的”，在推动应用上云的过程中，我听到的最多的噪音就是：没上容器时候是好的。
”在我机器上是好的“的原因应该说是很清楚的——环境失控、或者应用没有适应能力。Kubernetes 和各种公有云都很成熟，就先不展开环境问题了，说说应用自身需要回答的几个很直白的问题。
你的应用敢重启吗
容器本身是易失的，而在微服务设计中也强调了一点——面向故障的设计，不敢重启的应用，一定意义上就意味着该应用并无应对故障的准备。容器的重启和漂移，对这种应用来说，会有灾难性后果。
你的应用依赖清晰么
从面向对象到微服务，都不断地在强调，高内聚、低耦合、面向契约等等等等，这些名词都在倡导一种有清晰边界，有明确接触方式的应用实现方法。没有明确依赖关系的应用，连正常的割接、移机、扩展都会有巨大风险，更不要说从主机环境迁移到容器云上了。
你了解应用的资源使用情况么
很多计算资源宽裕的企业，对应用运行过程中的资源使用毫不在意，这种情况在上容器时会造成巨大的困扰——毕竟一般不会提供一个 64G 内存的容器。CPU、内存、IO、网络等需求，在容器化的过程中，都需要有个清楚的摸查。
你的应用可观测么
完善的应用框架都会提供一系列的观测支持、包括调用跟踪、资源报表、日志输出、健康检查、服务监控等。不过也有不少应用并没有重视这方面的东西、或者错误使用。比如常见的把进程存活或者端口监听当做健康检查的标准、或者模糊不清的日志输出，这些观测性的缺憾，最终都会成为容器化的缺憾。
你的应用的可用性需求明确么
很多用户受到误导，以为上了云，会自动漂移的应用就能够 N 个 9 了，事实上容器平台或者公有云对应用高可用的支持也是有限度的，应用自身对高可用的需求、运行平台在高可用方面的支持应该有一个全面的了解，并据此相互配合达成可用性目标。
也算结论
容器不是拦路虎，它是照妖镜。从 Dockerfile 到 YAML，再到 DevOps 和不可变环境，都对应用提出了更高的要求——容器并非从天而降，也不具备化腐朽为神奇的能力，应用强，则容器强。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK