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

\u0026#xD;

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

\u0026#xD;

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

\u0026#xD;

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

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

\u0026#xD;

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

\u0026#xD;

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

\u0026#xD;

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

\u0026#xD;

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

\u0026#xD;

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

\u0026#xD;

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