淘宝可伸缩高性能互联网架构: 果然每一项都很关键

一 应用无状态(淘宝session框架)

假如在session中保存了大量与客户端的状态信息，保存状态信息的server宕机时

　　通常通过集群解决，不仅有负载均衡，更重要的是要有失效恢复failover

　　tomcat用集群节点广播复制，jboss用配对复制等session状态复制策略，但严重影响系统的伸缩性，不能通过增加更多的机器达到良好的水平伸缩

　　因为集群节点间session通信随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，要保证应用无状态，这样集群中的各个节点来说都是相同的，使系统更好的水平伸缩

　　淘宝的session框架用clientcookie实现，将状态保存到cookie里，使应用节点本身不要保存状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的

　　但有限制，比如每个cookie一般不能超过4K的大小，很多浏览器都限制一个站点最多保存20个cookie

　　淘宝cookie框架是“多值cookie”，一个组合键对应多个cookie的值，可以防止cookie数量超过20，还节省了cookie存储有效信息的空间

　　除了淘宝目前的session框架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session 服务器，session服务器将session保 存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。

　　二 有效使用缓存(Tair)

　　浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等

　　大部分情况都是读缓存,读写比不高，对数据安全性需求不高的数据，将其缓存，减少对数据库访问

　　店铺系统，如店铺介绍，店铺服务条款，宝贝详情,适合放到缓存中，减少DB的负载

　　三 应用拆分(HSF)

　　拆分(也算是一种解耦)，将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统，提高系统扩展性和可维护性，系统的水平伸缩性提升，可以有针对性的对压力大的子系统进行水平扩展而不影响到其它的子系统

　　子系统之间的耦合减低了，当某个子系统暂时不可用的时候，整体系统还是可用的，从而整体系统的可用性也大大增强了

　　拆分也给系统带来了问题，子系统之间如何通信

　　一般有同步通信和异步通信，这个时候高性能的远程调用框架就显得非常总要

　　四 数据库拆分(TDDL)

　　应用除了应用级别的拆分以外，另外一个很重要的层面就是存储如何拆分,通常就是所说的RDBMS进行拆分

　　数据库读取压力太大，就是到了读写分离的时候，配置一个server为master节点，然后配几个salve节点，通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统恢复正常

　　到了master负载太高时就要垂直分区了(就是所谓的分库)

　　比如将商品信息，用户信息，交易信息分别存储到不同数据库，同时还可以针对商品信息的库采用master，salve模式，

　　分库后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，数据库的压力终又恢复到正常状态

　　用户量的不断增加，系统中某些表异常庞大，比如好友关系表，店铺参数配置表等，这个时候无论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，此时就要进行“水平分区”了(俗话说的分表，或者说sharding)

　　数据库是系统中最不容易scale out的一层

　　大型的应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分 库)，然后再到水平分区(分表，sharding)的过程，而在这个过程中，Master/salve 以 及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查 询数据，如何平衡各个shards的 负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化

　　从昂贵的高端存储(小型机+ORACLE)切换到MYSQL后，势必会遇到垂直分区(分库)以及水平分区(Sharding)的问题，淘宝根据其业务特点开发了自己的TDDL框架，解决分库分表对应用的透明化以及异构数据库之间的数据复制

　　五 异步通信(Notify)

　　消息中间件登场,采用异步通信关系到系统的伸缩性,以及最大化的对各个子系统进行解耦

　　异步一定是根据业务特点来的，一定是针对业务的异步，通常适合异步的场合是一些松耦合的通信场合，而对于本身业务上关联度比较大的业务系统之间，还是要采用同步通信比较靠谱

　　六 非结构化数据存储 ( TFS,NOSQL)

　　不是所有的数据都是结构化的

　　比如一些配置文件，用户对应的动态，一次交易的快照等，一般不适合保存到RDBMS，更符合一种Key-value的结构

　　另一类数据，数据量非常大，但实时性要求不高，此时这些数据也需要通过另外的一种存储方式进行存储

　　一些静态文件，比如各个商品的图片，商品描述等信息，这些信息因为比较大，放入RDBMS会引起读取性能问题，影响其它数据读取性能，也要和其它信息分开存储，一般的选择分布式文件系统，

　　随 着互联网的发展，业界从08年 下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性3者 不能同时满足，最多只能同时满足两个

　　传统关系数据采用ACID事务策略，更加讲究高一致性而降低了可用性的需求，但是互联网应用往往对可用性的要求要略高于一致性的需求，这时候就要避免采用数据的ACID事务策略，转而采用BASE(基本可用性，事务软状态以及最终一致性)事务策略

　　通过最终一致性提升系统可用性，这也是目前很多NOSQL产品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，非常适合一些非结构化的数据，如key-value形式数据存储，并且这些产品有个很好的优点就是水平伸缩性

　　七 监控、预警系统

　　大型分布式系统涉及各种设备，比如网络交换机，普通PC机，各种型号的网卡，硬盘，内存等等，在数量非常多的时候，出现错误的概率也会变大，因此要时刻监控系统状态

　　监控有粒度的粗细之分

　　粒度粗一点，对整个应用系统进行监控，网络流量，内存利用率，IO，CPU负载，服务访问压力，服务的响应时间

　　细粒度一点，对应用中的某个功能，某个URL访问量，每个页面的PV，页面每天占用的带宽是多少，页面渲染时间，静态资源比如图片每天占用的带宽

　　有了监控系统以后，更重要的是要和预警系统结合起来，比如当某个页面访问量增多的时候，系统能自动预警，某台Server的CPU和内存占用率突然变大的时候，系统也能自动预警，当并发请求丢失严重的时候，系统也能自动预警等等，通过监控系统和预警系统的结合可以使得能快速响应系统出现的问题，提高系统的稳定性和可用性