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

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

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

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

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