本文根据靳洪兵老师在〖deeplus直播第期〗线上分享演讲内容整理而成。（文末有获取本期PPT回放的方式，不要错过）
靳洪兵
美图技术专家
美图用户产品研发部技术专家，主要负责美图秀秀社区服务研发，主导参与美图秀秀调度系统、内容中台等多个项目的研发与设计。在分布式系统、消息中间件等方面具有丰富经验；
曾就职于新浪微博，负责平台研发部消息中间件、配置服务等系统的研发与设计。
一、美图秀秀介绍
我们来看一组数据，截止今年上半年，美图应用月活跃用户数超过3亿，独立设备数超过20亿，每个月美图秀秀要处理的图片以及视频数超过30亿。
在这些数据背后还有一些看不见的数据，在全国各地我们有6大自建机房，数以百计的服务器，十几款软硬件产品，PB级的业务数据。在支撑这些数据的过程中，我们逐渐的发现了一些问题。
首先是运维管理复杂，因为有这么多的服务器，随着一些服务器过保老化，故障率逐步上升。为了业务的稳定性，需要投入大量的研发人力去监控这些机器的监控状况。每隔一段时间，我们就会看到公司大群里，内购一些硬盘。
美图秀秀的业务流量有极强的周期性，周末比平时峰值流量高，元旦春节峰值会是平时的很多倍。为了支撑每年元旦春节流量，业务部门首先会预估流量，然后采购部门都会提前按照预估峰值流量采购服务器，然而春节过后流量下来，一部分服务器资源会闲置，变成一种浪费。需要付出的成本较高。
美图内部多个部门服务及组件重复建设的情况也比较普遍。但是由于有的服务组件与业务绑定的过于紧密，使得美图内部孵化的一些创新产品无法快速使用，导致创新产品的发布周期较长。
我们看到了这么些问题。应该怎么解决？那换个角度思考，从这些问题，看看我们需要的是什么？
其实我们需要的是运维简单的弹性计算和存储资源，开箱即用的服务和组件共同支撑起应用的快速开发。
通过什么样的方式能够实现我们想要的这些能力？经过公司仔细调研，我们给出的答案是云服务。公司在19年下半年提出了上云的计划。
二、上云的挑战与应对
那对于这么庞大体量的产品要上云，应该怎么做呢？又会遇到些什么问题呢？接下来就给大家带来的是上云的什么挑战，以及我们应该怎么去应对呢？
可能有人会说上云有什么难的？把服务部署上去不就好了。一开始我们接到上云任务的时候也是这么想的。然后在讨论这个事情的时候，组内的资深技术专家给大家提了这样的一个问题？
把大象装进冰箱里，总共分几步？当然我们都知道答案。3步，第一步把冰箱门打开，第二步把大象装进去，第三步把冰箱门关上。上云就相当于把大象装进冰箱。简单来说上云也分3步：
第一步在云上创建对应的服务和资源
第二步把数据同步上去
第三步把流量切换到云上。
每一步听起来都很简单，对不对？但是具体每一步该怎么做，细节就是魔*？我们有3亿的月活，海外用户的占比也不小，我们需要为用户提供的是7X24小时的不间断服务，在上云的过程中也不能中断。另外是我们有PB级数据，用户数据是我们最核心的资产，不管在哪个环境下，我们都需要保证用户数据的完整性和一致性。
简单来说就是用户需要完全无感知，这就要求我们整个上云的过程需要做到平滑和稳定。接下来主要围绕着如何做到平滑和稳定来跟大家分享上云的一些方案设计。
去掉一些细枝末节，我们可以将业务系统的架构简化为3层，最上层的负载均衡，中间的web服务，下面是资源层，对应着3个层面的迁移，流量的切换，应用的迁移和资源的迁移。另外还有依赖的外部服务。如果外部依赖不迁移，跨IDC的访问，专线有1ms的延迟，公网有几毫秒的时延。
我们将依赖服务按照跨IDC的时间敏感度分为强依赖服务和弱依赖服务。对于强依赖服务，需要在我们业务上云之前部署在云上，弱依赖服务可以按照服务提供方自身的上云顺序进行，但是我们仍然需要
