以下内容根据演讲视频以及PPT整理而成。
直播回顾，请点击这里。
回顾阿里云迁云实战解析（一）：全面上云拐点已到，云架构师get 何种技能？，请点击这里。
回顾阿里云迁云实战解析（二）：零售上云全解析（上），请点击这里。
优化方案：通过对该客户线下应用相关虚拟机配置与近期平均负载峰值进行统计，计算出集群总体的CPU和内存。另外在峰值的基础上预先配置了20%的容忍度，这在应用业务压力比较大的情况下可以自动帮助用户进行应用的扩容，同时也可以在某台主机发生故障的时候可以保证业务的稳定。这种方式不仅可以解决资源配置的问题，同时可以降低成本。
因为云资源是可弹性伸缩的，即使前期资源配置在正常情况下是满足，但是针对一些峰值情况如促销活动，通过合理规划、临时资源扩容可以快速满足用户的需求。而对于不使用容器化的用户，阿里云提供了专用宿主机的服务，通过CPU超分，轻松提升部署密度，类似于vSphere的超额预定，来帮助用户在资源规划的时候最大化降低成本。
云上数据库设计：云上数据库如果全部按照1:1的模式来设计，成本会很高。因此该案例用户最终在云端只对主数据库创建了高可用的RDS实例，实现云数据库主备；另外实现了分库分表，一旦涉及到读写要求比较高或者并发要求较高的场景，可以通过只读实例，满足数据库读写分离需求，来提高应用的并发性能；对于HR系统、会员系统和报表系统，由于线下集群只有单台MySQL，上云之后采用的是单机基础版，虽然使用的是单机基础版，但是仍然可以使用DBS的数据库备份机制对数据进行秒级备份。下图是云上数据库的设计方案，具体是能否能够真正满足业务需求还需要看后面迁移完成后的压测结果，数据库包括架构设计也将会基于压测结果来做进一步的调整。
数据库设计问题：上云过程中，即使前期进行了数据库设计，实施过程中还是可能会遇到一系列问题，如部分报表、数据库云上的执行速度比线下慢；同一执行的执行结果不一致；部分数据库的同步时间较长等等。
导致这些问题的原因主要有：
1） 出于成本考虑，使用单机基础版RDS，使得MySQL数据库版本需要从5.6升级到5.7，升级后导致最终的执行计划不一致，进一步导致数据库在一些特定的场景尤其是OLAP场景下执行变慢，需要通过参数调整和索引优化来解决；
2） 对于执行结果不一致问题，是因为单机基础版本RDS对于MySQL用的是SSD云盘，而SSD云盘本身的数据块是被打散的，数据读写到云盘上存在网络开销，由于网络抖动问题，读写到盘上的数据可能会存在不一致的情况；
3）针对第三个问题，一方面数据库同步主要是基于数据库分表机制，如果分库键的选择不合理，将会导致明显的数据倾斜，即一大部分数据集中在其中一个物理数据库实例上，这种情况下相对于其他数据库，该数据库的同步会比较慢。另一方面，目前在云上可以通过DTS对MySQL进行迁移，不同规格的DTS会对任务进行相应的限流，如果是因为这个原因所导致的数据迁移比较慢，则需要调整DTS的规格，比如从Medium调整到Large。
应用改造
应用改造的关键在于对于云服务的适配性改造，这是建立在深度了解使用场景的基础上的，同时需要进行相应的代码改造。具体来讲，主要分为以下四方面：
• 分布式微服务框架：客户由于外包的原因同时使用了Spring Cloud和Dubbo，为了使基于Spring Cloud和Dubbo的服务可以同时被服务注册和服务发现，阿里云的EDAS是一个很好的选择，它可以兼容Spring Cloud和Dubbo；线上使用的EDAS公有云版后期出现了一些小问题，比如EDAS和阿里云容器服务之间的打通存在一定的限制，举个例子，作为容器化最核心的一个特点HPA，其前期设置一直无效，因为无法获得Pod的负载情况。最终发现导致该问题的原因是EDAS的某些部署方式，如灰度发布和批量发布，与HPA的设置是不兼容的，这种情况下需要重新部署Pod来解决该问题；另外如果使用阿里云的公有云服务，尤其需要注意Jar包冲突的问题。大家都知道，在导入共有云的时候，有些Jar包是相同的，以用于日志输出的Log4j的Jar包为例，公有云导入的是最新Log4j的Jar包，而原来的应用可能使用的是Log4j旧的Jar包，当通过Maven进行构建，导入公有云的时候可能旧的Jar包先被加载，这种情况下就会导致因为Jar包冲突而找不到某个方法的问题。因此在引入新的Maven Jar包依赖时，须进行必要的梳理，从而将一些可能会存在冲突的问题提前解决。
• 消息中间件：消息队列的修改相对来讲比较容易，由于线下原本使用的是私有输出的消息队列RocketMQ，到云上之后要做的主要是云服务适配性的改造，因为公有云有别于私有云，其上任何一个服务的使用都需要进行鉴权，即绑定云账号下的AK/SK；另外和线下不同，线上消息队列Topic数量可能会对成本产生很大的影响，因此除了生产阶段，开发和测试阶段可以通过通用Topic的使用来降低总体Topic的数量；还有一个问题是线下已经建好的Topic如何批量迁移到云上，为了保证正确性，具体实践中可以将建好的Topic导入Excel文件中，自研工具通过OpenAPI的调用将线下已有的Topic批量迁移的云上。
• OSS替换FastDFS：FastDFS本身并不存储原始的文件名，它上传的文件名是根据自定义的规则随机生成的。一般情况下，客户会将随机生成的文件名和文件名的随机路径相应地存储到一张表中，以记录该文件名对应的是FastDFS中的文件路径。这种情况下OSS替换FastDFS的具体实践是：首先将原有的文件批量迁移到同一bucket下；然后将bucket读写权限设置为Public，并设置Referer防盗链；另外新增的文件保存到单独设置的bucket下，并按月区分。目前OSS有OssImport工具来帮助用户实现文件的批量迁移。
• 容器化改造：容器化改造本身并不困难，因为它只是一个Dockerfile添加的过程，但是客户线下的应用存在一系列的问题，会阻碍容器化改造。首先是线下应用间依赖严重的问题，同一个Maven项目有很多依赖关系复杂的子项目，如果通过GitLab提交的方式、用GitLab CI触发编译的话，往往会失败，解决方法是用Jenkins替代GitLab CI；还有一个问题是Maven私有仓库很多jar包太旧，或者已经不存在，针对这个问题驻云科技对客户的jar包和私有仓库进行了梳理；另外该阶段也遇到了前面提到的Jar包冲突的问题，问题和解决方案在此就不再赘述。
代码改造：上云的过程中涉及到代码改造，为此，驻云科技向客户提供了迁云改造代码分支管理的方式（如下图所示）。首先建立一个迁云改造代码分支，原来的代码分支正常使用，以保证客户应用的稳定，当迁云改造分支完成后，会合并到Develop分支，再从Develop分支拉出Release分支，通过Release分支的测试后发布云上应用版本。这种方式可以帮助客户提升迁云效率。
全链路性能压测：全链路端到端的性能压测是整个迁云过程中非常重要的一环，它用于检验迁云改造后的应用是否真正满足业务的需要。因此，在迁云完成后，驻云科技对该客户的零售系统和报表系统进行了全链路性能压测，来查看相应业务场景主要业务流的运行情况（如并发量、响应时间和资源使用率），并将测试结果反馈给客户，由客户来判断当前的运行情况是否能满足其业务需求。针对该零售客户的系统压测，驻云科技选择了其中五个对并发要求比较高的场景，整个过程花费了大约两周时间，部分压测结果如下图所示。压测工具使用的是阿里云的PTS服务，同时结合了其云监控服务和驻云科技自有的监控平台。