1.1.3 应用云原生改造
业界云原生相关的基础设施已基本成熟。对用户来说，对已有的传统架构服务进行改造，加速迁移到云平台至关重要。
应用的云原生改造基本分为 3 个阶段：
（1） 容器化改造；（2） 微服务化改造；（3） DevOps 改造。下面分别说明。
1. 容器化改造
为什么要对传统应用进行容器化改造？传统云化应用大多运行在虚拟机上，如图 1-5所示，由于增加了虚拟操作系统这一抽象层，虚拟机方案过于复杂冗余，存在资源调度困难、利用率低下、难以快速交付部署等问题。因此，使用共享内核的轻量级容器技术成为云原生时代更好的选择。
图 1-5 虚拟机 vs 容器
容器化改造是将传统应用程序和其所需的运行环境打包在一起形成完整的镜像，使得应用可以运行在 Docker、KataContainer 或其他类似容器中。容器化改造的具体流程如下。
（1） 抽离环境不同导致配置项发生变化，用环境变量或参数等形式传入应用。
（2） 编写 Dockerfile 文件 ，在 Dockerfile 中安装程序运行依赖的第三方软件包。
（3） 根据 Dockerfile 文件构建容器镜像，并推送到容器镜像仓库。
容器化改造后，应用程序将具有如下优势。
（1）标准化：只需配置好 Docker 或其他类似容器的运行时环境，即可消除开发、测试、生产环境的不一致性，从而实现一次构建，随时可运行。
（2）快速交付，通过构建容器镜像，可以实现高度定制化的自动交付部署机制，以及错误回滚机制，极大地降低运维流程的复杂度。
（3）高效：由于容器间相互隔离，确保了应用有序竞争资源，从而降低系统整体资源负载。
2. 微服务化改造
容器化改造本质上是优化了应用运行的环境，并没有改变传统应用内部模块的耦合，存在扩展困难、可靠性低等问题，因此，微服务化改造应运而生。
微服务化改造就是将原有的单体应用按照业务范围划分成多个微服务，服务之间相互独立，通过远程过程调用协议（RPC，Remote Procedure Call Protocol）、RESTful API 等轻量级通信机制通信，整体形成分布式的架构。
容器化改造结合微服务化改造，应用将具备更多优势。
（1）松耦合：由于容器的隔离性，不同服务内部独立，可以采用不同的开发语言，独立测试、部署，不需要考虑技术栈的相互影响；个别服务业务变动，重新部署上线也不会影响其他服务。
（2）扩展性：随着服务复杂度的提升，需要分配更多的资源，结合容器技术可针对所需服务进行资源的精准按需分配，提高资源利用率；同时当业务需要添加新的第三方依赖时，得益于容器化的轻量性，可以快速启动依赖服务。
（3）高可靠：重点服务可大量横向扩展，以确保服务的高可用性；此外得益于低耦合容器的快速部署，可动态根据流量规模对部分服务进行动态扩缩容。
结合云原生平台提供无侵入式的自动化服务发现、监控、容错、追踪等微服务网格（Service Mesh）的能力，可以进一步发挥微服务改造后应用的优势。
3. DevOps 改造
基于容器化和微服务化改造的基础， DevOps 改造可以解决应用开发过程中存在的需求变化快、交付慢、运维成本高等问题。从严格意义上讲，DevOps 不只是一个技术范畴，而是组织、流程与技术的结合。
（1）组织上：团队敏捷开发，特性专一，每个业务可以被独立地开发、发布和运维。
（2）流程上：强调端到端、可视化、灰度升级、链路追踪、故障自动回滚等。
（3）技术上：打破开发、测试和运维之间的壁垒，引入 CI/CD（持续集成 / 持续支付） 工具。
DevOps 改造流程具体如下。
首先需要完成容器化改造和微服务化改造，此时应用可以容器化部署运行，且已拆分业务逻辑，实现松耦合。
然后进一步微服务化改造，或者叫网格化改造，如图 1-6 所示，随着业务的发展，一个应用容器中除了业务代码，可能还包括日志、监控、限流熔断、链路追踪等运维功能的代码，此时即使只是调整日志模块的代码也需要将整个应用重新打包发布并升级部署，为了让应用更专注业务本身，需要将日志监控这类服务治理类的代码抽离出应用容器，放到 Mesh Sidecar（边车模式） 形式的容器中，这样应用只需关注业务变化。
图 1-6 网格化改造对比图
最后引入 CI/CD 工具，如图 1-7 所示，实现从代码推送到应用部署的全流程自动化。
图 1-7 CI/CD 流程
完成 DevOps 改造，业务代码推送后借助 CI/CD 工具自动打包镜像，持续部署，并利用 Service Mesh 的能力实现自动灰度发布和错误回滚，同时利用日志、链路追踪实时监控业务，从而实现业务的全链路持续集成交付以及自动化运维。
