如何快、准、狠地进行应用容器化改造？

本篇文章将带你了解所有关于企业级应用容器化改造的必备理论知识，以及如何清晰规划云原生转型路径，手把手教你如何做好容器化改造。

容器化目标与路径

众多周知，企业的数字化转型大都以业务价值为目标，由于每个企业的独特性，通常很难找到完全匹配的经验可供借鉴，因此必然带来转型过程的碎片化，从而对原有的传统应用架构带来巨大冲击，而大量新应用的产生同样会导致原有企业架构的碎片化，因此根据不同的应用特点重新梳理、区别对待，为了解决这一问题，以容器为核心的新一代双态IT架构应运而生。

双态IT架构主要包含稳态业务和稳态业务两大部分。敏态业务往往是直接和业务盈利相关的，会随着用户需求而不断变化，因而更注重满足业务的快速多样性，强调敏捷性和速度。稳态业务通常为支撑性业务，比如CRM、ERP、OA等等，更强调准确性、可靠性和稳定性。

与此同时，支持业务应用的持续演进也是容器化的一大目标之一。企业的底层基础设施也从原来的网络设备加服务器，过渡到虚拟化，再进阶到容器化，其所支撑的上层业务应用形态也会随之发生变化，逐渐从传统的单体应用向虚拟化时代的RPC/SOA应用、再向云原生时代的微服务应用转化。很多企业可能在虚拟机时代就进行了微服务化改造，但可能收益并不明显。虽然应用已经是独立的个体了，但依然有着极高的弹性伸缩等能力需求，这时候就需要借助容器来实现，二者的强强联合才能够真正将微服务的优势发挥出来。再配合DevOps平台，就能够更好地实现敏态业务的扩展和生产效能的提升。

此外，容器化的另一红利在于推进由系统化向平台演进。由于云原生技术的学习成本过高，比起浪费大量研发资源在自研云原生平台的调研、架构设计、技术选型、建设运维上，越来越多的企业开始拥抱开箱即用、灵活可控的一站式全栈云原生平台，企业无需再关心容器、微服务技术的细枝末节，一套平台提供生产就绪的微服务基础设施、治理、运行、运维最佳实践环境。

云原生应用形态

云原生应用形态主要包含以下几类：

· 中间件应用
MySQL、Redis、RabbitMQ、MongoDB、Kafka。这类应用是云原生平台内的一种应用形态，可能在容器平台内，也可能在原来的虚拟机、其他公有云等传统基础设施资源上，我们称之为数据服务，用于为应用提供持久化支撑。

· 工作负载
工作负载指的是在K8s下的workload，包括Deployment、StatefulSet、DaemonSet、CronJob等。

· 抽象模型
通常来说，在部署应用时需要进行抽象封装或定义。具体来讲，一个应用通常是指一个应用系统，应用系统又有各自的前端、后端、中间件、配置文件、网络等等。当然在不同的客户环境下，也可能有不同的定义，比如微服务团队下定义的应用就是微服务应用，涵盖workload、治理能力等等。因为有上述抽象模型的定义，就衍生出了OAM应用、微服务应用、原生应用。

· 管理分区及组织架构
由一个平台支撑多个应用，一个应用支持多个集群，集群又划分成不同的管分区，比如生产集群、测试集群、灾备集群等等。组织架构层的业务系统可以跨多个集群，设置分配不同项目的资源配额，在不同项目下独立开发运维。

应用上云关键路径

企业上云路径应该根据不同的应用资产形态、上云后的预期目标进行综合分析评估，确定合适的转型模式，再去采用对应的解决方案和环境。应用上云的转型模式主要分为以下6种：

Encapsulate：直接暴露API供创新应用调用，也是所有应用都适用的一种模式，相当于应用不迁移，只开放旧应用的API给新应用使用。

Rehost：不做任何修改迁移到云。这里分为两种情况，第一种是原有应用不需要修改，比如原有应用为容器化应用，就可以直接迁移到云上；第二种是没有时间修改，很多企业项目改造时间周期紧张，来不及做架构改造、微服务拆分，那么就可以直接把容器当成虚拟机来用，更方便利用容器平台来做DevOps，加速企业敏捷化运营，也便于后续进行单体应用改造。只不过成果收益不太显著，很难充分享受到云的便利。

Replatform：利用部分云优势进行容器化等少量改造，比如企业可以通过进行容器的外部化或者去状态化，体会到容器带来的优势，不需要过多地考虑基础设施的细枝末节，就能实现高并发业务场景下的自动扩缩容，提升系统的弹性和容错能力。

Refactor：利用云原生优势部分重构。这部分主要涉及到微服务改造，考虑如何去拆分业务应用。

Rearchitect：用云原生架构重构应用。除了考虑应用自身的容器化、微服务化改造，也要综合考虑中间件的云原生化，更多从整体架构上进行再规划建设。

Rebuild：构建全新的云原生应用。全面的云原生化可以帮助企业更快地享受到云原生降本增效的技术红利。

总体来看，很多业务应用甚至无需改变代码，就可以实现平滑地云原生转型。企业应结合自身业务愿景、投入产出、敏捷交付、服务水平、改造周期等目标进行全盘考量、合理规划，建议先上云后逐步改造，更早地发挥云原生优势，为企业创造更大价值。

企业上云原生关键步骤

第一步，优先建设企业级容器云平台。提供平台来托管从传统应用程序到微服务应用程序的所有应用程序。应用现代化允许现有中间件的容器化。

第二步，创新云原生应用开发，建议新业务直接采用新技术栈开发，在一开始就运用微服务、DevOps、API等敏捷技术框架，在企业级云平台上构建云原生应用，没有历史包袱。

第三步，现有应用上云。在分析评估后分类、逐步进行原有系统应用迁移。

第四步，实现多云化的应用管理。在新旧应用都云化之后，企业就会面临多云管理的问题，这时企业应重点关注运维层面，将技术与业务分离。应用要在多个云环境中运行，实现对于多云应用的全生命周期管理。

什么应用适合上云？

整体来看，所有的应用都可以上云，只不过企业需要综合考虑现有应用上云的改造成本和收益情况进行合理规划。应用上云原则主要可以归为3类：

第一类，优先上云
· 已经容器化的应用
· 微服务架构的应用
· 无状态的应用

第二类，推荐上云
· 需要故障自愈、弹性伸缩、快速迭代能力的应用
· AI应用，如Tensoflow、GPU密集型应用等

第三类，需要进一步考量
· 不维护的，无技术支持的黑盒应用
· 重资源应用
· 有特殊外挂的应用，如U盾
· 对操作系统有特殊要求的应用

优先上云的应用有无可参考的判断标准？

根据灵雀云多年的容器化改造落地实践经验，我们总结出了以下几条优先上云应用所需具备的条件：

· 已建立清晰的可自动化的编译及构建流程
使用了如Maven、Gradle、Make或Shell等工具实现了构建编译步骤的自动化，方便在容器平台上实现自动化的编译及构建，如已经使用了Jenkins等持续集成工具更好。

· 已实现应用配置参数外部化
应用已将配置参数外部化到配置文件或环境变量中，以便于应用容器能适配不同的运行环境。

· 已提供合理可靠的健康检查接口
容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。

· 已实现状态外部化，实现应用实例无状态化
应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。

· 不涉及底层的操作系统依赖及复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。

· 部署交付件不宜过大，建议在2G以内
轻量级的应用便于在大规模集群中快速传输分发，更符合容器轻量敏捷的理念。

· 启动时间不宜过长，建议在5分钟以内
过长的启动时间将不能发挥容器敏捷的特性，这部分应用往往因为过重而需要改造。