《天猫2013双十一架构》读后笔记

网购狂欢节背后的技术阅兵

     稳定性的极致要求

    1. 容量预估、依赖治理、监控

    2. 业务降级、限流预案

    3. 全链路压测
 

 

天猫篇

 

（1）双11的前端实践

    1. 淘宝的前台资源采用的都是非覆盖式发布，经过语义化路径定位，这样先后台能够分开发布，还能独立回滚

    2. 全站采用统一的kissy,MUI,经过配置文件按需加载组件，而且先后端自动实现一致的依赖关系等。
 

    3. 淘宝的左侧工具栏采用了插件机制，分开的源代码管理，能够单独部署，而且支持热插拔
 

    4. 淘宝有降级预案和限流预案，降级预案包括前观的页面的一些必须的功能以及json等请求
 

    5. 自动化测试，可以自动生成测试用例，进行上线前检测，上线后质量实时监控，猫须基于nodejs+express架构开发，支持多浏览器，包括phantomjs ,得益于Selenium Webdriver.

    6. 实时到秒的发布计划和实时发布。 另外，对于有些秒级业务，提早发布，后端代码判断时间来切换显示。前端还须要经过js代码判断时间刷新，后端代码和前端js都须要去服务器校对时间

 

（2）天猫浏览型应用的CDN静态化架构演变

      1. 2012阶段曾采用动态内容作CSI填充。http://www.cnblogs.com/wbinblog/archive/2012/05/16/2503528.html

          从页面中抽取出不依赖用户，时间，地域，cookie这些维度，而且不常常变化的部分，生成URL固定的页面。

         好比：商品页面，标题，商品详情，销售属性组合直接缓存，优惠，库存，物流，服务动态填充。

      2. 主动失效机制：当触发源发生变化时，发送消息给失效服务，失效服务主动失效对应内容。这个时间用户访问时会发现缓存已经不存在，去主动更新缓存，确实把Java系统转变成弱依赖。

      

 

     3.  统一缓存接入，解决单机缓存受内存大小制约

           

 

       4.最终目的，CDN静态化。  

           将静态页面放在CDN上，放置在离用户最近的节点上！流量集中区域，控制节点的数量，内部再经过一致性hash规则。

           静态化应用对应的域名解析到CDN和统一接入层虚拟IP上，这样CDN拿到资源后先读取本地缓存，缓存不命中的话，去统一接入层获取。这时候统一接入层 按照按照原有的规则（上面所描述)获取数据，缓存不命中则回到服务器端获取数据，这个时候统一接入层Web服务器须要可以识别用户请求是CDN回源类型还 是正常请求，以避免重复压缩和日志记录。

         

       5. 这种缓存体系缓存了静态页面，而且使整个架构对应用系统弱依赖。使用的tair开源地址：https://github.com/alibaba/tair

 

支付宝篇

 

（1）支付宝的架构变迁

 

   1. 支付宝除了按业务类型垂直拆分外，还应该按客户进行了数据的水平拆分。数据在主交易数据库集群生成，再经过数据复制中心复制到其余两个数据库集群。另外主交易数据库集群包括完整的备份和failver库。

       

     2.支付宝研发了中间件产品Zdal  https://github.com/qingyeqing/zdal

     3. 支付宝为了保障事务的可靠性，对2pc进行了改进，基于TCC型事务，没有了prepare阶段。每一个业务都进行try操做，完成后保留现场，全部的try完成后，再找回现场commit，若有失败找回现场进行本地cancel.

    

        4.支付宝对服务也作了依赖控制，最强，强，弱，最弱，在降级时使用。在代码中注解来标注，而后经过zookeeper实现统一配置，配置发生变化后，会把变化的值推送给订阅的客户端。

