以下内容根据演讲视频以及PPT整理而成。
接下来具体介绍两个驻云科技基于阿里云进行上云的客户案例。
1. 某零售客户上云
上云动因
目前该零售客户已将其线下的大部分核心业务搬迁上云，其最初的上云动因主要有四点：
• 线下扩容困难。该客户原有的存储经过几年的发展已经到了需要更新换代的阶段，驻云科技按照其目前的业务情况进行了估算，结果发现所需的置换成本较高，因此希望通过云服务来降低整体拥有成本。
• 提高平台稳定性和安全性。由于该客户线下的整个业务中台使用的是微服务技术，最初构建在阿里云中间件私有输出平台上，这种方式下其线下的平台稳定性和安全性需要用户自己来维护，核心业务平台的维护和升级需要大量的投入，甚至由于人员稳定性等原因可能会影响业务平台运行的连续性，而通过线下平台搬迁上云可以在帮助用户提升平台的稳定性和安全性的同时，降低业务平台的维护和升级成本。
• 容器化改造。希望上云后进行容器化改造，让资源得以利用充分的同时能够更加灵活的应对业务高峰低谷。
• 实现CI/CD自动化流程。希望上云后实现CI/CD自动化，提升交付速度，适应业务快速变化。
上云难点
该零售客户在上云过程中遇到了四个难点：
• 复杂性高。该零售客户原有系统的复杂性较高，应用系统数量繁多，依赖与调用关系复杂，尤其是数据库之间存在大量的同步机制，这种情况给业务梳理造成了很大的困难，成为上云的一大难点。
• 数据库结构复杂。该客户原本使用的是分布式数据库加MySQL数据库，实现了分库分表，而且存在大量云上-线下、云上-云上数据同步链路。
• 涉及多个中间件产品。包括Spring Cloud、Dubbo、RocketMQ等，这种情况下客户希望用公有云服务替代，但是由于线下某些开源组件的版本比较旧，代码改动点较多，无缝迁移困难。
• 对性能和稳定性要求极高。由于该客户的核心业务系统沉淀的POS、门店数据较多，同时涉及和WMS（仓库管理系统）的对接，因此对于系统的性能和稳定性要求极高。
应用系统及技术点
下图展示了该零售客户整个应用系统及技术点的具体情况。需要上云的应用系统主要包括门店POS系统、WMS（仓库管理系统）、O2O、内购券、全渠道业务中台、报表系统、HR系统和会员系统。
涉及的技术点主要有：
1）微服务。由于该客户的业务系统需要针对不同供应商进行开发，因此微服务系统包括Spring Cloud和Dubbo的使用比较多。2）Java。客户的整个业务系统中Java的版本使用不一，这也给后面的上云带来很多问题。
3） 对象存储。该客户针对一般文件存储采用的是NAS，对象存储使用的是FastDFS。由于在阿里云上搭建FastDFS不太合适，因此上云过程中涉及了FastDFS到OSS的改造。
4）容器化。使用容器化一方面是为了实现整个业务环境的标准化，从而更好地帮助其进行部署和实施；另一方面还可以帮助用户节省资源。
5）数据同步。业务的数据同步主要依赖底层的MySQL实现。
6）消息中间件。客户原本使用的是私有输出MQ，上云后使用的是阿里云的RocketMQ，版本升级很多，同时在使用方式上也发生了很大的变化。
7）分布式事务。使用的是阿里云自有的全局事务服务GTS。
8）高并发。为了满足客户的高并发需求，在涉及到云计算特性的使用选型上，驻云科技进行了一系列压测。
9）分布式事务和分布式数据库。
云上整体架构
该零售客户业务系统上云后的整体架构如下图所示。其中，数据库层与上云前差异不大，使用的都是分布式DRDS加MySQL。最关键的是，在应用层最终选型的是阿里云自带的容器服务ACK，使用的是K8S集群，其在阿里云上有三个版本，第一个版本是专有版，Master节点和Worker节点均可见，该版本适用于对K8s集群比较了解的用户，可以方便其对集群进行更细粒度的管理和控制；
第二个版本是托管版，Master节点不可见，Worker节点可见，该版本的优点是简单且成本低（Master节点免费），Master节点无需运维管理，用户只需要关注Worker节点上的业务；
第三个版本是全托管无服务器版，该版本主要适用于测试环境。驻云科技为该零售客户选型的是K8s集群专有版，以实现用户对K8s集群最大化管控。
资源规划问题：在上云的过程中可能会出现资源规划的问题，即最终的云上成本大于线下每年的平摊成本。导致该问题的原因主要有以下几方面：
• 线下用的是vSphere虚拟机，实际使用过程中会超额预定，即虚拟机配置高于整个物理机的实际使用配置；
• 数据库物理机配置非常高，有些数据库无备份，三个数据库主机互备，而云上使用RDS替代，无形中增加了成本；
• 线下很多库是单机库，一些单机库到云上采用的都是RDS高可用版本，相对来说成本会增加很多，而按照1:1的配比估算后发现成本非常高；
• 忽略了线下的维护成本、人员成本、机房和电力成本等等；
• 驻云科技对该客户需要上云的应用进行的整体性能评估结果显示，其虚拟机负载不足20%，大部分在5%-10%，而数据库负载不足50%。这意味着很多资源是可以释放的，而在云上资源的使用本身是弹性按需的，如果完全按照ECS的企业级实例来看，可以保证一定的稳定性，但是单价会非常高。这种1:1的模式完全无法体现出云计算的弹性优势，因此该案例后期又进行了整体优化。
