边开飞机边换引擎的案例

Bye bye Mongo, Hello Postgres

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

GitHub 网站的代码从 Rails 3.2 升级了到 5.2

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

Pinterest 采用新国际域名的工程方面的经验

这是一道不错的中高级工程师面试题:贵公司的各国网站从子域名(如 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.” 搜索引擎对一个独立域名在特定时间内能索引到的页面数是有限制的,采用多个顶级域名就能快速增加被搜索引擎索引的页面数。

用自建的 data pipeline 替换掉 Mixpanel,每年节省 $24 万

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

Kubernetes at GitHub

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

Moving Yelp's Core Business Search to Elasticsearch

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

Duolingo 用 Scala 重写系统的经验

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

改数据库 schema 迁移数据最佳实践

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

替换 MongoDB 存储引擎的那几个不眠夜

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

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

Yelp 网站的 https 大迁移

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

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

Netflix 将他们的 billing 系统迁移到 AWS 的经验

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

Dropbox迁移到HTTP/2的经验教训

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

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

HTTPS is Hard

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

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

升级到PHP7,省下$100万

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

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

Dropbox 迁离AWS的史诗般的壮举

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 ...

运营AWS 10周年学到的10条经验教训

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."

Ghost 如何从物理服务器迁移到 DigitalOcean

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

Move Fast and Fix Things

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

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

Uber 的数据库大迁移

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

Box迁移到HHVM的经验

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

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

从MongoDB迁移到PostgreSQL

Olery团队分享他们从MongoDB迁移到PostgreSQL的原因以及经验。 文章中没讲为什么他们一开始选择了MongoDB,因为schemaless的好处?但他们放弃MongoDB的主要原因就是Schemaless!如果数据的结构变了,而忘了迁移旧的数据,代码中各种bug就会浮现出来。 Postgres听起来不是那么酷,但却是实用的,经得起实践考验的好的数据库,比如Reddit和Instagram的主要数据库就是Postgres。如果你想把RDBMS当成NoSQL用,也是可以的(比如较新版本的Postgres支持JSON type);但反过来把NoSQL当RDBMS用却不行(小打小闹跑着玩是可以,一定规模的production部署就算了)。

Swiftype从EC2迁移到物理机器的经验

他们一开始用AWS,但AWS常出现网络问题、VM莫名其妙挂掉、不稳定的性能等问题。他们决定迁移到物理机器上。前期准备花了一个月,迁移十分成功,整体性能提高2倍,而且每个月租机器的费用降低了一半。 看了很多这样的经验总结,都是一个方向:从云服务迁移到物理机器;还没看过从物理机器迁移到云端的。

StackOverflow升级数据中心的经验

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

从nodejs迁移到Go

Bowery团队分享他们生产环境的代码从nodejs迁移到go的感受。他们对Go的几条赞誉中,如果只能选一条,我会选"Faster deployment" -- Go把所有代码、依赖编成一个二进制文件,大大降低了管理各种dependency的operational overhead。

Github升级到Rails 3.0的经验

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