萨摩耶混合云迁移之挑战
作者介绍
李质 萨摩耶金服DBA
第40篇架构好文：5878字 | 12分钟阅读
前言
大家好，我是李质来自萨摩耶金服运维团队
我今天分享的主题是《萨摩耶混合云迁移之挑战》，主要是围绕我们萨摩耶金服在混合云建设实施和迁移过程遇到的问题挑战，然后以及相应的一些应对措施，希望通过此次分享，能够为大家以后在云平台和数据中心的迁移实施中起到一些帮助和一些经验。
今天的分享主要内容为以下四部分：
第一部分是混合云迁移背景情况
第二部分是迁移要达成的目标和整体的思路
第三部分是迁移面临的挑战和问题
第四部分是我们迁移完成后的经验总结
首先说一下我们建设混合云的原因，主要是基于下面三个考虑：
第一成本因素。随着公司的发展硬件资源投入的成本增加，经过我们内部的评估计算，如果采用自减机法的形式和公有云同步使用的方式，能够在一定程度上降低我们在服务器资源上的投入成本，同时又能够兼顾使用公有云在计算性能和安全方面的一些优势。
第二公有云限制因素。在长期的公有云使用过程中，发现他存在很多的限制，主要体现在网络磁盘和灵活性上。
第三长期发展规划的需要。作为一家互联网金融的创新型公司，相关的监管机构对我们数据中心建设有比较高的一个规格的要求，包括安全规范上的一些限制，但是很多时候就是在个体上是无法达成的。
这是我们主要迁移原因的介绍，接下来看一下我们当前线上业务的现状。
我们现在线上业务是比较复杂的，主要体现在三点：
第一点是线上业务繁忙，我们经过三年的发展，已经积累了2000多万用户，业务类别扩展到十多种，我们现在系统，每天的业务工作可能达到3000左右，是相比于这种互联网金融行业来说是比较大的一个体量的。
第二点资源使用量大，我们现在已经使用了大量的资源，包括一些服务器、网络，同时按照现在这个规模来说的话，我们的迁移难度是比较大的。
第三点存在不足，我们在我们自身的IT建设上存在着一些不足，包括我们现在自动化和标准化有所欠缺，很多自动化、标准化平台还在推进和开放之中。其次的就是我们现在的监控体系还不够完善，还有一些监控缺失和监控死角的地方。
这就是我们线上的业务现状，接下来看一下我们当前的系统架构。
这幅图是我们线上系统架构的缩略图。我们现在使用的系统架构，应该是和业内比较流行的互联网模式的微服务架构是比较类似的，就是从入口层到接入层，然后就是我们的后台web层，web层之下就是我们的后台服务层，最后到存储层。我们整个架构所用到的相关组件，一些存储类的软件，都是通过开源的方案来实现的。这就是我们整体系统架构的现状。
前面是对我们迁移到混合云的原因以及相关的一些系统现状做了一些说明，接下来看一下我们要达成的一个目标及整体的一个迁移思路。
我们的目标分为三点：
第一点，迁移完成后的系统架构保留与原阿里云上一致。大家可以从左边看到原来在杭州阿里云的物理架构跟我们新建的混合云的这个架构，整体的层级是一致的，没有太大的变化，我们只是在入口上做了一些调整。
第二点，要把我们原来在杭州阿里云上所有的存储、服务和安全资源全部迁移到深圳混合云平台。在迁移过程中要保证数据的一致性和服务的完整性。这就是比较关键的一点。
第三点，域名保留在杭州阿里云上不变。因为域名备案的需要，把原有的公司域名保留在杭州的阿里云上，我们最后通过DNS的流量转化，把所有的原来流量引到我们的审核入口，同时在原来的杭州阿里上保留小部分流量，最终DNS的转发到我们的Nginx层上来，这是我们要达成最终的一个目标。
针对这个目标，接下来看一下我们内部的整体迁移思路。
我们整体的迁移思路分为三个阶段：
1、环境准备阶段
第一步 线上资产梳理，要把我们线上所有的服务器、网络、支持数据以及相关的一些配置架构信息全面整理出来，明确迁移范围，避免在迁移过程中出现资源丢失和遗漏的情况。
第二步 网络与专线实施，我们现在需要的专线主要有两块，一块的是我们萨摩耶数据中心到阿里云之间的专线，然后另一块就是我们混合云到第三方合作商之间的专线，这两块专线的完成是我们下一步工作开展的一个前提。
第三步 我们需要做好基础环境的部署及测试，我们要把所有基础的软件，包括操作系统用到的各种组件，安装完成，做好相应的测试验证工作。
2、迁移验证阶段
第一步 平台连通性测试，我们用的混合云是一个全新的平台，我们需要做大量的安全战略和网络的隔离，为了保证我们后面迁移完成之后，区域之间的服务调用能够正常。
所以我们要先做下连通性测试，我们主要是通过模拟线上的整个布局规划，然后验证所有的系统功能来完成测试验证工作。
第二步 应用与储存迁移，我们基于安全性和稳定性的考虑，确定整体的迁移思路，是分批迁移。然后我们要分步的来批示，把所有人员在阿里云上的应用服务迁移到我们的这个新的混合云上来。
第三部 业务应用验证，我们迁移完成之后，为了保证我们所有业务的功能正常，需要做好相应的验证与测试。
3、系统切换阶段
第一步 应用与储存切换，就是说我们先迁我们的应用与存储，在迁完应用与存储之后，一切都正常运行，就开始第二步。
第二步 流量入口的切换，应用与储存一切正常的情况下就开始逐步放流量，就是把我们原来在阿里云的流量切换到我们混合云的入口上来，这是第二步要做的。
第三步 经典网络到PVC网络切换，因为我们原有的阿里云域名的限制，保留了小部分流量，就要把它分销网络切换，经典网络到PVC网络切换，网络上来保证我们流量正常转发。
通过我们这三个阶段，九个步骤，基本上能够完成所有的迁移工作。接下来说一下我们为了达成整个迁移的目标，所面临的一些挑战和困难。
总体上来说，我们面临的挑战有三大类：迁移前、迁移中、迁移后。
迁移前的挑战：风险的评估与规避
迁移中主要有三点：
1、如何完整高效的完成数据迁移；
2、如何安全平滑地完成储存、应用、入口切换，最大限度的降低对现在的影响；
3、如何全面快速完成切换后应用验证，验证要求我们做到全面快速。
迁移后主要有两方面需要考虑：
一方面，我们要做如何快速发现和预警问题，
另一方面，出现问题之后，我们怎样要做快速的回馈。
如何评估风险，制定相应的规避措施
我们风险评估制度是：首先就是划分不同的风险阶段，主要是迁移前、迁移中、迁移后，再明确我们自己的风险类别，包括我们的网络和平台的风险，然后明确我们在每个环节的风险点，最后针对每个具体的风险点制定应对措施。
根据我们上半年经验来看，有一点就需要我们重点关注一下，就是专线的实施，主要是指我们萨摩耶数据中心到阿里云之间的专线，因为混合云规划是用的10网段，阿里云的也是10网段，相同网段的专线是无法打通的，后面我们全面调整了萨摩耶数据中心的网络技术之后，才实施了专线的完成。这个过程花不了比较长的时间，在这里可以跟大家分享一下。
在这个环节最重要的就是我们的风险评估要尽可能全面，考虑到可能出现的各种因素，制定好相应的措施，才能保证我们后面的工作能够按照之前的评估计划有序的进行。
如何完整高效地完成数据的迁移，保持数据的一致性
看一下我们迁移的目标，我们的目标主要是有三点：
第一点 影响面要小，因为自己在迁移过程中会增加一些自己的拷贝、导出这类的就会产生比较大的消耗，线上读写性能，我们要尽可能降低对线上的一个影响。
第二点 迁移速度要快，因为前面说过我们整个专线的成本是很高的，比如说我们要尽可能的降低迁移时间周期，或者我们快速完成我们的迁移工作，节约迁移的成本。
第三点 数据的一致性，因为作为一个金融行业的公司，我们的数据的一致性要求比较高，我们要在迁移过程，保证我们数据是全一致。
如何安全平滑地完成储存、应用、入口切换，最大限度的降低对现在的影响
我前面的思路里面讲到过，我们整体的迁移思路是分批迁移，分批迁移的话必然会导致一个问题，不同的批次里面的存储和服务层的跨区域调用问题，我们跨区调用的延迟是25到35毫秒之间，这个延迟对整个系统影响比较大的。
针对这个问题我们提出两种切换选择：存储层跨机房和服务层跨机房，对于这两种切换方式有什么优缺点呢？
存储层跨机房
优点：
1、配置简单，切换⽅便
2、回退简单，只涉及到存储层
缺点：
1、如果存储层调⽤出现性能问题，很难扩容
2、存储层调⽤次数多于服务层调⽤，拉⻓响应时间
服务层跨机房
优点：
1、如果调⽤出现性能问题，能够快速实现扩容
缺点：
1、配置稍显复杂
2、需要重启两地的ZK服务
3、如需回退，⽐较困难
最终的选择
基于两种方案的数据对比，我们统计了线上所有的API调用，然后评估了所有API调用的整体的响应时间，以及调用次数，最后我们发现其实我们整体系统上一次请求，关键数据调用不超过三次。如果最多是三次最后调用，其实它整体要延长只有最多75毫秒左右，这样是我们应该可以容忍的范围，同时又考虑到我们迁移的这个难度，最终选择存储层跨机房进⾏存储和应⽤的分批次切换。
如何快速全面完成应用验证
最开始我们收到业务服务有40多个，应该说我们服务还是比较多的，要在短期内完成业务的全面验证与测试，这个难度是比较大的，但是同时要达到验证的目的，我们主要是通过把整个验证与测试环节拆分成两步来做。
第一步就是我们在系统迁移后，但是没有在切换之前做恢复验证。
另外一步的话就是说我们在系统切换之后做个全面测试，并且把我们所有主要的应用测试的环节保证在这个恢复验证阶段。
现在重点介绍一下我们这个恢复验证是怎么做的。系统已经迁移完成，但是没有切换的时候，分成四个阶段来做：
1、测试验证：修改本地host文件。直接访问我们整个混合云的入口，然后进行相关的一些功能的认证测试。
2、内部测试：办公网络DNS劫持。就是把我们整个办公网络的流量劫持到混合入口之后，公司的成员都参与到我们的验证实践中来，能够更全面的涉及到所有的功能点
3、外部验证：DNS解析部分流量到混合云。外部验证的主要是利用阿里云的DNS把我们的小部分的入口流量引到我们混合云入口，使用户能参与到我们整个验证测试工作中来，帮我们反馈一些问题。
4、逐步扩大分配到混合云入口的流量。就是我们逐步快扩大引流的范围，加大分配到我们入口的流量，让更多的用户能够参与到我们这个业务验证中来，最后完成我们整个应用的验证工作。
通过我们整个恢复验证的话，应该说大部分问题都是在我们恢复验证中一经发现就及时解决了。后面我们再做全面测试基本上都是没有出现这些问题。
如何快速发现和预警问题
很多时候我们在系统切换完成后，当时的这种验证测试是没有出现问题。但是随着我们流量的逐步放大，越来越多的用户进到我们系统里面，很多之前没有的情况会出现。
那我们要如何做到快速的预警发现？主要是基于我们现在的一个监控体系，我们的整个监控主要分为五组来做：
1、最底层的基础设施的监控，就是包括一些基础的资源的服务情况，一些流量的占用之类的。
2、云平台监控，就是包含云平台的各种性能指标之类的。
3、应用的监控，就是技术结构，这一层我们需要重点关注一些这种接口的调用指标，就是接口调用是否有超时的情况，或者调用明显降低的这种情况出现。
4、业务指标，业务指标是比较关键的，我们需要关注我们业务指标的用户访问情况，以及这个资金的交易情况，相比于或者说同比比有没有大的波动之类的。
5、对商城APP上的监控，主要看一下APP的活跃情况，以及APP端的响应时间是否正常。
通过我们整个这个五个层面监管，基本上覆盖到我们所有可能出问题的点，达到我们问题的快速发现和预警。
如果出现问题短时间解决不了，如果说要快速的回退
我们主要是通过以下四步来做：
第一步 我们要基于监控指标明确回退基线。就是说我们明确哪些情况需要回退的，或者哪些指标异常是需要回退的，就在我们前期的迁移的计划里面，包括现在方案里面要明确下来，后面如果出现相应的问题，要快速做出一个决策。
第二步 分批迁移，只回退当前切换批次。我们迁移的话是通过分批迁移的方式，如果出现问题需要回馈的话，我们实际的内容比较少，那么达到快速回归的一个目的。
第三步 数据反向同步，保证数据的快速回退。把数据同步到原来的机房，并且保留一段时间，这样子的话如果我们后期出现问题，再需要切换过去的时候，那我们可以不用花很多的时间做数据的同步。
第四步 完善的验证和切换程序，快速完成回退切换操作。就是说我们在整个迁移过程中是准备大量的切换程序和切换脚本，如果出现需要回退的情况，直接通过脚本就可以快速完成切换。
我们整个迁移项目持续了一个月左右，基本上把我们原来在阿里云上的一百个数据，四个服务全部迁到我们的新的混合云平台，我们分了五个批次，然后每个批次基本上是在两个小时以内完成它的切换工作。
下发完成之后，我们经过一些个时间的验证没有发现他有问题，应该说我们整个迁移项目是比较成功的。最后说一下我们迁移完成的经验分享。
迁移前
首先要准备好一个详细完善的迁移方案，就包括我们的迁移的计划以及迁移的范围和包括风险评估，以及具体的各环节组织的一些操作，都要体现在我们的迁移文档上。这方便我们能够按照计划，有序的推进我们前期工作的开展。
第二点就是多方有效的沟通，作为一个比较大的一项目，它涉及到的系统应该是公司所有层面上的系统，我们需要我们的部门包括开发、测试、业务部门的配合协调，所以我们要提前做好各方面的沟通沟通工作，方便我们过去的工作开展的一些支持和配合的事情。
迁移中
第一点分批迁移，风险可控。我们每一步迁移的存在的服务相对来说是比较小的，这样减小了影响力和我们迁移风险，做一个平滑安全的迁移。
第二点自动化脚本操作。就是说我们所有的操作要通过脚本化和自动化的这种模式来做，避免了一些人为操作的风险，同时它也能够提升我们整个迁移的速度。
第三点基于数据评估。就是我们线上所有的方案决策都要基于线上的数据来评估，包括我们整个操作及方案的一些合理性，避免出现异常的情况。
迁移后
第一点要重点关注业务指标。因为我们迁移完成之后，整体的系统使用，用户体验都没有大的一些问题，但是我们的业务指标有明显的异常，或者说有波动，这肯定是有问题的，你需要的进行一个排查去去跟踪，这块的话，其实我们公司也遇到了相应的一些情况。
最后一点加深了对线上业务系统的认识。经过整个迁移项目的实施开展，我们加深了线上业务系统的理解，为我们后续的一些自动化、平台化开发与推进，积累的一点经验。