背后那双手 - Evernote服务迁移到GCP的技术支持和方法论
编辑手记：Evernote在70天的时间里完成了3PB数据迁移至云端，整个过程竟然实现用户零感知。那么迁移过程到底使用了什么样的技术，我们一起来学习。
文章来自Evernote官方文档翻译，若有不精准的地方，请参考原文。
回顾：用户零感知到达云端: Evernote顺利完成向 Google 云平台的迁移
自2008年开始服务以来，Evernote已拥有自主配置和维护的服务器和网络。 我们能够用我们自己的方式，构建我们想要的服务。 当然自我管理也有一些限制，比如难以扩大规模、升级缓慢、维护昂贵。 虽然我们的基础设施在当时非常适合支持Evernote，但就现在来看，随着各方面的发展，基础设施在速度和灵活性上不能满足我们今后的需求。
对于每一个使用Evernote的人来说，迁移到公有云，这只是一个简单的商业策略，但让我们都感到兴奋，自从我们发布第一篇公告以来，我们就着手在后台实施整个迁移过程，将数据从物理的数据中心迁移至google云平台的新家上。整个过程完成很快，好像一眨眼之间我们就完成了迁移，用时仅为70天。
也许有人对于我们如何实现迁移以及迁移的整个过程的实现很感兴趣，我们接下来将会深入阐释为什么能够这么快的实现。当然并不是迁移方案，不会包含所有细节，但是在过程中一些重要的点和遇到的关键性的问题，我们都会详细说明。
为了大家更好的理解，我觉得有必要以简要介绍Evernote的服务开始讲起。
Evernote的服务介绍包含以下几个模块。
The Shard (NoteStore)
分片是Evernote上最核心的功能或者服务，通过创建块来存储用户的笔记。每一个分区能包含高达300000个Evernote的用户。每一个分区包含以下内容：
Evernote的客户端可以连接到前端的网页服务端，这是基于Tomcat实现的
数据存储层 - 实用Mysql数据库存储用户的笔记
检索索引 - 服务器端Lucene搜索用户内容的索引。
总共有762个分片，或者称为NoteStores，它们总共管理2亿个用户帐户并存储大约50亿个用户笔记。
The UserStore
基于MySQL的中心用户和首选项数据库，存储有关用户的所有集中信息，并管理用户认证。 由于此数据库管理并服务于所有用户状态和身份验证，因此它是服务中最关键和最复杂的部分，我们对其任何操作始终非常小心。
User Attachment Storage (Resources)
我们有一个单独的文件存储层，用于存储50亿用户文件（我们称之为资源）。 这包括206个自包含的WebDav服务器。 当用户将附件上传到Evernote时，Shard会将附件保存到本地的两个不同的WebDavs。 一个副本发送到位于远程灾难恢复数据中心的非现场WebDavs。
Front-end load balancing
我们运行高可用性负载平衡集群，它能够加速和终止TLS，并负责将用户的请求路由到他们的笔记数据所在的适当的后端分片。
Supporting services
最后，我们还有约200台Linux服务器执行缓存和批处理功能，如手写和文本识别。
关于迁移的选择
随着Evernote服务规模的扩大，架构迁移到云端将是一个复杂的工作，需要进行多个相关决策。我们希望能够快速移动和复制，所以我们采取了基于键值的战略决策建立一个稻草人的做法。然后，在可能的情况中，我们测试以查看是否稻草人是一个可行的方案。 这使我们能够快速迭代我们的计划。
我们从理解需要改变的地方开始，认识到有一些组件将不会简单地（或直接地）转化到我们的新的云平台。 于是迁移之初，我们将环境的组件分为两类：
Lift and Shift –- 这些系统在Google的云服务平台上跟物理的数据中心大致上是相同的，Shards，UserStore和大多数支持服务都在这个组。 他们在我们的物理数据中心基于Linux，并将迁移到云中类似的Linux虚拟机。
Transform – - 用户附件存储，我们的负载平衡层和识别服务（Reco）需要在迁移过程中经历重大变革。 在云上并没有类似的服务，或者更有效的实现方式。
迁移方法论
最重要的，是要选择合适的迁移方法。 对于Evernote，有以下两种方法可选：
Big Bang - 在迁移过程中寻找合适的时间点，当一切准备就绪，通过这个点从旧的平台完全切换到新平台。 这是比较常见的一种做法（可能是因为它是通常唯一的选择），因为大部分情况下，数据中心和应用程序体系是一个整体，很难分开进行搬迁。 但这种策略通常会存在较大风险，一次性的搬迁，出现故障将会是致命的。
Phased cutover – 这是一种分而治之的方法，可以按阶段或波形迁移服务，按服务或用户分组。 这样的模型还经常允许你在提交整个移动之前“测试”或验证迁移的部分
考虑我们的具体情况，很显然，Big bang并不是一个合适的选择。 即使有最好的规划，我们也会承担太多的风险。但同时，在多个数据中心或者物理站点分开实施搬迁也不适合，因没有对应的应用程序来支持。尽管有迹象表明我们可能已经在一段时间内创建了一个“拆分”的环境。
所以我们需要在两个极端之间找到一个折中的方法。 我们希望，如果可能的话，计划我们所谓的“阶段性加速切换”。 整个服务迁移将在20天以下的短暂时期快速实施，作为迁移窗口。然后对于其他后续阶段进行严密的部署和规划，以最小化每个步骤的风险。 同时我们期望允许回滚点，如果某一阶段没有达到预期的结果，可以快速回滚重新来过。
第二部分我们将会讲述Google 云平台的用户数据保护。
如果您有任何问题，欢迎您访问印象笔记论坛，技术团队的成员将会给您专业的解答。
如何加入"云和恩墨大讲堂"微信群
搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
Oracle公众号推出全新检索功能，只要你记得题目，作者，或者关键字中的任何一个，都可以通过回复获取想要的文章！更多精彩，请关注Oracle公众号获取。