应用上容器对应用的改造影响有多大？业务不做改造是否也可以上容器？

（1）容器云平台上线后，对于开发人员的工作流程，产生了一些变革：
容器化前：
① 开发以源代码方式进行提交，然后进行打包，主干分支只保留最新的代码版本；
② 部署方式为手工部署，无法保证部署环境相同。
容器化后：
① 开发通过版本号提交，对版本变化可以追踪记录，并且镜像仓库中能保留多个测试通过的镜像版本；
② 支持自动化构建和自动化部署，并保证部署环境完全一致。

（2）容器云平台上线后，对于运维人员的工作流程，也产生了一些变革：
容器化前：
① 开发提交给运维的交付物为二进制包或二进制文件，部署方式为手工部署，无法保证部署环境相同；
② 回滚方式为手工回滚，流程比较复杂，效率比较低。
容器化后：
① 开发提交给运维的交付物为在测试环境测试通过的镜像版本号，部署方式为自动化部署，在不同环境下能保证部署方式标准一致；
② 可以自动化回滚到之前的任意交付版本。

（3）容器云平台上线后，对于应用访问方式以及网络管理也带来了一些变革：
应用容器化前，访问应用采用的是F5的IP+端口方式，F5为同一个地址，但不同应用的服务端口不同，访问不同应用需要知道其端口号；同时，运维中心网络管理人员需要维护大量应用的F5配置；
应用容器化后，访问应用通过域名的方式，不同应用只是三级域名不同；同时，运维中心网络管理人员，只需在容器云平台上线时，进行一次F5配置即可，将F5的IP+端口映射至容器云平台的两个Router节点，访问不同的应用，通过不同的域名，经过Router节点后即可进行应用区分，将流量分发至对应的应用容器中。

一般情况下，对于无状态应用；微服务应用；高并发场景应用；新开发的应用；敏捷开发的应用这类可以不做改造，而传统的业务一般都是要做一些改造的。

业务改造根据不同的实现目标，分不同的阶段。可以不做任何改造，或只做环境适应性改造，就可以上云、上容器，但这只是获得资源节省、快速启动等最少的收益；进一步，高可用改造、无状态改造、环境变量使用等可以让应用进一步获得容器平台带来的快速迁移、高可用、负载均衡等；更进一步，是架构的微服务重构，理论上这一步改造最大，自然获得的收益最多，完全获得了云原生业务的优势。

所以不应该问容器对应用的改造有多大，容器并不要求改业务，而是用户想在容器里运行什么样的业务、什么收益目标，决定了对应用的改造有多大。