`

京东活动系统--亿级流量架构应对之术

阅读更多

 

背景

 

京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动,并对外提供页面访问服务的系统。其高时效性、灵活性等特征,极受青睐,已发展成京东几个重要流量入口之一。近几次大促,系统所承载的pv已经达到数亿级。随着京东业务的高速发展,京东活动系统的压力会越来越大。急需要一个更高效,稳定的系统架构,来支持业务的高速发展。本文主要对活动页面浏览方面的性能,进行探讨。

 

活动页面浏览性能提升的难点:

1. 活动与活动之间差异很大,不像商品页有固定的模式。每个页面能抽取的公共部分有限,可复用性差。

2. 活动页面内容多样,业务繁多。依赖大量外部业务接口,数据很难做到闭环。外部接口的性能,以及稳定性,严重制约了活动页的渲染速度、稳定性。

 

经过多年在该系统下的开发实践,提出“页面渲染、浏览异步化”的思想,并以此为指导,对该系统进行架构升级改造。通过近几个月的运行,各方面性能都有显著提升。在分享"新架构"之前,先看看我们现有web系统的架构现状。

 

一、web架构发展与现状

1.开发阶段

以京东活动系统架构的演变为例,这里没有画出具体的业务逻辑,只是简单的描述下架构:

 

2.第二步,一般是在消耗性能的地方加缓存,这里对部分查库操作加redis缓存



 

 

3.对页面进行整页redis缓存:由于活动页面内容繁多,渲染一次页面的成本是很高。这里可以考虑把渲染好的活动内容整页缓存起来,下次请求到来时,如果缓存中有值,直接获取缓存返回。

 

 

以上是系统应用服务层面架构演进的,简单示意。为了减少应用服务器的压力,可以在应用服务器前面,加cdn和nginx的proxy_caxhe,降低回源率。

 

 


 

 

 

 

4.整体架构(老)

除了前3步讲的“浏览服务”,老架构还做了其他两个大的优化:“接口服务”、静态服务

 

 

 

 

1.访问请求,首先到达浏览服务,把整个页面框架返回给浏览器(有cdn、nginx、redis等各级缓存)。

2.对于实时数据(如秒杀)、个性化数据(如登陆、个人坐标),采用前端实时接口调用,前端接口服务。

3.静态服务:静态资源分离,所有静态js、css访问静态服务。

要点:浏览服务、接口服务分离。页面固定不变部分走浏览服务,实时变化、个性化采用前端接口服务实现。

 

接口服务:分两类,直接读redis缓存、调用外部接口。这里可以对直接读redis的接口采用nginx+lua进行优化( openresty ),不做详细讲解。 本次分享主要对“浏览服务”架构

 

二、新老架构性能对比

在讲新架构之前先看看新老架构下的新能对比

 

1.老架构浏览服务新能:

 

击穿cdn缓存、nginx缓存,回源到应用服务器的流量大约为20%-40%之间,这里的性能对比,只针对回源到应用服务器的部分。

2015双十一, 浏览方法tp99如下:(物理机)

 



 

Tp99  1000ms左右,且抖动幅度很大,内存使用近70%,cpu 45%左右。

1000ms内没有缓存,有阻塞甚至挂掉的风险。

 

2.新架构浏览服务新能

 

本次2016 618采用新架构支持,浏览tp99如下(分app端活动和pc端活动):



 



 

移动活动浏览tp99稳定在8ms, pc活动浏览tp99 稳定在15ms左右。全天几乎一条直线,没有性能抖动。

 

新架构支持,服务器(docker)cpu性能如下



 

cpu消耗一直平稳在1%,几乎没有抖动。

 

对比结果:新架构tp99从1000ms降低到 15ms,cpu消耗从45%降低到1%,新架构性能得到质的提升。

why!!!

 

下面我们就来揭开新架构的面纱。

三.新架构探索

1. 页面浏览,页面渲染 异步化



 

再来看之前的浏览服务架构,20%-40%的页面请求会重新渲染页面,渲染需要重新计算、查询、创建对象等导致 cpu、内存消耗增加,tp99性能下降。

 

如果能保证每次请求都能获取到redis整页缓存,这些性能问题就都不存在了。

即:页面浏览,与页面渲染 异步。

 

2.直接改造后的问题以及解决方案:



 

理想情况下,如果页面数据变动可以通过 手动触发渲染(页面发布新内容)、外部数据变化通过监听mq 自动触发渲染。

但是有些外部接口不支持mq、或者无法使用mq,比如活动页面置入的某个商品,这个商品名称变化。

 

为了解决这个问题,view工程每隔指定时间,向engine发起重新渲染请求-最新内容放入redis。下一次请求到来时即可获取到新内容。由于活动很多,也不能确定哪些活动在被访问,所以不建议使用timer。通过加一个缓存key来实现,处理逻辑如下:



 好处就是,只对有访问的活动定时重新发起渲染。

 

 

四、新架构讲解:

  整理架构(不包含业务):

  

  view工程职责

  a.直接从缓存或者硬盘中获取静态html返回,如果没有返回错误页面。(文件系统的存取性能比较低,超过   100ms级别,这里没有使用)

  b.根据缓存key2是否过期,判断是否向engine重新发起渲染。(如果,你的项目外面接口都支持mq,这个      功能就不需要了)

 

  engine工程职责:渲染活动页面,把结果放到 硬盘、redis。

 

  publish工程、mq 职责:页面发生变化,向engine重新发起渲染。 具体的页面逻辑,这里不做讲解

 


 

 

Engine工程的工作 就是当页面内容发生变化时,重新渲染页面,并将整页内容放到redis,或者推送到硬盘。

 

2.view工程架构(redis 版)




 
 

View工程的工作,就是根据链接从redis中获取页面内容返回。

 

 

3.view工程架构 (硬盘 版)

 




 
 

 

 

两个版本对比

a.Redis版

优点:接入简单、 性能好,尤其是在大量页面情况下,没有性能抖动 。单个docker tps达到 700。

缺点:严重依赖京东redis服务,如果redis服务出现问题,所有页面都无法访问。

 

b.硬盘版

优点:不依赖任何其他外部服务,只要应用服务不挂、网络正常 就可以对外稳定服务。

在页面数量不大的情况下,性能优越。单个docker tps达到 2000。

缺点:在页面数据量大的情况下(系统的所有活动页有xx个G左右),磁盘io消耗增加(这里采用的java io,如果采用nginx+lua,io消耗应该会控制在10%以内)。

解决方案:

a. 对所有页面访问和存储 采用url hash方式,所有页面均匀分配到各个应用服务器上。

b. 采用nginx+lua  利用nginx的异步io,代替java io。

 

 

4.Openresty+硬盘版

现在通过nginx+lua做应用服务,所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐。通过上述讲解,view工程没有任何业务逻辑。可以很轻易的就可以用lua实现,从redis或者硬盘获取页面,实现更高效的web服务。

 

通过测试对比,view工程读本地硬盘的速度,比读redis还要快(同一个页面,读redis是15ms,硬盘是8ms)。所以终极版架构我选择用硬盘,redis做备份,硬盘读不到时在读redis。



 

 

这里前置机的url hash是自己实现的逻辑,engine工程采用同样的规则推送到view服务器硬盘即可,具体逻辑这里不细讲。后面有时间再单独做一次分享。 

 

优点:具备硬盘版的全部优点,同时去掉tomcat,直接利用nginx高并发能力,以及io处理能力。各项性能、以及稳定性达到最优。

缺点:1、硬盘坏掉,影响访问。2.方法监控,以及日志打印,需使用lua脚本重写。

 

 

五:总结

无论是redis版、硬盘版、openresty+硬盘版,基础都是页面浏览与页面渲染异步化。



 

 

优势:

1、所有业务逻辑都剥离到engine工程,新view工程理论上永远无需上线。

2、灾备多样化(redis、硬盘、文件系统),且更加简单,外部接口或者服务出现问题后,切断engine工程渲染,不再更新redis和硬盘即可。

3、新view工程,与业务逻辑完全隔离,不依赖外部接口和服务,大促期间,即便外部接口出现新能问题,或者有外部服务挂掉,丝毫不影响view工程正常访问。

4、性能提升上百倍,从1000ms提升到10ms左右。详见前面的性能截图。

5、稳定性:只要view服务器的网络还正常,可以做到理论上用不挂机。

6、大幅度节省服务器资源,按此架构,4+20+30=54个docker足以支持10亿级pv。(4个nginx proxy_cache、20个view,30个engine)

 

 

六:结束语

 从事开发已有近10载,一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托,对活动系统新架构做了一次简单整理分享给大家,希望能给大家带来一丝帮助。第一次在网上做分享,难免有些没有考虑周全的地方,以后会慢慢的多分享一些自己的心得,大家一起成长。最后再来点心灵鸡汤。。。




 

转载请标明出处:

http://moon-walker.iteye.com/blog/2332314

  • 大小: 45.8 KB
  • 大小: 56 KB
  • 大小: 45.9 KB
  • 大小: 64.2 KB
  • 大小: 105.8 KB
  • 大小: 55.6 KB
  • 大小: 53.2 KB
  • 大小: 74.5 KB
  • 大小: 45 KB
  • 大小: 56.2 KB
  • 大小: 33.2 KB
  • 大小: 50.9 KB
  • 大小: 92.6 KB
  • 大小: 104.6 KB
  • 大小: 78.5 KB
  • 大小: 32.1 KB
  • 大小: 215.9 KB
  • 大小: 38.9 KB
  • 大小: 85.4 KB
  • 大小: 73.3 KB
  • 大小: 103.5 KB
分享到:
评论

相关推荐

    京东亿级流量海量数据搜索架构.pdf

    总的来说,京东的亿级流量海量数据搜索架构是一个复杂而高效的系统,它不断演进以适应快速增长的业务需求,通过分布式计算、实时索引、智能缓存策略和精细化的搜索逻辑,确保了在大规模数据下的快速、准确和个性化的...

    亿级流量网站架构核心技术-跟开涛学搭建高可用高并发系统

    #### 二、亿级流量架构的设计原则与实现策略 1. **水平扩展而非垂直扩展**:传统的垂直扩展方式(增加单台服务器的硬件配置)难以满足亿级流量的需求。相比之下,通过增加更多的服务器节点来实现水平扩展更为有效。...

    京东零售流量数仓架构建设

    京东零售流量数仓架构建设是京东在大数据处理领域的一个重要实践,它涵盖了用户在京东页面上的行为数据收集、处理和分析。流量数据来源于移动端、PC端、线下店、外部采买及合作商等多个渠道,通过SDK和JS等方式进行...

    架构师特刊.[京东-进击的618].InfoQ

    京东618是中国最大的电商促销活动之一,对于京东这样的电商平台来说,618期间所面临的流量激增和技术挑战是极为严峻的。在这篇文章中,京东的技术团队分享了他们如何应对这些挑战,尤其是在技术基础设施和人工智能...

    京东技术开放日第一期-京东数据中心网络服务如何支撑618大流量

    - 为了确保整个系统的稳定性和可靠性,京东建立了完善的监控体系,包括分钟级的流量监控、质量监控等。 - 监控系统不仅可以帮助快速定位问题,还能实时调整资源分配,确保服务正常运行。 #### 四、具体措施及优化...

    京东分布式K-V存储设计与挑战.pdf

    同时,为了应对业务快速增长,JIMDB支持在线扩容,通过监控分片内存占用大小和进出流量来触发扩容,确保资源利用率最大化。扩容过程中,JIMDB采用平滑扩容策略,提前通知客户端新的拓扑信息,避免服务中断。 FBASE...

    京东技术开放日第一期-电商海量订单处理OFC系统的关键技术环节

    京东作为中国知名的电子商务平台,每天都要处理海量的订单,其背后所依靠的订单处理系统是电商技术的重要组成部分。本文将围绕京东技术开放日所展示的OFC系统(订单履约中心)的关键技术环节,进行深入解析。 首先...

    京东王栋:618大促网关承载十亿调用量背后的架构实践

    在这篇文章中,京东的架构师王栋分享了618大促期间,面对十亿级别的调用量,如何设计和优化网关架构来承载如此巨大的流量和调用。这涉及到高并发架构的实战经验和对网关技术、技术栈的深入讲解。我们可以从中提取...

    亿级流量并发策略

    《亿级流量并发策略》这本书,出自京东资深架构师之手,是一本深入探讨如何应对大规模网站流量问题的专业著作。面对互联网行业中日益增长的流量挑战,这本书为读者提供了宝贵的实战经验和理论指导,旨在帮助程序员...

    京东技术架构归类.pdf

    随着业务的不断扩张,京东不断优化和升级技术架构,以应对日益增长的用户需求和流量挑战。同时,通过大规模招聘技术研发人员,京东也显示出对技术创新和系统能力提升的持续投入。这些举措确保了京东在电商领域的竞争...

    京东图片系统架构演进.pdf

    为了应对这种流量压力,京东采用了CDN(内容分发网络)和分布式文件系统JFS(京东文件系统)来优化存储和分发效率。 JFS是京东自研的分布式文件系统,它由协调节点(coordinator)、数据节点(datanode)和副本组...

    大数据架构-京东商城双十一技术实战

    京东商城在每年双十一期间都会面临巨大的访问和...通过这些综合性的技术策略和应对措施,京东商城的大数据架构得以应对大规模的订单处理、用户访问和数据处理需求,确保了双十一等促销活动期间的系统稳定性和用户体验。

    京东图片系统架构演进 .pdf

    京东图片系统架构的演进是随着京东业务的高速增长而不断迭代和优化的。在过去的几年里,京东集团的交易额持续攀升,相应的,其图片服务的规模也经历了显著的变化。从2013年至2017年,京东图片的数量和网络流量都呈现...

    京东全链路军演系统的架构设计和演进

    【京东全链路军演系统架构设计与演进】是京东在应对618和双十一等大型促销活动中,为了确保系统稳定性和高并发处理能力所采用的一种关键技术。该系统首次揭秘了全链路压测的技术细节,旨在通过模拟真实用户行为,...

    京东应用架构设计.pptx

    【京东应用架构设计】...在618大促等高峰期,京东的架构设计能有效地处理高并发流量,确保用户体验和系统的稳定运行。通过持续的优化和迭代,京东应用架构实现了在满足业务需求的同时,兼顾了效率、性能和成本的平衡。

    京东青龙系统架构篇PPT课件.pptx

    京东青龙系统是京东集团内部开发的一套先进的分布式服务架构,旨在提高系统的可扩展性、稳定性和效率。作为一套专业的课件,这份PPT详细介绍了青龙系统的关键设计和实现原理,涵盖了多个重要知识点,包括但不限于...

    京东应用架构设计

    本文将深入探讨京东应用架构的关键要素,包括分层架构、微服务化、分布式系统、缓存策略、数据库优化等多个方面。 一、分层架构 京东应用架构采用经典的分层设计,通常包括表现层(前端)、业务逻辑层(后端服务)...

    架构演进:京东应用架构设计.zip

    《架构演进:京东应用架构设计》是一...这份资料将深入解析这些技术细节,帮助读者理解京东如何通过不断的技术创新和架构演进来应对商业挑战,对于从事或学习互联网架构设计的专业人士来说,是一份极具价值的学习材料。

Global site tag (gtag.js) - Google Analytics