从我 2006 年加入豆瓣团队以来,豆瓣无论从规模上还是从架构上都发生了很大的变化,并且看起来这个变化会越来越快,越来越激烈。从刚入职时十万级PV,到百万级PV 到千万级PV 再到并不遥远的亿级PV 目标,在每一个阶段,都给系统架构带来不小的挑战。
2009 年 4 月份,我应泰稳和大辉的邀请在 QCon 大会上和大家分享了豆瓣从最初上线到当时的系统架构变迁历程,没想到得到了很多人的关注和共鸣,从一个侧面也反映出来系统架构如何按需而变是大家共同关注的问题。架构设计是为了解决实际问题,一切的考虑从这个出发,可以避免无用的过度设计。
关注性能和可用性
2009 年,豆瓣的用户规模达到了千万级,最直接的需求是要解决数据量增加带来的性能问题,以及作为一个有影响力的网站,可用性要求需要上一个台阶的问题。前一个问题,我们通过对 doubandb(开源版本 beansdb 已经在 12 月份在 google code 上发布了第一个版本)进行了进一步的性能优化(主要是哈希树的内存缓存和数据的异步读写),并对一些影响性能的MySQL 大表做了水平拆分来解决。后一个问题,则是逐步完善各服务的fail over 机制,建立服务部署规范,扩大监控范围,并开发了一系列的小工具来简化配置更新和上线操作。在按需设计的同时,注意对设计模式的识别和抽象,总结方法,以规范和基础设施的形式将好的设计推广,可以说是我在工作中最重要的心得。
建立面向服务的架构
当前豆瓣的信息架构正面临着巨大的调整,传统的读书、电影、音乐三个栏目将以独立的二级域名子站方式呈现,而www 域名则成为社区站。各子站在发展路线和资源配给上会依各自不同的产品特性而具有一定的独立性。反映在技术架构上,则是需要把原来耦合度较高的代码和服务,依照产品类型进行解耦,为各产品线的未来发展留出更大空间。如何让这个过程进行的更为平滑,对产品开发工程师的干扰更小,是我目前最关注的问题。
同时,随着解耦的进行,各产品线新功能的不断推出,以及移动客户端战略的推进,会有更多的功能模块需要以服务的形式独立出来,豆瓣的架构也会越来越向面向服务的架构(SOA)倾斜。这是一个逐步发展的过程,在这个过程中,如何实现好SOA 治理,如何在与性能和开发维护方便性的关系中取得好的平衡,不为将来的系统留下混乱的隐患,都是非常值得研究的课题,也是现在我正在重点考虑的内容。
2010 年的关注点
在 2010 年,我希望能够在以下几个技术点上有所收获:
- NoSQL 数据库。09 年可以说是 NoSQL 数据库蓬勃发展的一年,各个流派的 NoSQL 数据库层出不穷,豆瓣也贡献了分布式 Key-Value 存储类型的 beansdb 给开源社区。2010 年里,相信这些新兴数据库会逐步稳定和成熟起来,也能看见大量的实际使用案例。对其他类型的 NoSQL 数据库的应用,以及与传统 RDBM 的配合使用(NoSQL 的意思是 Not Only SQL,关系型数据库在不少场合下仍然是最优选择),消除 RDBM 在 scalability 上的劣势,会是一个很有意思的课题。
2. 多语言混合开发。豆瓣技术团队传统的开发语言是 Python 和 C,但随着团队成员兴趣的不断扩展,以及新鲜血液的不断流入,对其他开发语言的应用也逐步增多。C++、Java、R、Erlang 以及 Google 在 09 年新推出的 Go 语言,在团队内部都有爱好者,而且这些语言各有特色,各有特别适合的使用场景。如何充分发挥 Python 的胶水语言作用,以及充分发挥 SOA 架构实现无关的特性,来达到让每一个语言各尽其能的效果,也是一个不错的研究对象。
3. 并行计算平台。随着数据规模的增长,豆瓣的后台算法已经很难在单机上完成计算任务,越来越依赖多机并行计算来保证运算速度。目前已经初步实现了基于 MPI 的并行计算平台,基于 Hadoop 的 MapReduce 平台也正在搭建之中。希望能够对它们进行深度定制和二次开发,让它们协同工作,各取所长,并且能够与豆瓣的其他基础设施如 doubandb 完美协作,成为豆瓣规模化运算的方便平台。
- SaaS。随着豆瓣的商业发展,会出现面对合作伙伴或用户的付费服务需求。一个完备的 SaaS 架构会是成功的基础。这对豆瓣而言是个全新的领域,并且对可用性、数据准确性等提出了更高的要求,也是很有挑战性的。
相关内容:
1、架构师(三月刊)
个人简介:洪强宁,2002 年毕业于清华大学,现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质,在网站架构、性能、可伸缩性上进行深入研究。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大 家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论