边开飞机边换引擎的案例

这是一篇写得相当好的文章。The Guardian 放弃使用 MongoDB（不稳定、咨询费太贵又没用），迁移到 Postgres。本文记录了为什么启用 MongoDB，以及详尽的迁移过程。

历时一年半，都在同一个 branch 上进行改动，升级 Rails 与产品功能开发两不误。一个一个小版本循序渐进地升级。文章最后总结的经验适用于各种“边开飞机变换引擎”的升级/迁移操作。

这是一道不错的中高级工程师面试题：贵公司的各国网站从子域名（如 de.pinterest.com）改为顶级域名（如pinterest.de）后，对用户登录、js、SEO等有何副作用？请设计一套安全迁移的方案。

不错的发现：“One of the more interesting findings through this process was that more of our pages can be indexed, because a different top-level domain opens up a separate “crawl budget” for the search bots.” 搜索引擎对一个独立域名在特定时间内能索引到的页面数是有限制的，采用多个顶级域名就能快速增加被搜索引擎索引的页面数。

花了 5 周时间在 Google Cloud 上用 BigQuery、Dataflow、Kubernetes 自建 data pipeline。其实还得算上开发与维护的人工成本才科学啊，毕竟现在人比机器贵多了。

GitHub 将他们的大型 Rails app 迁移到使用 Kubernetes 来运行、部署代码。整个过程必然十分小心谨慎，做了各种措施、缓慢地增加迁移的信心。

Yelp 是 2004 年成立的，整个技术栈里难免还残留着一些古老的东西。他们刚把 business search 的后台从 Lucene 迁移到 Elasticsearch。

原系统是用Python写的。重新设计系统架构，用Scala重写后latency从750ms降到14ms，uptime从99.9%升到100%。可惜没说代码规模、开发时间多长、多少人开发。

算是基本常识了，四个步骤：1，dual writing，同时写到新旧两处；2，改从新地方读取；3，只写到新地方；4，删旧数据与旧代码。新地方可以是同一表不同列、也可以是不同表、也可以是不同数据库等。

他们将 MongoDB 的存储引擎从 MMAPv1 换成 WiredTiger，当 WiredTiger 缓存用满后，MongoDB 变得无响应；花了几个不眠夜换回 MMAPv1，数据恢复就用了36小时。

这是“边开飞机边换引擎”的失败案例：）抛开吐槽 MongoDB 的种种不是，他们在 production 上对数据库进行这么关键的操作确实准备不充分，灾难恢复也没做好。本文最后他们自己也总结了经验教训，另一篇来自 Parse 前系统工程师的博文针对此次事件也做了很好的评价，也推荐读一下。

2004年成立、2011年上市的 Yelp 最近才让网站每个页面都是 https 的。迁移过程主要担心的是已被Google索引的http页面会重定向到https，访问量会瞬间翻倍；所以一开始先迁移他们加拿大的网站，试试水。

Google 从 2014 年开始，搜索结果比较偏爱使用 https 的网站；如果你最近才开始做网站，最好一开始就全部用 https，省得以后迁移会比较麻烦。现在湾区日报的网站每个页面都是 https。

看得出来这是很关键的系统，跟钱有关的，而且历史悠久。原来是放在自己的数据中心里，使用 Oracle 数据库。迁移到 AWS 时，用 Cassandra 与 MySQL 替换掉了 Oracle。迁移过程小心翼翼，边开飞机边换引擎：）

他们的web services用 nginx 做 load balancer。他们就把 nginx 升级到最新版，先在canary机器的nginx配置文件里enable http/2，然后观察各种监控图与nginx logs。还是有不少坑的。

整体感觉各种千奇百怪的客户端（浏览器与app开发的sdk）对http/2的支持还不成熟。

英国本地生活服务网站yell.com全面支持https，这一过程动用了超过10个工程师，花了7个月，牵动公司内部众多部门以及其他第三方服务提供商。满满是坑。

文章很长，值得一读。现在做网站最好一开始就是https，省却以后迁移的痛苦。

Badoo 将积累了10年的、超过2百万行的PHP代码升级到PHP7后（紧随Etsy之后，第二个大规模使用PHP7的公司），CPU/内存使用降了一半，少运行了一半的机器（300台），直接省下$100万。

