《天猫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，已开源

本文出自 “似水流年” 博客，请务必保留此出处http://lonely7345.blog.51cto.com/5605849/1428105