背后那双手 - Evernote服务迁移到GCP的技术支持和方法论

编辑手记:Evernote在70天的时间里完成了3PB数据迁移至云端,整个过程竟然实现用户零感知。那么迁移过程到底使用了什么样的技术,我们一起来学习。

回顾用户零感知到达云端: 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 云平台的用户数据保护。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-02-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

MySQL中间件方案盘点

首先数据库技术发展的基础还是在业务推动的背景下,能够实现相关的技术保障。业务需求的提升必然会在数据量,访问量等方面有更高的要求,而映射到数据库层...

7915
来自专栏杨建荣的学习笔记

和开发讨论的一个数据变更需求(r9笔记第8天)

最近在评估一个开发同事的需求时,发现随着需求的变化,DBA相关的评估工作也会随之变化,同时反射到开发同事那边,通过这个案例也可以看到很多的需求变化,可以从中看出...

3395
来自专栏杨建荣的学习笔记

自动化平台开发小结(三)

今天来继续说说自动化开发的一些事情,截止目前,也是按照计划中的开发进度在推进。说几点自己的感受。 元数据的设计 元数据这部分我的设计就是从简,先来一个概要的信息...

3245
来自专栏韩伟的专栏

如何提高程序员的生产率(上)

一、硬件资源 1) 办公环境 ? 大部分开发团队都不把座椅家具视为一个非常重要的问题。拥有宽敞的桌面的环境,可以在桌上放置更多的东西:本子、笔、杯子、书本、打...

4296
来自专栏芋道源码1024

什么场景应该用 MongoDB ?

月初在云栖社区上发起了一个 MongoDB 使用场景及运维管理问题交流探讨 的技术话题,有近5000人关注了该话题讨论,这里就 MongoDB 的使用场景做个简...

3910
来自专栏张善友的专栏

微软发布正式版SQL Server 2016

微软于今天在SQL 官方博客上宣布 SQL Server 数据库软件的正式发布版本(GA),历时一年多,微软为该软件发布了多个公共预览版和候选版本,而今天最终...

2146
来自专栏Linyb极客之路

唯品会架构师是如何实现架构重构的

随着唯品会业务的快速发展,订单量的不断增长,原有的订单存储架构已经不能满足公司的发展了,特别是在大促高峰期,原订单库已经成为抢购瓶颈,已经严重制约公司的发展。

1742
来自专栏数据库

数据库设计技巧:一个字符串细节处理解决递归查询问题

问题提出 许多人在做开发时都会遇到这样的case,比如:需要维护一个部门层级结构,每个部门都要存储一个上级部门的id,记做parent_id, 当查询一个部门的...

22210
来自专栏程序人生 阅读快乐

MySQL技术内幕:InnoDB存储引擎(第2版) (数据库技术丛书) - 姜承尧.mobi

本书是国内目前唯一的一本关于innodb的著作,由资深mysql专家亲自执笔,中外数据库专家联袂推荐,权威性毋庸置疑。

1795
来自专栏逸鹏说道

微软发布同时支持 Windows 和 Linux 平台的新 SQL Server 预览版

  今年 3 月,微软 宣布将把自己的旗舰级数据库软件 SQL Server 带到 Linux 平台,这个 消息在当时堪称大大的惊喜。直到最近,预览版软件仍然是...

3659

扫码关注云+社区

领取腾讯云代金券