上云并非一劳永逸，想要云上迁移，如何设计最佳方案？
为此，TGO 特训营准备了三场主题分享活动，旨在为企业提供“全面云化的工具方案构建指南”。7 月 18 日，TGO 特训营第一场主题分享活动在上海顺利举行，「流利说」平台团队管理者姚海涛以《云厂商评估 & “搬家”攻略 》为题，分享了选择云厂商方法以及云端迁移的经验，本文即由该分享整理而来，enjoy：
大家好，我是姚海涛。今天主要和大家聊一下云厂商评估和搬家的思路。
当我们选择一家云厂商的时候，首先应该思考第一性原则。
什么是第一性原则呢？对于线上服务的企业，首先应该考虑计算能力，包括虚拟机、 K8s（GPU）等等；其次，需要考虑存储，包括云盘、对象存储、数据库、缓存、消息队列；最后需要考虑的是网络——包括内外和外网。外网主要是考虑网络的稳定性，内网则是更多地去关注网络架构。
清楚了第一性原则，我们在选择云厂商的时候，也应该通过三个方面来考量：
产品；技术支持；生态。
下面，我们来逐一进行简单分析。
首先，如何判断产品是否满足业务需求？我们可以通过以下四个维度进行考量：
功能；质量；研发效率；成本。
第一，功能。当我们需要 GPU 服务时，不能提供这项功能服务的厂商自然会被淘汰，这就是从产品功能的维度判断厂商是否符合预期；
第二，质量。产品的可用性、 BUG 数量等, 都属于质量维度的判断要素；
第三，研发效率。这方面我们需要重点关注 API 、文档、社区等要素是否成熟，因为这是提升研发效率的基础；而研发效率的提升从侧面上也是云服务整体成本的降低.
最后，成本。成本则相对容易理解，主要是指产品价格。
其次，关于技术支持，我们可以通过以下两个方面去考虑：
应急响应；日常支持。
只有厂商的技术支持对所有状况都有预期，在遇到突发事件的时候，才能够快速响应、制定应对预案。厂商处理突发问题的时间是多久？他们团队的问题解决机制是什么？他们处理问题的透明度如何，是否会公开问题详情和改进措施？或者说，他们只是在敷衍了事？如果透明度出现问题，那么这次遇到的问题还有可能再次出现。
最后一个方面就是生态。
生态考察首重 API ，API 是基础；其次要考察文档的建设。
大家需要阅读各大云厂商的相关文档，判断其完善度是否可以支撑研发人员构建基础设施。当遇到问题的时候，我们能否 Google 一下就找到解决方案，还是必须同厂商的技术支持沟通？
现实中有一些厂商，非常喜欢通过群聊天的方式提供解决方案，可实际上，这些问题无法有效沉淀下来, 效率相对是不够高的。所以，若对厂商的技术生态情况进行评估，一个重要依据是有多少开源项目可以用来辅助构建自己所需要的平台或者服务。
总体来说，对云厂商进行评估是一件很宏观的事情。从技术角度来看，评估框架也不是一成不变的。我们需要结合自己的实际情况和真实需求，理智选择最合适的云厂商。
谈到“搬家”，我还是有一些经验可以分享给大家的。因为在不久之前，我们公司进行过一次比较大规模的云端迁移。
从本质上讲，搬家就是搬数据。我们能否在可控的、固定的时间内把用户数据迁移到另一家云厂商，还要确保业务不受影响，是“搬家”成功与否的关键。
那么我们应该如何进行“云上搬家”呢？
第一，在“新家”里搭建基础设施，屏蔽底层差异；
第二，“想要富先修路”，把两家厂商之间的专线打通。
因为在“搬家”过程中，专线是十分重要的。一旦专线出现问题，你就只能选择使用公网，而公网在质量和宽带上，都与专线相差很多。
做好前期准备工作，接下来就到了最重要的环节——“搬家”。如何实现“云端搬家”，我们可以分为三步进行：
改造；
演练；
割接。
首先，我们需要调研现有的全部业务架构和技术架构，了解每一个业务的运行情况和架构.
其次，我们要设计迁移架构。迁移过程中，最重要的技术决策是什么？是我们应该怎样进行迁移。
最后一点，我们需要将设计好的迁移构架实施落地，验证其可行性。简单来说，如果我们做一个移动互联网业务的话，那么整个业务架构应该是这样的——用户通过手机访问我们的 API GateWay，之后经过业务线的服务相互调用输出访问结果，最后结果数据到达底部存储层。
再往后，随着业务增多，我们的业务线拉长，每一条业务线产出的结果都会到达自己对应的存储层。那个时候，我们的架构就会变成下图的样子：
如果将业务线继续往后延的话，就会产生一个中台业务，中台会有自己对应的存储层。这就导致中台业务需要支撑起所有的业务线。如果此时我们需要进行业务迁移，供我们选择的方案就只有两种——“一把梭” or “排队”。
继续参照上图：我们有 A、B 两条业务线与中台业务。此时，如果要进行业务迁移的话，就需要我们做出决策——是要“一把梭哈”还是“排队一个一个来”。
前者风险比较大，需要涉及到的研发人员进行数据相关的架构改造。这就意味着, 我们可能没有机会进行尝试。迁移过程中一旦遇到问题，回滚策略与规则策略设计会很复杂。后者的问题是等待时间比较久，而且对中台业务的挑战比较大。
我们当时选择了“排队”的方式，来降低风险，同时对中台架构进行了相应的改造。
参照上图，我们在数据迁移之前，对中台技术架构进行对应改造, 做跨云架构. 业务流量割接后, 对中台的读请求先访问新机房的本地只读实例, 如果读取不到数据, 说明有可能是数据同步延迟, 再通过专线远程访问原来机房的服务, 确保读取到最新的数据. 对于写请求, 直接走专线写原有机房的 Master 实例.
这里仅仅是简单讲一下大概的流程, 中间还涉及很多细节, 而细节往往就是魔鬼。
我们在实际的迁移过程中，会涉及到很多研发人员。如果不进行多次演练，那么一定会出现现场混乱的情况。
通过一次又一次的演练，我们确保所有的问题都暴露出来，通过解决这些问题，我们去构建一个稳定的闭环，稳步寸进。最后，通过一次次的复盘，我们对“搬家”方案进行持续改造。
整个演练，最主要的目的是提高迁移过程中的配合效率。
割接之前，我们需要确定每个环节的预期时间以及最后截止时间；需要明确每个人承担的角色；需要提前做好预案，确保在遇到问题的之后，能找到相应的回滚策略。
割接的过程中，我们也需要制定方案，保证对用户的把控。
割接完成之后，我们还需要确定，报告手册的内容，数据测试的流程。
做一个比喻，割接过程就如同参演一个剧本，所有人按照剧本的要求来扮演好自己的角色就可以了。
把握好以下 4 条原则，可以帮助我们在“搬家”的时候，更好地选择存储：
举例来说，你在选择厂商的时候，需要留意他们的存储是否有定制化协议。一般来讲，各大云厂商是兼容的，但是，如果你选择了某厂商，他有一些定制化的协议，那么在改造过程中，你可能需要改造整个业务线框架，这些新引入的工作量，会极大地延长迁移时间。
平时大家可能觉得做缓存挺好，谈到做存储也可能有些工程师也觉得无所谓。但是用 Redis 做迁移的时候，就可能会出现问题。而 MySQL 相关生态和工具就更加成熟, 迁移起来更轻松.
用一个不恰当的比喻，就像是精致的水晶杯，在家里使用的时候很好用，但是“搬家”的时候就容易碎。
MySQL 由于相关生态和工具相对更加成熟, 迁移起来更容易。
每多一种存储服务，迁移过程中就需要有配套的迁移工具甚至特殊的方案设计，非常费力。因此建议如果没有特殊需求，尽量选择通用的存储服务。
高层的支持非常重要。整个迁移过程可能会比较长，甚至中间有不达预期的阶段，这时候高层的支持就显得非常重要。
演练更重要。在演练过程中，可以尽早发现问题，尽早让团队进入状态，正式割接时就是“照本宣科”，降低风险。
最小改动原则。迁移过程中，我们应当尽可能少地进行所谓技术改造优化，原封进行迁移是风险最低的。否则，一旦迁移过程中出现问题，你很难判断问题原因究竟是技术改造还是迁移本身。
迁移的过程中，我们要记得拍照或者录制视频。因为照片和视频，可以帮助你记录团队成员在迁移过程中的状态——遇到困难时的压力，迁移完成后的喜悦与释然等，这些瞬间，都能给团队留下美好的回忆。
有一种说法叫 Cloud Tax, 大意是云厂商会像税收一样, 从我们的业务发展中抽取一定比例. 如何通过优化降低云服务成本是我们时刻需要思考的问题。
作为额外拓展的内容，我给大家简单分享一下“云上降本提效”的方法，分为以下四点：
量化是基础。
我们需要将团队开销尽可能地细化——每个业务服务消耗的云服务成本，都需要做好量化。
两手抓：提升利用率 & 优化付费。
提升利用率就不多讲了，每家公司都在尽可能地提升资源利用率；
优化付费是技术活。很多云厂商在付费方式设计上有很多可以优化的点，例如包年包月 / 按需实例 / 保留实例 / 竞价实例等。如何在不同的厂商采用不同的购买方式，降低成本是一个技术活儿；
当然，商务谈判获得优惠的折扣也是不可或缺的一环。
好了，由于时间关系，我的分享到这里就结束了。大家有什么问题，可以现在提出来，我们进一步地去探讨。
希望我今天的分享，可以给大家带来帮助和启发，让大家在日后选择云厂商的时候，更加从容；进行云端迁移的时候，更加顺畅。
特别提示