Guradian这个名字非常陌生，这是一家位于美国的新闻类网站。他们的网站上面的主要内容是各种文章，博客和一些影音资料。作为一个新闻网站，当然会拥有众多的记者，并且网站会提供一个类似于CMS的文章排版系统。这些实际上就是整个网站的组成。本次阅读的文章是他们的技术团队在最近的MongoDB到PostgreSQL数据库迁移之后所撰写的文章。
2018年4月份，他们完成了MongoDB到PostgreSQL的迁移工作。文章介绍了他们为何要做这个迁移，以及如何做到的。实际上通篇阅读完之后，介绍数据库部分的内容实际上非常的少，大部分是介绍的整个迁移方案，而不是数据库本身。
为何要进行迁移，肯定是MongoDB表现的不太好了，Guardian发现了几个MongDB的缺点，这些缺点让他们难于承受，以至于要更换数据方案，我总结他们的所说的缺点有如下几个：
- 他们购买了MongoDB的OpsManager产品和一些技术支持服务，甚至都停止了内部的数据库只是的学习。但是后来使用的过程中，Guardian觉得他们花的钱不值，根本没有像享受到什么服务，什么事情都要的自己做，问题还得自己解决。
- MongoDB在一些设计上面有缺陷，效果不令人满意
- OpsManager让他们花了大钱，但是声称的什么一键升级的功能根本不好用。别说什么认证功能变更，导致的不能一键升级，我作为付费用户，不需要关心这个，我只关心你是否兑现了你的服务。
- Guardian觉得MongDB的管理还是比较复杂，花费了大量的时间（一年里面有两个月的时间花在数据库管理上面）
综上导致Guardian决定要替换掉MongoDB，至于替换成什么，他们有下面三点要求，其实我觉得这三点要求实际上不高啊。
- 最小的数据库管理要求，也就是别让我花费很多时间来操心数据库的事儿。
- 数据库要有对我们的作品进行加密的能力
- 当然需要能够做到从MongDB迁移的能力了
他们一开始觉得既然在AWS上面了，而且还用的是JSON的NOSQL数据库，那么干脆就直接用亚马逊的DynamoDB了，这里要不是因为有加密的需求，而且当时正好DynamoDB还没有这个功能，否者就会用上DynamoDB了，更没有后面PostgreSQL什么事儿了，也可以看出来平台对软件的选择起了很大的作用啊。等了9个月，啥也没有等到，AWS怎么可能为了一个Guardian而加快开发速度呢，还是有自知之明，换吧，直接相中了咱们PostgreSQL，这个家伙根本就没有提到MySQL啊，这里不知道为何，可能美国那边PostgreSQL地位这么高？Guardian经过一些调研，发现Postgres相当成熟，这种成熟度在stackoverflow这里就能看得出来了，基本上能问的问题都能够在上面找到答案了，为此对Postgres有自信也是自然而然的。实际上PostgreSQL真的是没啥说的，虽然作为一款开源数据库，但是还有很多的厂商再给他提供商业化的管理工具的，由于PostgreSQL的代码质量超级高，并且设计的架构也超级先进，所以大部分的管理工具的都非常的优秀。对于所有为PostgreSQL做商业化的公司都是一种福气。
第二部分，内容迁移
实际上文章往后就没有数据库的什么事儿了，都是人家迁移方案的事儿。
对于迁移，他们做了一个大体的计划：
- 在PostgreSQL里面创建一个新的数据库。将来MongoDB的数据库都要迁移到这里面
- 对上面创建的新的数据库，还要开发一个新的API，专门负责写入新数据。之所以这样做是因为他们觉得他们想要用接口之间的操作来做真是的数据迁移，而不是数据库对数据库的迁移，他们觉得API接口方便测试，并且老的API接口都已经经过完善的测试了，对此比较有自信。
- 需要写一个代理程序，用来对数据进行新老接口的分发。一开始数据转给老接口，然后在复制一份发送给新接口。
- 把MongoDB里面的数据移植到新的PostgreSQL。
- 删除MongoDB
2017年7，8，两个月的时间，他们就开发完成了这个代理程序。
真正的迁移工作是通过一个脚本来驱动的，这个脚本读取老接口的文章，然后导入到新接口中，最后在对比一下这两个接口中返回的数据是否一致。这种方法好像我之前在海信的时候做数据迁移的时候的想法，只是我全凭的是感觉，不如人家还写出了几个理论。
这个脚本有几个重要的设计要点：
- 能发HTTP请求就不用说了
- 每一分数据在做了迁移之后，都要比较两个版本的数据的一致性。
- 如果发生了error，必须停止下来。这个跟我之前做的好像不同，我让处理继续下去了，只是记录下来哪些数据发生了错误，现在想想可能遇到错误停下来是正确的。
- 工具需要生成足够多的细节来帮助问题排查。这个真的是说起来简单，做起来难，谁知道会遇到什么错误，保留到什么级别的数据才算够用啊，说到底还是靠经验和感觉吧，不过至少正在处理的文章的标识，遇到了什么系统错误要保留下来，其他的还需要什么，我也不知道了。至少我没有因为阅读此文章而获得此处的技能或者经验的提升。
- 下一次运行，需要在发生错误的那个点继续运行。这个说的也比做的容易100倍。还要看具体什么错误的，要想实现大部分的继续执行的功能，那实现的环节的工作量和复杂度会增加不少，比如在新插入数据的时候还需要检查一部分数据是否已经成功导入了，否者会发生duplicated数据的错误。
任何线上服务的互联网月，都应该至少存在线上环境和开发环境吧，实际上大部分还存在一个预发布环境（有些公司也叫灰度环境），本次迁移工作自然也要在开发环境先搞一搞了，开发环境和线上环境拥有相同的程序版本，只是开发环境没有流量，不过他们可以先尝试在开发环境评估一下迁移工作所要花费的时间。
在线上部署代理软件
代理软件自有的功能可以自己开发，但是流量复制的功能还是要请大咖啊，goreplay就是这个用来做网络数据复制的大咖。此时有goreplay和代理程序部署在了一起，但是发现goreplay消耗的系统资源太大了，以至于发生了一次宕机，虽然时间不长，但是也是一身冷汗，于是他们把代理程序部署到了他们的一个做监控的清闲的节点上面，这个路子感觉跟我当时也一样，没啥新意的东西。我一向都以为还有什么能够预判的神功，在系统负荷太大的时候能够自动的降级，保持系统的稳定运行，但是可能我还是太年轻。此处他们还发现了很多的代理软件的问题，有代码问题，设计问题，底层调用的问题，总之都是想要把东西做好都要面对的问题。处理好这些问题肯定是要花精力和时间的呢，成本是做事情最需要权衡的东西。Guardian团队当然认识到了这点，并且做到了适可而止，此时做了一个哲学的思考，要做大事，就必须要有冒险精神，要做好心里准备迎接错误，而且一定会发生错误，当然他们是幸运的，错误果然发生了，只是都不算太大。代理程序是一个临时用的东西，就这样吧。
之后的线上环境的迁移都是有惊无险的，总体算是顺利，也没啥亮点需要说的了。最后他们删除掉了所有的MongoDB相关的所有的部署。
我个人感觉这篇文章在国外的流行程度来看，所执行的迁移方案是有普遍的认可度的，而且是跟我的想法实际上差不多，在方案上面我对自己的想法有了更多的确认。我通过这篇文章主要是认识到了国外的IT圈子对于互联网应用圈子来讲，实际上跟我们国家没有多大的差别。软件是一个实践的学科，善于勤于思考，是能够想出来比较好的方案的（实际上好多时候，方案就那么多种，没有太多选择，受限于各种软件本身的限制，整体方案更是有限制）。
最后，软件不是泥巴，你想要他什么形状，它就能变成什么形状；软件是模具，一旦代码完成，他就是固定的了。泥巴是模具的输入，输出的是需求。
