《天空之城》助 Twitter 刷新纪录，新架构功不可没

本月，宫崎骏大师的《天空之城》在 NTV 迎来其第 14 次电视重播，剧情发展到高潮之时，“Blase 祭”也将 Twitter 的 TPS（Twitters per second）推上了新的高度——143,199 TPS，Twitter 一般每天会发出 5 亿多条微博，平均 5700 TPS，新纪录是平均值的 25 倍。

Twitter 的“大鲸鱼”曾为人津津乐道，每次 Twitter 出现故障都会挂出大鲸鱼，但细心的朋友一定已经注意到“大鲸鱼”的出镜率越来越低了。自 2010 年世界杯后，Twitter 便开始了大刀阔斧的架构重构，如今的 Twitter 早已不再是那个全球最大的基于 Ruby on Rails 的 Web 站点了。Raffi Krikorian 在 Twitter 的官方博客中介绍了新架构是如何应对 14.3 万 TPS 这一高峰的。

在开始重构前，他们为自己定下了三个目标：

• 新架构能在性能、效率、可靠性上有所突破，即改善用户体验到的延时，减少 10 倍的服务器数量，在故障面前，基础设施能做到故障隔离。
• 实现一个松耦合的面向服务的模型，鼓励系统级的封装和模块化。
• 能更快地让新功能发布到线上。

Twitter 曾经是 Rails 的“金字招牌”，发展初期大量使用了 Rails，但后来 Twitter 从 Ruby 转向了 Scala，一度让人们认为 Ruby 的性能问题阻碍了 Twitter 的发展，而Linkedin和Iron.io从 Ruby 转向其他语言，也加重了大家对 Ruby 性能的顾虑。其实，Ruby 并非幕后真凶，Rails 才是！为了提供一站式的 Web 建站设施，Rails 默认提供了太多的功能，正如范凯在其博客中说的那样：

Rails 适合开发 Website，但不太适合 Web Service，而移动时代的发展趋势就是：未来服务器端会更多的使用 Web Service 而不是 Website，这也意味着 Rails 将越来越不适合时代的发展。

虽然 Ruby 有点冤，但是 Twitter 却在从 Ruby 到 JVM 的转型中实实在在地得到了好处。Twitter 在 JVM 上实现了它的搜索引擎、流 API 和社交图谱，这让其服务器的吞吐量从每秒处理 200 到 300 个请求提升到了 10000 到 20000 个请求，带来了 10 倍以上的性能提升。

SOA 化也是 Twitter 重构中的重点，从一个庞大的 Ruby 应用拆分为多个相对独立、边界清晰的小系统，专注于各自的服务，服务之间通过Finagle实现 RPC 调用。很多知名的互联网站点都有过类似的经历，比如大家所熟知的支付宝和阿里巴巴，支付宝的首席架构师程立就曾在 InfoQ 上分享过自己在大规模 SOA 系统上的经验；在 RPC 框架方面，阿里巴巴也有自己的Dubbo 框架。

存储上，Twitter 对原先的 MySQL 主从结构做了调整，对数据库进行了拆分，在此期间，他们还开发了一系列的框架，比如Gizzard和Snowflake。淘宝也同样对数据库进行了拆分，大量地分库分表，并且开源了自己的 TDDL 框架。由此可见，国内外的各大网站当发展到一定规模之后，必然会采取一些类似的措施来保证自己能够进一步发展下去，正所谓“英雄所见略同”。

博文中还提到了监控与开关相关的内容，例如与 Finagle 整合在一起的 Viz 和Zipkin，能方便地对每个请求进行监控。而他们的 Decider 系统集成在 Twitter 的所有服务里，这个系统类似一个开关，能够快速地对功能进行切换，甚至能让某个功能仅为指定百分比的用户提供服务，如此一来，可控的灰度发布就能成为可能。说到功能开关，乔梁曾在介绍百度的持续交付经验时也提到过类似的概念，不过他说的仅是控制特定功能的打开与关闭，显然 Twitter 的 Decider 更胜一筹。

除了这次的博文，Raffi Krikorian 去年在 QConSF 上还专门就 Twitter 的时间线优化做过分享，而著名的 HighScalability.com 上对 Twitter 的新架构也有介绍，如果您对 Twitter 的架构感兴趣，不妨再做进一步的了解，然后将您的体会分享给大家。