应用容器化改造方案概述

方式一：

单体应用整体容器化

• 业务0修改：应用架构和代码不需要做任何改动。
• 提升部署和升级效率：应用可构建为容器镜像，确保应用环境一致性，提升部署效率。
• 降低资源成本：容器对系统资源利用率高。相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。

• 整体性架构扩展难度大，随着应用程序代码扩展，更新和维护工作非常复杂。
• 推出新功能、语言、框架和技术都比较困难。

方式二：

先将部分组件容器化（将对弹性扩展要求高，或更新频繁的组件拆分出来，先容器化改造）

• 渐进式变革：在原有架构推倒重建太伤筋动骨，通过较为缓和的改动，更容易接受。
• 弹性更灵活：将对弹性要求高的组件容器化，当需要扩展时，只针对该容器扩展，弹性更灵活，且能降低系统资源。
• 新特性上线更快：将更新频繁的组件容器化，只针对这个容器进行升级，上线更快。

需要对业务做部分解耦拆分。

方式三：

整体微服务架构改造，再容器化

• 单独扩展：拆分为微服务后，可单独增加或缩减每个微服务的实例数量。
• 提升开发速度：各微服务之间解耦，某个微服务的代码开发不影响其他微服务。
• 通过隔离确保安全：整体应用中，若存在安全漏洞，会获得所有功能的权限。微服务架构中，若攻击了某个服务，只可获得该服务的访问权限，无法入侵其他服务。
• 隔离崩溃：如果其中一个微服务崩溃，其它微服务还可以持续正常运行。

业务需要微服务化改造，改动较大。