2同行回答
一、容器化改造概述
为了利用云平台PaaS层优势，传统应用不适合容器PaaS平台的架构和部署方式，因此需要经过改造，才能有效利用PaaS平台。传统应用容器化改造有如下三种方式：
- 容器改造上云
- 应用改造上云
- 混合改造上云
二、改造模式
2.1 容器化改造模式
2.1.1 容器改造上云概述
容器改造上云是指将应用接入层（Web服务器），应用逻辑层（即应用中间件层，包括JAVA环境、中间件、应用程序包）打包在容器中，通过云平台进行自动化部署和发布。容器改造上云，基于容器带来的标准化、轻量化和隔离性，实现秒级快速部署，进一步提高资源利用率。
采用容器改造上云方式，应用需实现本地持久化数据转存（即业务逻辑和业务数据解耦，应用非结构化数据、缓存数据、结构化数据均不能位于本机或本地，应保存在共享存储或数据库），不符合此类型的应用应先改造。
2.1.2 容器改造上云目的
容器改造上云的目的，主要包括快速发布、弹性扩容、统一日志等。
1） 标准化应用的部署和交付：采用容器镜像的方式实现运行环境的标准化，屏蔽应用部署过程中的环境配置、安装步骤等复杂过程；
2） 资源弹性伸缩：对于面向互联网或者存在访问高峰、低谷差异的业务应用，通过容器实例的自动弹性扩容或收缩，满足应用在不同压力场景下的访问性能需求；
3 ） 统一日志：应用迁移到容器中，基于云平台的统一日志收集，实现应用日志的集中存储和展现；
4 ） 提升资源利用率：容器是基于操作系统的轻量级虚拟化技术，多个容器可以共享操作系统的内核进程和内核资源，有效节省操作系统级的资源开销，通过容器密度的提升更好的利用资源。
2.1.3 对平台要求
容器上云需要云平台在主机、存储、网络等基本资源服务基础上，提供自动化部署、弹性伸缩、统一日志等服务。 以应用当前运行环境的资源现状，做为提出容器上云的资源需求的依据，应包括容器镜像、容器规格、容器网络、容器存储、负载均衡方面内容，包含的关键资源如下：
1)容器基础镜像:云平台镜像仓库应提供分层的容器基础镜像，具体如下：
操作系统基础镜像（Centos7）；包括应用Web服务的容器镜像（Nginx、Apache等）、包括应用中件的容器镜像（包括JAVA JDK，Tomcat、WebLogic），同时容器镜像应提供应用要求的对应版本，确认软件部署路径；
云平台提供的容器基础镜像可通过DockerFile文件、CI持续集成工具进行创建，在镜像文件描述、容器镜像存储、容器镜像库构建等方面遵循发布的规范。
2)容器规格:云平台应提供可选择的容器实例规格，规格参数包括：CPU、内存、挂载本地卷、节点数等。
3）容器网络：容器实例间网络可直接通信，应用容器实例与宿主机可直接通信；云平台需控制容器实例间的网络带宽配置。
4）容器持久化存储：云平台需提供相应NAS存储、分布式存储，满足应用容器实例访问的缓存数据、读写的非结构化数据的存储需求。
5）负载均衡：云平台负载均衡组件应用满足应用容器实例的SLB（4层或7层）、GSLB需求。
6）应用编排配置文件：云平台应提供应用配置参数、环境变量的编排文件。
7）备份：云平台应满足应用War包、容器基础镜像归档与管理，同时应满足结构化数据、非结构化数据的全备和增量备份。
8）租户：云平台应给迁移应用单独分配租户。
2.1.4 对应用要求
采用容器改造上云，对应用层面的要求如下：
1、容器数据持久化存储
应用容器化后涉及到的结构化数据、非结构化数据、缓存数据，不能存储在内存、本地文件中，结构化数据位于关系型数据库中，非结构化数据可位于NFS存储、分布式存储中，缓存数据可位于Redis、Memcached集群。
2、代码与配置分离
应用需要将配置参数定义成环境变量，可保存在配置文件中，并可传递给应用代码；代码层面只负责处理业务逻辑，代码内部调用使用定义的变量，不能指定特定的IP地址；应用部署和运行涉及到的配置文件可保存在云平台中。
3、健康检查接口
应用应提供健康检查接口（比如健康检查页面或业务监控指标接口），云平台通过判断应用容器实例状态，对应用服务进行状态保持。
4、不依赖复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制。
5、应用容器实例启动时间
应用程序War包大小控制在500MB以内，单个容器实例对内存需求控制在32GB内，应用容器化后启动时间建议控制在15分钟内。
6、日志标准化
通过标准化日志，例如带上唯一的ID信息等，可以对成功率、响应时间等关键业务指标进行统一关联分析，作为问题预警、诊断分析的科学依据。
2.2 应用改造模式
2.2.1 应用改造上云概述
应用改造上云是指微服务架构应用，通过容器、微服务框架等方式支撑应用在云上部署和运行。
应用改造主要针对新建业务应用或新建模块，利用SG-UAP进行微服务、微应用开发，将存在众多复杂业务子模块、且子模块间紧密耦合的传统单体应用，以合理的业务层面维度，拆分为多个模块化微服务，单个微服务是处理某一特定业务逻辑的最小单元，单个微服务是高内聚的，微服务之间是松耦合的。
微服务应用的访问统一由分布式服务总线网关进行负载、汇总、治理，微服务的注册、发现通过分布式服务总线注册中心实现
2.2.2 对云平台要求
针对基于微服务开发的应用，提出云上的资源需求，应包含微服务治理和云平台核心能力方面内容，具体云化服务包括：微服务治理（包括服务注册、服务发现、服务管控、服务故障快速定位、服务路由、服务监控），云平台核心能力（弹性伸缩、故障自愈、自动化部署、统一配置、统一日志）。
应用微服务改造上云的资源需求如下：
1）微服务容器基础镜像：JDK版本：1.8版本；部署路径：微服务容器镜像应统一JDK、Web、中间件的部署路径；日志路径：要求可配置。
2）微服务容器规格：云平台应提供可选择的容器实例规格，规格参数包括：CPU、内存、挂载本地卷、节点数等。
3）容器持久化存储：云平台需提供相应NFS存储、分布式存储，满足应用容器实例访问的缓存数据、读写的非结构化数据的存储需求。
4）与外部系统集成：与外部系统采用PI、OSB接口或分布式服务总线集成；
5）服务治理：云平台需解决服务运行期注册发现，解决服务配置动态调整、解决服务调用过程的全链路监控跟踪。
6）微服务部署：云平台需提供网关服务，实现前端WEB页面和后端微服务的平滑对接，解决微服务日志、监控数据的自动收集和存储。
7）负载均衡：云平台负载均衡组件应用满足微服务架构应用的SLB（4层或7层）、GSLB需求。
8）应用编排配置文件：云平台应提供微服务架构应用配置参数、环境变量的编排文件。
9）备份：云平台应满足应用Jar包、容器基础镜像归档与管理，同时应满足结构化数据、非结构化数据的全备和增量备份。
10）租户：云平台应给迁移应用单独分配租户。
2.2.3 对应用要求
采用应用改造上云，对应用层面的要求如下：
1、微服务开发
微服务的开发基于华为云ServiceComb技术路线，有单独手册说明。
2、微服务集成
微服务架构下，一个业务系统由多个微服务构成，微服务启动后将服务自动注册到分布式服务总线，微服务通过分布式服务总线发现被调方的地址并本地缓存，微服务之间都是直接调用对方服务名、数据交换采用RESTful接口。
3、容器数据持久化存储
业务应用涉及到的结构化数据、非结构化数据、缓存数据，不能存储在内存、本地文件中，结构化数据位于关系型数据库中，非结构化数据可位于NFS存储、分布式存储中，缓存数据可位于Redis、Memcached集群。
4、代码与配置分离
应用需要将配置参数定义成环境变量，可保存在配置文件中，并可传递给应用代码；代码层面只负责处理业务逻辑，代码内部调用使用定义的变量，不能指定特定的IP地址；应用部署和运行涉及到的配置文件可保存在云平台中。
5、健康检查接口
应用应提供健康检查接口（比如健康检查页面或业务监控指标接口），云平台通过判断应用容器实例状态，对应用服务进行状态保持。
6、不依赖复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制。
7、启动时间
微服务应用程序Jar包大小控制在50MB以内，单个容器实例对内存需求控制在16GB内，应用容器化后启动时间建议控制在5分钟内。
8、日志标准化
通过标准化日志，例如带上唯一的ID信息等，可以对成功率、响应时间等关键业务指标进行统一关联分析，作为问题预警、诊断分析的科学依据。
2.3 混合改造
2.3.1 混合改造上混概述
1. 混合模式上云是指应用系统采用容器改造上云、应用改造上云模式中的两种混合模式上云。
2. 应用改造主要针对业务系统技术架构复杂，容器改造上云、应用改造上云两种上云模式中的一种无法满足技术架构要求和业务发展需求，如WEB服务采用容器改造上云，后台服务采用应用改造上云。
三、上云规范
传统应用容器化大致分为 如下 阶段：
1. 应用现状分析：梳理应用使用的资源、系统的逻辑架构拓 扑 、应用服务的所有数据依赖、应用上下游服务依赖关系、服务所依赖的进程、系统中需要保留的重要日志及数据、数据和文件权限等；
2. 方案规划和设计：根据前期对应用系统现状的调研和分析结容器平台特性，应用系统产出新的系统架构图和迁移的改造计划，比如是直接容器化上云还是改造后再容器化上云，以及容器化后业务系统功能和性能测试方案、系统的割接方案等。
3. 编写Dockerfile：若要打包应用程序以供在 Docker 中运行，需要编写脚本文件Dockerfile，用于自动执行所有应用程序部署时需要执行的步骤。这通常包括一些Shell配置命令，以及用于复制应用程序包、设置所有依赖项的指令，也可以解压缩已压缩的存档或安装包。Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。在 Docker镜像使用中，我们最好把经常变化的内容和基本不会变化的内容要分开，把不怎么变化的内容放在下层，创建一个基础镜像供上层使用。
4. 生成镜像：使用docker commit命令将某个container的环境提交成为持久化的docker image。使用docker build命令基于dockerfile构建。 这种构建方式的优势在于可以通过docker history命令溯源镜像的生成过程。并且消除了docker commit可能把一些不需要的东西误提交的隐患。镜像构建成功后，只要有docker环境就可以使用，通过利用docker push命令将镜像推送到镜像仓库中去。
5. 应用部署：将docker镜像部署到对应Kubernetes集群应用。在 Kubernetes 集群上需要用到的部署模板，在具体实施过程中，可以根据不同的模板来部署到对应不同的集群。
6. 上云测试： 容器改造上云对原系统进行了代码与配置分离改造，同时将原来保存在服务器节点上的数据都转存到数据库。容器改造上云测试应包括 ：
（1）测试代码与配置分离的系统在云平台上是否能正常运行，业务逻辑是否会产生错误 ；
（2）验证数据转存到数据库后是否会对系统性能产生影响；
（3）验证云中系统与外部系统集成是否正常。
7. 上云成效分析： 应用上云成效分析应从以下几个方面考虑
(1)云平台支撑维度：云平台上运行的计算、存储、网络资源配置及资源利用率；云平台上运行的应用容器实例、节点数及资源利用率；要求通过云平台进行统一汇总、监控和展现。
(2) 应用业务层面维度：通过云平台统一展现 ； 业务处理量、业务成功率、业务响应等监控指标，可确认云上环境是否满足应用业务层面基本运行要求。
(3)应用上云获得感维度：从最终用户、应用开发测试、应用部署上线、应用安全、应用运维等层面，依次评估分析 应用容器化 上云获得感。具体可参考如下指标：
(4)应用访问性能：是否借助于云平台的弹性水平扩展、高并发能力，实现业务层面的削峰填谷、智能负载均衡、一致的用户体验；
(5)应用开发测试：是否借助于云环境下的开发框架，实现开发运维一体化、持续集成、自动构建和快速迭代；
(6)应用部署上线：是否借助于云平台下的标准化部署、自动化部署等能力，实现应用系统的快速上线；
(7)应用安全：是否借助于云平台提供的多租户隔离等功能，实现各应用租户间的资源隔离、权限隔离、访问隔离；
(8)应用运维：是否借助于云平台提供的标准化应用运行环境、自动化运维等功能，应用无需负责基础设施和系统软件运维，只需关注业务流程层面的维护 。