背景介绍
对基于Jive的一个平台做迁移，所有的内容被导入到Google产品上，包含Google Drive、Google Group、Google site等。
迁移中我们使用了Google 提供的一套云端平台叫Google Cloud Platform（简称GCP）。官方对它的介绍是: 它是一项使用了Google核心基础架构、数据分析和机器学习技术的云计算服务，提供了一系列模块化的基于云的服务和大量开发工具，例如托管和计算、云存储、数据存储、翻译API、预测API。
所以GCP完全能满足当前我们迁移的需求，以下就是我们的流程：
第一阶段 - 数据备份
导读介绍：基于jive的平台是我们日常工作交流的工具。
在确定了平台迁移这一重大事情之后各方人马就开始一起参与进来，进行了迁移的工作。迁移平台要做的第一件事情就是数据备份，以下是我们数据备份的流程：
第一步，列举所有的数据并确定了数据备份的优先级，例如Group、Community、People、Blog、Document、Files、Discussion等。这个优先级在每天的站会中都会进行确认和调整，几乎达到了最快的反馈速度。
-
第二步，分析要备份的数据结构，通过Jive Rest API 获取解析数据，存在GCP的Spanner DB中。这个过程中写了大量的脚本，所有的脚本都在GCP 的VM上运行。
因为数据量的庞大，我们遇到了很多坑。例如，对于10万+的数据Jive Rest API经常返回超时导致无法获取我们要的数据，所以找了排序、分页、条件查询、对返回字段的控制等办法；数据量太大，数据备份太慢，剩下的时间太短，需要加快数据备份的速度，所以在脚本中加入了大量的并发处理；VM的存储空间不够，如何扩展存储空间的问题。
第三步，文件、图片、视频备份到GCP的Storage或者Google Drive上。在Jive上有很多文件，图片，视频，附件等，这些数据我们没有存在数据库中，而是直接通过API下载，并同步到Google Drive或者Storage上。同步到Storage特别简单，使用gsutil工具可以一条命令快速上传。
第二阶段 - 数据导入新平台
上一个阶段把数据存储在Spanner和Storage上是一个中间过程，最终我们会把Jive上有效的数据导入到Google的各个产品中。
第一步，筛选数据，确定最终存放的位置。在数据备份阶段中存了大量的数据，这些数据有的是已经被删除的，有的是过时的，对这些内容进行筛选以后进行整合确定了数据存放的位置，例如Team Drive、Google Group。
-
第二步，通过Google各个产品的API把数据导入到Google平台。
- 通过Google Drive API把Storage的内容（文件、图片、附件）放入到Google Drive里。
- 通过Google Group API把Spanner DB中存储的博客和讨论导入到Google Group中。
第三步，重定向。在数据迁移的过程中，发现数据之间是有关系的，例如一篇文章里引用了图片，带有附件，或者包含另外一篇文章的链接等情况，因为这些内容都已经放在了Storage或者Drive中，所以需要对这些文章里的链接进行重定向，保证文章里的链接都是可跳转的。对此，我们搭建了一个链接跳转服务，对于之前的链接替换所有的domain为新域名（my.newdomain.com），这些链接会经过我们的跳转服务中心，被导向到新的存放地址。
第三阶段 - 查漏补缺
平台数据迁移不是一朝一夕可以完成的，在把大部分的数据迁移完成后，就进入查漏补缺的阶段。根据一些特殊的用例找到它们的共性然后特殊处理。比如在这个过程中会发现有一些数据是无法通过Jive API拿到的、不在我们数据备份中的、曾经被用户删除的数据等等，对于这些遗漏的数据就会从Jive公司提供的数据备份中根据某些自定义规则找出来并导入到Google平台中。
GCP的使用总结：
- GCP这个平台与Google其他服务紧密联系，所以对于Google的一系列产品有着很好的集成体验。
- GCP的权限管理比较清晰，比如Sorage可以根据用户或组来给予权限。
- Spanner控制台只能进行查询，无法进行数据的增删改。
- GCP提供分钟计费和续用折扣，实时分析CPU使用情况并提示用户更便宜的方案。
最后的总结
这是我第一次参与的平台迁移的工作，之前一直觉得平台迁移是个艰巨长远的工作，那么做好这个工作的关键我觉得是如何做好任务管理，也就是很多人说的列task。把整个迁移工作列一些大的task，再对每一个大的task分细小的task，对于细小的task在做的时候又有很多checklist，把这些任务一级一级分解下来，一步一步有条不紊的完成，迁移也就变得简单起来了。
