头破血流阶段

在搞定了运维中心与质量中心后，生产与测试环境实施容器化的技术障碍基本排除，而又与集团公司保持了基本相同的技术栈，自我感觉总算可以大刀阔斧的可以开展容器化之路了。可没想到此时平时喊着对新技术一腔热血的业务研发们又成了容器化推广的障碍了。

容器化的质疑

1. 资源利用率高

2. 服务秒级启动

3. 交付迅速、完整

这三条 docker 早期的优点自然无法说服我们的业务研发们，因为生产压力本身就比较大，再加上人本能的路径依赖，对已经熟悉的虚拟机有很强的依赖感，如果没有更进一步的解决业务团队的痛点，业务团队是没有动力实践一门新的容器技术的。因此我们不得不在容器平台的基础能力上面增加以下特性，以获取业务团队的支持。

1. 滚动热部署

2. 弹性扩缩容

3. 熔断降级

但是即使我们在容器平台推出了以上三种对代码几乎没有入侵的解决方案，但是，业务团队还是说：我们通过 dubbo，spring cloud 也可以实现，为什么要容器化？一时之间容器化之路又进入了僵局。



容器化的救命稻草



眼看着以容器化这个 title 推广容器化在业务团队面前是比较难开展了，此时还是 2018 年初，微服务还在如火如荼的热炒之中，公司也在准备架构优化调整全面向微服务架构转型，我碰巧正是主要的参与人员之一，而正是这次微服务架构调整成了最后拯救容器化的救命稻草。