配置资源包括了流量控制、应用层参数、数据节点。

       5.支付内部监控方案xflush,对监控数据作增量计算，而且对上层提供二次开发接口，而且有实时日志分析平台，架构图见下图。

       6. 一次完整的自动化调度流程见下图。弹性平台的分析 ，支付宝是使用groovy编写分析脚本进行的。对于产生控制指令，对于有些状况就中止在这一步，交给人工审核执行。

       7.支付宝天天的发布的流程： 集成测试环境＝》预发布环境 ＝》 beta集群（对于A集群，发布时先切1%流量，没问题再切10%,直到切完）＝》所有没问题再发布剩余集群

       8.支付宝的SOFA框架，面向模块化和组件模型，组件直接采用spring(IOC),模块化借鉴spring-DM，业务模块Spring上下文隔离，不一样模块之间的组件(bean)不可见，减小耦合。

       9.经过扩展spring scheme extensions扩展，定义组件之间的关系。组件和组件之间的依赖经过服务发布/引用模型，组件和组件集成关系经过扩展/扩展点模型，组件和组件发布订阅关系经过消息topic的发布订阅模型。

     10. sofainsight经过java agent技术动态挂载到应用的ivm进程上，把监控信息发送到分析平台，客户端经过jmx监控线程池，链接池等。还经过aspectjs动态搭载请求从入到出的全调用链路耗时。

      11.zdal的核心架构图

 

中间件篇

 

（1）中间件技术的双11实践

    1. 阿里如今大量使用软负载，经过软件系统解决请求的均衡负载，相对于F5,LVS。软负载特色：无中心化，成本低，效率高，功能强。

    2.ConfigServer不须要master,内部实现了节点间数据增量同步的功能。数据变化后将数据推送到订阅客户端 ，并且客户端本地也作了本地容灾文件，ConfigServer不可用时，会优先使用本地内存中的数据，从新启动也可先依赖本地的容灾文件。

   3.感受支付宝的Notiry也和kafka相似，都是消息先落盘,  但他也支持选择成使用内存存储。

   4. EagleEye鹰眼系统很牛，把调用链全都进行了统计分析，在进来的时候生成了一个traceid,而后跟随整个过程，能够用于发现问题，评估。

   5.TDDL的流程

  

  

 

 

运维保障篇

 

（1）双11数据库技术

1.评估：经过鹰眼系统，监控调用量关系，和数据库的qps来估算数据库的容量。从上而下来作。考虑Cache命中率以及须要考虑Cache宕机状况。直接经过模拟真实业务来评估单机承载量。

2. 数据库扩容

    第一种是读写分离，添加从库  第二种是水平扩容， 利用分库规则进行细化，将数据从新拆分到更多台服务器上 ，阿里研发了dbree,自动化完成。

3. 预案： 降级和限流

4.阿里的mysql分支alimysql,并行复制。并发控制，自我保护。

 

---

kafka在惟品会的应用 

1 .主要用来日志传输，基本保持25w/s的producer性能，consumer吞吐量  55w/s.  RabbitMQ相比这下差很远。

2 .每一个kafka集群有多个broker，每一个broker有多个topic，每一个topic都会有多个partition.每一个partitioin只 能被一个consumer消费，consumer消费的是topic，具体消费哪一个partition由kafka的分配算法决定，能够多个 consumer组成consumer  group消费同一个topic，Kafka保证他们不消费同一份数据.producer在发送消息时，会负载写到同一个topic不一样的 partition中。

3.  Kafka server有本身的编号，【server编号】_【topic名称】_【自增编号】组成partition编号，好比0_topic1_1表示编号为0 的server上的topic1下面的编号为1的partition。一个partition就是一个文件.

4. Kafka利用了磁盘的顺序读写，磁盘的顺序读写速度快于内存的随机读写速度，并且Linux系统对磁盘读写作了优化和缓存，重启后还能用，若是使用内存存储，须要jvm作gc.

5. 每一个消息在Kafka中都有一个offset，consumer消费到了那条消息经过offset记录，能够配置成同步offset到zookeeper中。这样当消费系统或者消息系统出问题时能够找到offeset回复，由于消息存在磁盘上也没丢.

6. Kafka的数据压缩和解压是producer和consumer本身作的

7.kafka没有ack机制，由consumer本身维护

8. Kafka经过zookeeper维护broker可用列表

9. Kafka集群中网卡可能会先于磁盘出现瓶颈，可考虑双网卡

10. Kafka能够直接热扩容，直接添加server

11. 日志收集使用flume，他们开发了针对Kafka的插件flume-Kafka，已开源