全 Tumblr 150亿月浏览量背后的架构挑战 _架构

每月页面浏览量超过150亿次，已经成为火爆的博客社区。用户也许喜欢它的简约、美丽，对用户体验的强烈关注，或是友好而忙碌的沟通方式，总之，它深得人们的喜爱。
每月超过30%的增长当然不可能没有挑战，其中可靠性问题尤为艰巨。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，并运行于超过1000台服务器上，所有这些帮助实现巨大的经营规模。
创业公司迈向成功，都要迈过危险的迅速发展期这道门槛。寻找人才，不断改造基础架构，维护旧的架构，同时要面对逐月大增的流量，而且曾经只有4位工程师。这意味着必须艰难地选择应该做什么，不该做什么。这就是的状况。好在现在已经有20位工程师了，可以有精力解决问题，并开发一些有意思的解决方案。
最开始是非常典型的LAMP应用。目前正在向分布式服务模型演进，该模型基于Scala、HBase、Redis（著名开源K-V存储方案）、Kafka（项目，出自的分布式发布-订阅消息系统）、（由开源的容错、协议中立的RPC系统），此外还有一个有趣的基于Cell的架构，用来支持（CSDN注：富有特色的用户界面，类似于微博的时间轴）。
目前的最大问题是如何改造为一个大规模网站。系统架构正在从LAMP演进为最先进的技术组合，同时团队也要从小的创业型发展为全副武装、随时待命的正规开发团队，不断创造出新的功能和基础设施。下面就是Blake 对系统架构情况的介绍。
网站地址
主要数据软件环境硬件环境架构
1. 相对其他社交网站而言，有其独特的使用模式：
2. 目前运行在一个托管数据中心中，已在考虑地域上的分布性。
3. 作为一个平台，由两个组件构成：公共和
老的架构
最开始是托管在上的，每个自定义域名的博客都有一个A记录。当2007年无法满足其发展速度不得不迁移时，大量的用户都需要同时迁移。所以他们不得不将自定义域名保留在，然后再使用和路由到新的数据中心。类似这样的遗留问题很多。

文章插图
开始的架构演进是典型的LAMP路线：
采用了“扩散-收集”方式。当用户访问时将显示事件，来自所关注的用户的事件是通过拉然后显示的。这样支撑了6个月。由于数据是按时间排序的，因此模式不太管用。
新的架构
由于招人和开发速度等原因，改为以JVM为中心。目标是将一切从PHP应用改为服务，使应用变成请求鉴别、呈现等诸多服务之上的薄层。
这其中，非常重要的是选用了Scala和。
之所以没有选择Node.js，是因为以JVM为基础更容易扩展。Node的发展为时尚短，缺乏标准、最佳实践以及大量久经测试的代码。而用Scala的话，可以使用所有Java代码。虽然其中并没有多少可扩展的东西，也无法解决5毫秒响应时间、49秒HA、4万每秒请求甚至有时每秒40万次请求的问题。但是，Java的生态链要大得多，有很多资源可以利用。
内部服务从C/为基础正在转向Scala/为基础。
开始采用新的NoSQL存储方案如HBase和Redis 。但大量数据仍然存储在大量分区的MySQL架构中，并没有用HBase代替MySQL 。HBase主要支持短地址生产程序（数以十亿计）还有历史数据和分析，非常结实。此外，HBase也用于高写入需求场景，比如刷新时一秒上百万的写入。之所以还没有替换HBase，是因为不能冒业务上风险，目前还是依靠人来负责更保险，先在一些小的、不那么关键的项目中应用，以获得经验。MySQL和时间序列数据（分片）的问题在于，总有一个分片太热。另外，由于要在slave上插入并发，也会遇到读复制延迟问题。