他们一开始也实验了一下HHVM，但由于诸多不便之处（兼容性、Facebook的独家开发、部署超慢等），最终没用HHVM。作为对比，同样使用PHP的 Box 与 Wikipedia 倒是都在Facebook的帮助下，用上了HHVM。

2016年3月，就在AWS庆祝开张10周年之际，AWS的大客户Dropbox一方面庆祝5亿注册用户这一里程碑，另一方面有组织有计划地完成了为期2年半的迁离AWS的行动。

Dropbox使用AWS 8年了，用户数据500 PB（主要存在s3上）。本文全方位报道了Dropbox自己设计服务器的硬件、自己开发了一个类似 s3 的存储服务（一开始用golang，后来改用rust）、#边开飞机边换引擎#地史诗般地数据大迁移，耗时两年半，在与AWS合同到期前完成迁移。

这种大规模行动最令人骄傲、也最令人失望的是：用户丝毫没有察觉。令人骄傲，因为没有中断服务，用户正常使用；令人失望，这毕竟不是开发酷炫的新功能、工程师们没法指着屏幕告诉朋友们“这个是我做的”。

那Dropbox为什么要迁离AWS？1. Dropbox这种规模的服务，（据说）用自己的数据中心比较便宜；2. Amazon也有类似Dropbox的这种面向最终用户的云存储，算直接竞争对手了，Dropbox肯定不放心把自己的业务放到自己竞争对手的数据中心里 -- 可为什么Netflix就不担心？hmm ...

Amazon CTO 的文章。从2006年3月14日上线第一个云服务 S3 后，AWS走过了10年。“There is no compression algorithm for experience.”

总结的这10条经验教训既可以当做运营 cloud business 的商业经验来看，也可以当做是搭建分布式系统的工程经验来理解，值得一读。

边换引擎边开飞机："... the evolution of Amazon S3 could best be described as starting off as a single engine Cessna plane, but over time the plane was upgraded to a 737, then a group of 747s, all the way to the large fleet of Airbus 380s that it is now. All the while, we were refueling in midair and moving customers from plane to plane without them even realizing it."

非常详尽的 step by step 的技术文章，内容的组织很结构化（每一步骤都有why，how，result，resources），很方便阅读。

来自 Github 的非常精彩的清除technical debt 的案例。用5天 part-time 的工作，成功重构 Github 的 merge 代码（Pull Request页面那个merge按钮的功能）。

重点看他们如何研究可能的解决方案，如何小心翼翼，如何用来自 production 的少量请求对比新旧代码在功能与性能上的异同。他们在 infrastructure 上的长期投资让诸如此类的代码重构／实验变得（相对）轻松愉快。Github一天能部署网站（github.com）代码60次之多。

从SQLAlchemy+Postgres迁移到自家基于MySQL上开发的NoSQL。数十个工程师，耗时8/9个月的开发与准备，在按下按钮的当天早晨6点，工程师们全体到公司报到，以防迁移过程出问题。

（原链接被墙，下载 iOS App 免翻墙阅读原文，或看打印出来的pdf文件：https://nfil.es/a/8fQcrl.pdf/）

再来一个“边开飞机边换引擎”的案例。HHVM 是 JIT 的，他们每次部署新代码都要事先跑 curl 来 warm up 一下。

又是一个“边开飞机边换引擎”的案例。stackoverflow团队分享了他们升级使用了4年多的物理服务器的经验。用了1.5天进行升级计划，用了4天时间肉身前往数据中心升级机器，文章最后给出的那张图应该是所有“边开飞机边换引擎”的工程师最喜闻乐见的吧：升级前后的性能对比。

Github是跑在Ruby on Rails上的。他们公司4个工程师用了6个月时间，全职工作，将他们production的Rails版本从2.3升级3.0。 如果你也经历过这种过程，一定能体会到此中的痛苦：production里的ubuntu/postgres/mysql/django/rails已经落后于最新版本若干年了，升级到下一个版本后，刹那间所有东西都不work了。于是就懒得去升级，一直拖着。直到最后忍无可忍了，就只能放下手头重要的产品开发任务，专门来升级runtime systems。