2013年6月17日星期一

淘宝高性能架构简介

本文只是做个简介,起抛砖引玉效果,希望能给大家一些启发(ps:作为一线码农,在工作中经常接触并使用这些框架,深深为其强大功能、设计思路所折服)

1. session框架
session大家肯定都不陌生,由于HTTP协议本身是无状态,前后两次请求通常是没有关联的,但由于一些业务需求,又必须让其有所关联(比如登录,不可能让用户每次访问一个页面都需要重新登录一次,那用户肯定会疯掉)
此时我们就需要借助session机制,将用户的一些信息存储在服务端,其主键jsessionid存储于客户端的cookie中,下一次用户发起请求时,servlet框架会根据jsessionid自动寻找关联的信息。
但随着互联网的快速发展,用户群越来越大,如何来存储、管理庞大的session信息显得越来越重要。
通常的作法是采用集群(多么熟悉的名词,ho~ho~),例如tomcat采用集群节点广播复制,jboss采用配对复制,但都严重影响系统的伸缩性,不能通过增加机器达到更好的水平伸缩,而且随着节点的增加,节点间的通信也更加频繁,势必会造成系统内耗加大。

webX框架的基于cookie的session可以有效的解决这个问题,将信息存于客户端浏览器的cookie中,而应用节点本身不保存任何状态信息。但要注意的一点是不同的浏览器对cookie的支持标准不一样,关于这块可参照之前的文章《浅谈浏览器cookie》。对于这个问题,我们的解决方案是“多值cookie”,一个组合键对应多个cookie值,可以有效将cookie的个数控制在20个以内,很大程度节省了cookie信息的存储空间,更多精彩可参考《Request context之session指南

2. 缓存tair
缓存,主要是为了减轻对数据库的压力,使用场景非常广泛。有浏览器缓存、反向代理缓存、页面缓存、对象缓存等
tair是淘宝的一个高性能、分布式、可扩展、高可用性的key-value结构的存储系统。

     非持久化:   
          mdb引擎: 只支持key/value,单机性能7w qps(测试条件:单条记录512字节,响应时间2ms内)
          rdb引擎: 不仅支持key/value,还支持list/hashmap/set/sortedset等复杂数据结构。
     持久化:
          kdb引擎:采用了kyoto cabinet做为引擎,性能在2000 qps单台。
          ldb引擎:采用了leveldb做为引擎,并且自带cache。服务器采用了ssd,性能在5w qps以上。

目前tair已经开源,开源地址:http://code.taobao.org/p/tair/src/

3. 服务化(HSF框架,dubbo)
服务化的核心就是解耦,将生产端和消费端有效拆分,借助于HSF来达成调用关联。使用系统的整体可用性、扩展性大大增强。

举个很形象的例子,一个业务开创之初,可能只有一个应用,但随着业务的不断膨胀,代码量也越来越大,无论后期开发还是维护带来的成本都是很高的,此时,从架构的角度会进行系统拆分,通过增加子域名的形式,借助于http请求,将不同的业务交由不同的系统来处理。
比如商品展示交由系统A处理;当用户添写一个购买数量,并选择好规格属性后,点击“购买”按钮,会将请求发送到系统B来处理, 无论从业务划分、模块定位、还是代码开发,都鲜明不少。

现在回到我们服务化的内容来,在服务化推广之前,底层业务通常是这样处理,如果你想使用部门A的业务(通常要数据库操作),首先要引入相应的jar包,尤其是底层的dal层的包(sql.xml ,接口,接口实现等),然后在应用中手动配置各种bean关系,可以说相当繁琐。当然如果只是配置一次,再繁琐也忍了。互联网千变万化,电子商务更是瞬息万变,业务变更相当频繁,代码频繁改动那更是家常便饭。想象一下,如果你的dal层jar包被十几个业务线所依赖,如果你想改底层的dao接口实现,你是不是需要这十几个业务线也跟着空发布一次,只是为了打包时能加载你最新的代码。
痛苦之大难以想象。幸好有了服务化。服务化可以有效将业务收扰到服务端,对外只暴露一个接口即可,如果你想用我的业务,只需做下简单接口配置即可,调用时,HSF框架会帮你找到对应的服务端,然后服务端会进行相应的业务处理,返回给你想要的结果,是不是清晰了很多。

4. 数据库拆分TDDL
现在是大数据时代,随便一个应用,动辄就是上千万的数据,数据库表示压力越来越大。分库分表成为业务发展的不二选择。
TDDL是淘宝开发的一套分布式数据库访问引擎。可以有效解决
a)数据访问路由:数据的读写请求发送到最合适的地方
b)数据的多向非对称复制:一次写入,多点读取
c)数据的存储自由扩展:不再受限于单台机器的容量瓶颈和速度瓶颈,平滑迁移
关于分库分表可以看看iteye上的一篇文章《淘宝下单高并发解决方案
另外tddl也开源了,开源地址:http://code.taobao.org/p/tddl-dynamic-datasource/src/trunk/

5. 异步消息(notify)
主要是借助消息中间件,采用异步通信来达到系统的伸缩性,以最大化的对各个子系统解耦。
具体是采用同步通信还异步通信,需要结合业务来衡量,如果业务本身关联度较大,建议还是采用同步通信比较靠谱。
关于异步消息这块,之前有过简单整理《基于消息的分布式架构设计

6.  非结构化数据存储 ( TFS,NOSQL)
并非所有的数据都是结构化的,比如一些配置文件,交易的快照等,一般不适合保存到RDBMS,更符合一种Key-value的结构;另一类数据,数据量非常大,但实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储。
一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,影响其它数据读取性能,也要和其它信息分开存储,一般的选择分布式文件系统。

随着互联网的发展,08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性三者不能同时满足,最多只能同时满足两个。
传统关系数据库采用ACID事务策略,更加讲究高一致性而降低了可用性的需求;但互联网应用往往对可用性的要求要略高于一致性的需求,这时候就要避免采用数据的ACID事务策略,转而采用BASE(基本可用性,事务软状态以及最终一致性)事务策略

目前此类产品有facebook 的cassandra,apache hbase,google bigtable等,非常适合一些非结构化的数据,如key-value形式数据存储,具有很好的水平伸缩性

没有评论:

发表评论