《天空之城》助 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 的架构感兴趣，不妨再做进一步的了解，然后将您的体会分享给大家。