1199亿成交额！京东618大捷幕后技术功臣揭秘

《1199亿成交额！京东618大捷幕后技术功臣揭秘》要点：
本文介绍了1199亿成交额！京东618大捷幕后技术功臣揭秘，希望对您有用。如果有疑问，可以联系我们。

6月19日消息: 1199亿元,是京东6·18全民年中购物节从6月1日开始,截止6月18日24点累计下来的总下单金额.而就在2016年天猫双十一购物节的总交易额是1207亿元.这两者的数值已经非常接近了.

京东6.18的成绩单&&黑科技

6月18日凌晨一点多,京东CEO刘强东通过微信朋友圈发了一条信息：“今年618的第一个小时的销售额同比去年增长250%多!小小激动一把!”

1199亿元,是京东6·18全民年中购物节从6月1日开始,截止6月18日24点累计下来的总下单金额.

而在当日,京东的黑科技发布却让我们瞠目结舌.6月18日,京东无人送货机器人在中国人民大学、清华大学、浙江大学、长安大学、中国传媒大学和北京科技大学园区正式开始启用,这或许意味着无人化服务的开始.

从京东发布无人送货机器人这个角度来看,京东在IT信息系统的研发的投入非常巨大,京东的IT信息系统的复杂与庞大也是毋庸置疑的.

在这么大的公司中,这么多不同架构的IT业务同时运行.一旦出现问题,是得有多么恐怖啊?万一出现问题怎么办?

技术先行,数据说话,ForceBot压测实践得真知

在6.18之前,技术保障团队最担心的问题是环环相扣的各个核心系统,尤其是强依赖,上下游关系紧密结合的系统出现瓶颈的问题.这会影响整个系统链路的处理性能,直接影响用户购物体验.从而导致订单量下降,成交量下降的情况.

更重要的一个问题是各系统容量规划数据不精准问题.每次大促前备战会必不可少的讨论话题就是服务器资源申请扩容问题,各团队基本都是依据往年经验和线上资源使用率给出评估量,提出一个扩容量需求,导致各个业务系统每次促销扩容量非常大数据不精准.

为了解决以上各种苦恼,2016年基础平台部整体牵头启动了 ForceBot 全链路压测(模拟备战常态化)这个项目.

此项目牵扯到所有京东研发体系团队,各系统必须改造识别压测过来的流量和线上正式流量进行区分标记特殊处理,不能因为压测流量影响正常用户体验和污染线上数据等工作,由于跨团队协作之多、跨系统协调改造等工作量非常大,挑战性可想而知!

京东ForceBot设计与架构揭秘

设计目标

2016年主要实现了订单前的所有黄金链路流程高并发压测用户行为模拟,包括模拟用户操作：首页、登陆、搜索、列表、频道、产品详情、购物车、结算页、京东支付等.

在黄金链路中有各种用户行为场景,比如一般用户首先访问首页,在首页搜索想要产品,翻页浏览,加入购物车、凑单、修改收货地址、选择自提等等.

各系统压测量依据往年双11峰值作为基础量,在此基础上动态增加并发压力；同时要区分对待两个大的场景,日常流量和大促流量.

大促场景下抢购活动集中,交易中心写库压力最大,另外用户行为和日常有很大的反差,比如用户会提前加入购物车,选择满减凑单,集中下单等等场景.

2016年启用的链路较短,在2017年将实现订单后生产的全链路.

设计实现价值

ForceBot 在2016年双11替代往年各系统独自优化、性能压测备战状态,目前所有的备战数据和各系统性能承载能力、资源规划等都由 ForceBot 给出直接数据作为依据,在军演压测过程中,秒级监控到压测源、压测中、京东所有的黄金链路系统、接口响应时间、TPS、TP99 等数据,军演完成后提供丰富的压测报告,准确的找到各系统并发瓶颈.

同时也承担了内网单一系统的日常压测任务,开放给研发和压测团队,支撑京东所有的压测场景统一压测平台,对公司内压测资源的整合和提高利用率.

设计ForceBot架构

新平台在原有功能的基础上,进行了功能模块的解耦,铲除系统瓶颈,便于支持横向扩展.

• 对 controller 功能进行了拆解,职责变为单一的任务分配；
• 由 task service 负责任务下发,支持横向扩展；
• 由 agent 注册心跳、拉取任务、执行任务；
• 由 monitor service 接受并转发压测数据给 JMQ；
• 由 dataflow 对压测数据做流式计算,将计算结果保存在 db 中；
• 由 git 来保存压测脚本和类库.GIT 支持分布式,增量更新和压缩

这样极大的减轻了 controller 的负载压力,并且提升了压测数据的计算能力,还可以获取更多维度的性能指标.

改造业务系统

1. 黄金流程业务

   首期识别从用户浏览到下单成功的黄金流程,其包含的核心业务如下：

1. 压测流量识别

   压测流量是模拟真实用户行为,要保障在军演过程中不能污染线上各种统计等数据,比如：PV UV 订单量等,更不能影响正常用户下单购物体验.

   首先要对用户、商品进行打标,以便于各个系统进行测试流量识别.针对下单压测,库存系统需要根据测试用户和商品提前准备好库存量.风控系统需要放行测试用户和商品的操作.

2. 压测数据存储

   业务系统识别出压测数据后,根据不同的场景,采用两种方式来存放压测数据.

• 打标数据并存储到生产库中,压测的数据能体现生产环境性能.定期清理测试数据.统计报表要过滤掉测试数据.改方案能利用现有资源,需要系统进行较多改造.
• 构造压测库环境,根据压测流量,把压测数据存放到压测库中进行隔离.改方案需要较多的资源,但系统改造量小.

  支付系统最大的改造困难就是银行接口的强依赖,不能用真实的银行卡扣款和支付, ForceBot 的目标不是压银行接口,而是压自己本身的支付系统.

  所以京东这边支付团队目前是自己造了一个假银行,假接口,通过前端传递过来的压测标识,自动路由到假银行进行扣款支付；

测试是保障和检验能力的最佳的方法,通过模拟测试,反馈出现有的技术问题.

原文来自微信公众号：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/2398.html