原文:http://blog.sina.com.cn/s/blog_4c4a24db0102v4h8.html
问题导读:
1.什么是无状态应用无状态?
2.你是否使用过缓存,缓存对系统架构的影响是什么?
3.数据库压力过大,造成网站崩溃都有什么解决方案?
4.消息中间件产生的原因是什么?这是openstack、hadoop分布式有什么共同点?
5.为什么要安装监控、预警系统?
时间过得很快,来淘宝已经两个月了,在这两个月的时间里,自己也感受颇深。下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 伸缩,高性能,高可用性的分布式互联网应用。
一 应用无状态(淘宝session框架)
二 有效使用缓存(Tair)
三 应用拆分(HSF)
首 先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此 将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户 的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那 么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统, 不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大 大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整 个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整 体系统的可用性也大大增强了。
因 此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系 统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系 统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦,因此咱们淘宝也有了自己的HSF框 架。
上 面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了, 系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前淘宝正 在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。
OK, 既然明白了拆分的重要性,我们看看随着淘宝的发展,淘宝本身是如何拆分系统的。
淘宝系统的一个演变过程,在这个演变的过程中,我们所说的拆分就出现两个版本,分别为V2.2和V3.0之 间。在V2.2版 本中,淘宝几乎所有的逻辑都放在(Denali)系统中,这样导致的问题就是系统扩展和修改非常麻烦,并且更加致命的是随 着淘宝业务量的增加,如果按照V2.2的架构已经没有办法支撑以后淘宝的快速发展,因此大家决定对整个系统进行拆分,最 终V3.0版 本的淘宝系统架构形成:
在V3.0版 本的系统对整个系统进行了水平和垂直两个方向的拆分,水平方向上,按照功能分为交易,评价,用户,商品等系统,同样垂直方向上,划分为业务系统,核心业务 系统以及以及基础服务,这样以来,各个系统都可以独立维护和独立的进行水平伸缩,比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩 展。
从上面可以看出,一个大型系统要想变得可维 护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题,关于通信方面,淘宝目前独立开发了自己的高性 能服务框架HSF, 此框架主要解决了淘宝目前所有子系统之间的同步和异步通信(目前HSF主要用于同步场合,FutureTask方 式的调用场景还比较少)。至于系统间的依赖管理,目前淘宝还做的不够好,这应该也是我们以后努力解决的问题。
四 数据库拆分(TDDL)
好 了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的 重要性。
系 统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是 随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而 来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据 库读取压力太大了,此时咱们都清楚是到了读写分离的时候。
这个时候我们会配置一个server为master节 点,然后配几个salve节 点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开 始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗 流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还 可以针对商品信息的库采用master,salve模式,OK, 通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复 到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO, 不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候 无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).
OK,上 面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分 库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以 及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查 询数据,如何平衡各个shards的 负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。
拿 淘宝目前的情况来说,淘宝目前也正在从昂贵的高端存储(小型机+ORACLE)切换到MYSQL,切 换到MYSQL以 后,势必会遇到垂直分区(分库)以及水平分区(Sharding)的问题,因此目前淘宝根据自 己的业务特点也开发了自己的TDDL框架,此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制
五 异步通信(Notify)
在”远 程调用框架”的 介绍中,我 们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是 拆分了以后,子 系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节 中,我 们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既 然说到了异步通信,那 么”消息中间件”就 要登场了,采 用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.
说 到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务 上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。
OK,那 么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个 子系统构成,假如A和B是 同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行 伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同 步调用B, 如果A可 用,那么B可 用,逆否命题就是如果B不 可用,那么A也 不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在 提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。
下 面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很多其它的业务系统交 互,如果在一次交易过程中采用同步调用的话,这就要求要向交易成功,必须依赖的所有系统都可用,而如果采用异步通信以后,交易系 统借助于消息中间件Notify和 其它的系统进行了解耦,这样以来当其它的系统不可用的时候,也不会影响到某此交易,从而提高了系统的可用性。
最后,关于异步方面的讨论,我可以 推荐大家一些资源:
1 . J2EE meets web2.0
2. Ebay架构特点(HPTS 2009)
六 非结构化数据存储 ( TFS,NOSQL)
七 监控、预警系统
因 为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这 些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个 应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的 负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的 访问量是多,每个页面的PV是 多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可 少了。
前 面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和 内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快 速响应系统出现的问题,提高系统的稳定性和可用性。
八 配置统一管理
本文链接:http://www.aboutyun.com/thread-8121-1-1.html