作者:陈保安,2011年加入京东,目前主要负责手机京东核心业务(搜索、商品、购物车、结算、收银台、我的京东)的后端研发工作。带领团队在一线奋战多年,积累了非常丰富的大促备战经验,也见证了核心系统从一分钟几千单到几十万单的质的蜕变。 京东手机单品页在每次大促时承载所有流量的入口,它被天然赋予的一个标签就是抗压,对系统的稳定性、性能方面要求极其苛刻,另外单品页本身业务复杂度较高,单品页有几十种垂直流程业务,并且展示上都要求个性化的单品页,加上依赖有50+的基础服务,稍有抖动,对整体服务质量都会有比较大的影响,因此之前大促也出现过各种问题,不断打磨,持续优化升级,当前系统架构可支撑接近百万的QPS瞬时访问,并且今年双11表现非常平稳,借此机会一块和大家做一次分享。 一、先聊聊APP接口开发的特点 1、 手机网络、流量受限
2、 手机不同分辨率、网络环境、系统版本的适配
3、 APP版本兼容
因此APP的接口开发逻辑复杂度和后续的维护成本被放大很多。 二、单品页业务系统架构
这是当前单品页系统的整体架构图,其他的核心交易流程,比如购物车、下单等也都基本类似,单品页系统主要有三个进程:OpenResty、Tracer-Collect、Tomcat,以及包含几个旁路系统。OpenResty是nginx层的web容器,主要职责是做静态化和限流防刷,只有经过清洗过的流量才会流转到tomcat的java进程真正的业务处理,Tracer-Collect进程是通过旁路的方式异步埋点到统一的监控平台,进行实时的数据分析。 三、核心技术点 1、 OpenResty这个是在今年618之前架构上做的一个变化,主要有以下几点考虑:
使用规范上
Lua语言对于很多团队都使用过程中都遇到各种问题,今年双11的总结会上也有团队分享大促期间lua死锁问题,我们这里遇到的一个场景是zk的配置数据同步到lua时一定概率出现死锁。 原因:lua运行在nginx主线程中,但zk在nginx主线程外启动新的线程watch,当zk更新时通过这个新线程通知数据更新,这时我们在这个新的线程中直接调用lua代码,会有概率产生死锁。 解决方案:在这个新线程中不直接调用lua代码,而是通过http协议直接进入nginx主线程更新配置数据。 2、 数据静态化单品页给APP提供的API重点包含两个,一个是静态接口,一个是动态接口数据,这里提到的静态化重点是针对静态接口数据,包含商品图片、基本信息、店铺商家信息、颜色尺码、延保…..等,去年双11期间,由于一些热点商品访问量过大,对jimdb集群单个分片的连接数和操作数都非常高,服务压力过大,整体集群服务性能变差,因此针对此进行了三级热点的优化:
3、 数据异构,减少强依赖数据异构带来的好处是可以减少一些基础服务的强依赖,之前老板提的一个目标就是基础服务挂了,上层业务还能很好的活着,但是京东这个数据体量来看成本是非常巨大的,因此APP单品页选择部分数据异构,减少基础服务接口的强依赖,主要是商品的基础数据、扩展属性信息、商品的详情数据,全量数据同步一次之后通过中间件JMQ进行增量的数据同步变更,存储使用的是缓存中间件jimdb(redis缓存)。 4、 并发请求异步化APP单品页前期属于野蛮发展,很多RPC的依赖极其不合理,比如依赖关系没有层次概念,超时时间设置超长、内外网接口同时依赖,造成任何的服务质量变差和网络抖动对整体API影响非常大,因此进行了一次SOA化改造,主要工作是把单品页系统从大网关分离出来,然后制定服务接入标准并进行改造,第三方面就是上游基础服务调用并行化,系统整体并发能力及稳定性得到了极大的提升。 服务依赖的标准
随着流量不断增加,并行化遇到了瓶颈,每次请求会创建大量的线程,线程的维护和上下文切换成本本身比较消耗CPU资源,因此基于现有HttpClient和JSF基础组件的异步化支持,进一步进行异步化的改造,单机压测效果还是比较明显,并发能力提升40%。 5、 监控系统流量到一定程度,系统的各维度监控尤为重要,可以帮助我们缩短排查、定位问题的时间,甚至可以帮助预警风险,当前APP业务从用户到后端整个服务链条的监控都已经非常完善,包括各运营商入口流量的监控、内外部网络质量、负载均衡、以及网关流量的监控以外,我重点介绍下单品页业务层的监控,下边是业务监控系统数据异步埋点的架构,主要分为两类数据,第一业务指标数据比如单品页各渠道访问数据,通过UDP协议实时埋点到Kafka,然后storm实时在线分析形成最终需要的数据落地,另一类是大流量数据,比如系统异常信息落到磁盘日志中,然后通过logCollector异步发送到Kafka中,这类数据对磁盘IO、网卡IO的流量占比大,针对磁盘IO,会按照文件大小100M滚动生成日志文件,数据搬走之后进行删除操作,网卡IO在数据传输过程中进行了限速,按照1m/s的速度进行传输,可进行动态调整,基本对业务不产生任何影响,大促峰值期间会针对一定比例降级。
业务系统除了基本的服务器各项指标CPU、MEM监控,服务的性能、可用率监控以外,介绍几个比较实用的业务能力监控:
监控细节还有很多,以上几个监控手段对当前业务系统帮助非常大也是非常实用的一些能力,现在业务系统已经做到非常透明,任何人都可以清晰看到系统的健康度,并且部分服务具备通过故障自动容错的能力,对系统整体的稳定性提供了非常大的保障。 6、 限流手段京东APP上所有商品价格库存都是分区域的,因此很多刷子以及爬虫不断的来爬京东各区域的价格、库存和促销信息等,有一个很明显的特征就是大量刷子刷时用户登录态的占比会明显下降,因此单品页针对用户的行为实时行为数据进行分析和控制:
7、 压测单品页压测比较麻烦,一方面压测的流量大,对线上可能会造成很多不可预知的问题,另一方面涉及的基础服务比较多,牵涉的人就多,每次压测要协调上下游几十号人支持,协调成本比较高,第三方面压测的商品数量都在上百万的商品,每次压测的SKU会变更,脚本变更比较大,第四每次压测完成之后需要人工形成压测报告并分析其中的薄弱环节问题,因此APP端产出了一个自己的压测平台,通过流程方面来协助解决以上几个问题:
压测数据准备方面:
四、未来方向 单品页还有很大的一些优化空间,比如为适应快速的业务迭代进行系统重构、jvm垃圾收回策略和堆内存分配大小的调整、异步化的改造等等优化正在进行,未来单品页最重要的几个方向:
|
|