作者 | 阿木
责编 | 郭芮
上周，知名社交网络平台 Myspace 丢失了自公司成立以来（2003年）到2015年期间的全部用户上传数据，且不可恢复。Myspace 官方对外宣称数据丢失是由大批量的服务器迁移失败而导致的。
据 Kickstarter 前首席技术官 Andy Baio 称，Myspace 此次数据丢失波及1400万创作者，包含一些借助 Myspace 走红的知名艺人，如 Lily Allen、Arctic Monkeys、Kate Nash、Calvin Harris 与 Yeasayer 等，具体丢失的数据可能会超过5000万！这些数据包含众多创作者在2003年到2015年期间上传的所有图片数据、音频数据、视频数据以及发布的其他内容。
Myspace 简介
Myspace 是一家社交网络服务网站，在2005年到2009年期间曾经是全球最大社交网站，用户数可为海量。
像常见的社交网站一样，Myspace 网站提供的功能有人际交互、自定义朋友网络、个人空间页面、博客、群组、照片、音乐和影片的分享与存储，除此之外也提供内部的搜索引擎和内部的电子邮件系统等功能。Myspace的总部位于美国加州的圣塔莫尼卡，其母公司总部则位于纽约市。
根据 Alexa 网络公司调查，Myspace是全世界第四受欢迎的英语网站，而在所有语言的网站中，受欢迎的程度则排名第六，并且也是美国第三受欢迎的网站，有许多星期Myspace的排名皆为第一名。
Myspace提供的服务比起其他的小型网站更受欢迎，在所有社交网络网站的访问次数中，Myspace就占了将近80%。在2006年8月9日，Myspace 注册的用户量达到1亿，不过最近几年 Myspace 的用户正在逐步的流失，注册的用户数在不断的减少（YouTube 的崛起导致）。
2011年6月30日，Myspace 公司的 CEO 以邮件的形式对外向全体员工宣布，Myspace 以3500万美元被在线媒体和广告公司Specific Media收购。
有趣的是，Myspace 公司曾经于2007年4月在中国推出过一个试用版，即Myspace.cn，也称 Myspace 中国，后续也许是水土不服，Myspace 在中国的业绩表现并未像在本国那样的出色。
虽然今天的 Myspace 网站已经没有了昔日的辉煌，但凭借多年的积淀还是拥有大量的用户群体，有许多用户仍然依赖它保存自己喜欢的图片、音乐、视频等档案。
据媒体报道，此次数据丢失问题发生后不久，Myspace 已经向受本次事故影响的用户道歉，并承诺日后会竭力避免此类的故障再次发生。
大家可能会问这样一个问题，一个拥有这么多用户的公司，为什么迁移服务器失败会导致数据永久丢失？
正常情况下迁移失败后，后面解决掉迁移过程中遇到的问题后再次迁移不就可以了吗？退一步讲，即使数据丢失了，数据备份总该有吧，总不能数据就存了一份吧，用备份的数据恢复下不可以吗？很遗憾，对于上面的问题答案是不可以，因为 Myspace 丢失的这些数据确实只有一份，没有做冗余备份，这个结果在今天的我们看来确实是匪夷所思，但问题确实是发生了。
大型系统的迁移对于一个公司来说是至关重要的事，需要慎之又慎，一般需要分批、逐步迁移，一次迁移少量的数据，以防止迁移中途出现意外导致迁移的数据丢失，且迁移之前需要做好完整的数据备份。
谈谈大型系统迁移
系统迁移通常又称为系统切换，一般指在新系统开发完成后将老的系统的流量迁移到新的系统的过程。
一般来说，公司的技术能力发展和公司的发展类似，是一个从快速迭代到逐渐成熟的过程。系统的升级或者迁移一般也是遵循这样一个类似的过程，尤其是对于一个大型的系统的迁移，一般需要经过很多的步骤，如需要梳理业务的重要程度、业务的依赖关系，哪些业务是允许停服的，哪些不允许停服，允许停服的业务可以停服的时间长度等都需要在迁移开始前进行梳理。
前面准备工作完成后根据业务的重要程度，从最不重要的业务可以进行迁移，先将一部分的流量切过去，查看新系统是否可以正常工作，如果正常则再将此业务剩余的流量逐步的迁移过去，后续因此迁移稍重要的业务模块，直至迁移工作完成。
公司技术发展过程中，相比一般的业务系统，核心系统的功能演进一般是比较缓慢的。原因有很多，每个公司可能会有区别，在此我们列举几个：
1、公司正在运行的业务需要核心系统必须稳定，核心系统在项目的初期可能就已经定型了，为防止影响到在线业务一般不能轻易变动。
2、随着业务的发展，核心系统的功能会越来越复杂，模块也会逐渐的增多，模块之间相互依赖的概率也会逐步增大，迁移的难度越来越大。
核心系统迁移在一个公司的发展过程中一般是很少出现的（可能会影响到公司的生死存亡），大部分员工从入职一个公司到离开这个公司可能都没有经历过一次公司核心系统的迁移，再加上每个公司核心系统架构的差异性，因此了解核心系统迁移的技术人员也就相对较少。
在此我们梳理了一下迁移一个核心系统需要经历的过程——假设新系统环境已经部署完毕：
1、梳理系统业务
系统切换之前必须要充分理解迁移涉及的每个业务模块，包括每个模块的业务逻辑，各个模块之间存在的依赖关系，各个业务模块另外也包括需要迁移的这些模块中当前已知的一些缺陷。
2、制定回归方案
系统迁移完成后一般需要跑几遍回归Case，确保新的系统可正常运行。因此迁移之前需要先准备好回归的Case。
回归Case可以采用地毯式的回归Case，也可采用自顶向下、从核心到周边的方式。具体使用哪种方式需要结合自身业务选择，原则的话就是准备的Case 要尽量全面，覆盖尽量多的测试点，回归次数一般建议2轮以上。
3、性能压测
迁移前需要对已经部署好的新环境做几次性能压测，确保新环境可以支撑起现有的业务量，对存在瓶颈的部分需要尽快优化，不能将问题带到迁移中。
4、确定切流计划
一般做完前面的步骤后即可进行迁移计划的制定了，需要根据业务的优先级对业务进行排序，从优先级低重要程度的低的业务开始迁起，各个业务模块依次计划好迁移的顺序。
确定切流时最先切换的比例，如1%，确定切流的间隔周期，以及切流幅度。
5、制定应急方案
以上准备工作都处理完毕后，需要考虑下如果迁移过程中出现异常应该如何应对，指定兜底方案。
虽然压测和逐步切流可以避免很大的风险出现，但仍存在一些不容忽视的问题，如脏数据问题，需要对各种意外情况做好应急预案。
6、备份数据
迁移开始前需要检查各项数据库的自动备份是否正常，包括关系型数据和非关系型数据库，除了周期性备份之外，建议在迁移开始之前也要做一次全量的备份。
除了数据库中保存的数据之外，还建议保存诸如虚拟机的、容器的镜像数据，消息队列的数据等数据。
7、切流
具体切流时，安全起见一般建议逐步切，先切很小的一部分流量，如1%，看下切过去的流量在新系统中是否正常，如果正常再按照之前指定的切流方案逐步进行。
8、回归验证
执行到此步时系统一般已经切过来了，整个迁移过程已经完成了一半的工作。
不同规模的系统回归的工作量一般不同，大型的系统回归的工作量相对较多，一般建议进行至少两轮的回归，每一轮的回归必须包含前面设计的所有业务的链路，另外回归过程必须完成所有业务数据的检验，比如关系库数据、NoSQL数据、日志数据、消息数据等。尽量使用自动化的Case，自动化成本较大的Case可以考虑人肉排查。
9、数据监控
迁移过程中和迁移之前是不一样的，有些问题可能不会触发告警，即使我们配置了告警管理，这个时候就需要介入一些人为的判断，迁移过程中每个业务模块的技术人员都要时刻关注自己模块的运行情况。
总结
上文中我们只是从整体的系统层面梳理了核心系统迁移可能经过的一些过程，并未从具体的功能模块讨论，如数据库模块的在线迁移方案等。
数据库的在线迁移本身也是一个很大的部分，由于数据库是整个系统的核心，所以在线迁移数据库也被成为给飞行中的飞机更换引擎。此部分的内容较多，需要很大的篇幅才能描述完。在线迁数据库比较直接的方式一般就是源库设置只读，避免新数据写入源库，然后在线同步数据到新库，最后将老系统的流量切到新的库，具体内容在此我们不再赘述。
作者：王洪鹏，运营有个人公众号新新生活志。目前任职网易云计算技术部高级工程师，近3年云计算从业经验，爱读书、爱写作、爱技术。
声明：本文为CSDN原创投稿，未经允许请勿转载。
热 文 推 荐
☞在线公开课 | 从理论走向实践，多角度详解Cloud Native
GitHub超全机器学习工程师成长路线图，开源两日收获3700+Star！
曝光！月薪 5 万的程序员面试题：73% 人都做错，你敢试吗?
System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"
点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。
喜欢就点击“在看”吧！
扫一扫
251
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
