亿级流量架构之 页面浏览、渲染异步化

标签: 流量 架构 页面 | 发表时间:2016-10-24 18:53 | 作者:moon_walker
出处:http://www.iteye.com

 

背景

 

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

 

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

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双十一pv 2.6亿 。 浏览方法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



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [流量 架构 页面] 推荐:

亿级流量架构之 页面浏览、渲染异步化

- - 互联网 - ITeye博客
京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动,并对外提供页面访问服务的系统. 其高时效性、灵活性等特征,极受青睐,已发展成京东几个重要流量入口之一. 近几次大促,系统所承载的pv已经突破2亿. 随着京东业务的高速发展,京东活动系统的压力会越来越大. 急需要一个更高效,稳定的系统架构,来支持业务的高速发展.

大流量、高并发的网站的底层系统架构

- - 企业架构 - ITeye博客
大流量、高并发的网站的底层系统架构. [转载自] http://www.webjx.com/webmanage/experience-25319.html. 动态应用,是相对于网站静态内容而言, 是指以c/c++、php、Java、perl、.net等 服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用.

页面架构HTML+CSS ●▽● 各种布局各种实现

- - SegmentFault 最新的文章
(1)清除浏览器默认样式. (1)项目开发初期就定义好. (2) reset.css 在引入的时候一定要放在第一位. (3)不同的产品 reset.css不一样. 3.table合并边框间距. table { border-collapse: collapse; // 合并边框 border-spacing: 0; //边框间距.

历经16年猪八戒网如何成功实现双活流量架构

- - DockOne.io
猪八戒网随着业务访问量的直线增长,用户增长达到一定规模后,同时面临着高并发业务和海量数据的挑战,传统单机房在服务器容量上存在瓶颈,而且在一些不可预知场景下,导致整个网站出现故障,例如机房断电、火灾等这些不可抗拒因素都会导致所有服务器出现宕机从而导致业务瘫痪,即使有备份,恢复业务花费的时间也比较长. 所以公司根据实际业务情况选择了同城双活流量高可用架构,当然还有两地三中心、异地多活等方案.

Tumblr架构 – 页面浏览量150亿/月并且比Twitter更难拓展

- - 龙浩的blog
    注:一些内容不熟悉,所以没有翻译.     Tumblr每个月增长30% , 一天5亿网页浏览,40K/sec , 每天3TB的数据存储在1000+的服务器上. 最开始只有4名工程师来处理所有事情,当有20多个工程师的时候,才有实力出一些有趣的解决方案.     Tumblr最开始是典型的大型LAMP应用,现在的分布式服务模型使用了Scala, HBase, Redis, Kafka , Finagle等,现在在处理PHP应用的问题,开始走向面向服务的设计.

架构

- - IT瘾-dev
网关:Nginx、Kong、Zuul. 缓存:Redis、MemCached、OsCache、EhCache. 搜索:ElasticSearch、Solr. 熔断:Hystrix、resilience4j. 负载均衡:DNS、F5、LVS、Nginx、OpenResty、HAproxy. 注册中心:Eureka、Zookeeper、Redis、Etcd、Consul.

超3亿活跃用户的多活架构,数据同步与流量调度怎么做? - 架构 - dbaplus社群:围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙。

- -
1、OPPO多活架构原则   . 多活成本比较高的,双活是两倍,三活可能成本会低一些,但三活的难度更大. 因此没有办法对所有业务进行多活,只能对主线做多活. 举个例子,系统有个充值的功能,充值功能本身是强一致的,完全不能允许任何的延迟或者是副本的读. 但是多活切换之后,只有少数用户在切换的前几分钟有充值的,这部分用户余额可能没有通过过去,只需要对这部分用户进行服务降级,其他绝大多数用户是可以使用完整的服务的.

流量生意

- flypen - 张磊的blog
前些日子网上盛传某联盟的按月分成数据,其中番茄花园、雨木林风的分成都高达百万. 有人惊呼:原来做盗版软件这么赚钱. 也有人质疑:他们怎么可能赚这么多钱. 他们确实很赚钱,简单说,这就是流量生意. 为什么几乎每个巨头都有一个“网站联盟”. 为什么Google当年愿意付费推广Firefox. 为什么,推广Firefox、自己做Chrome的同时,把微软当作对手的Google还特意提供“优化的Internet Explorer”.

信息架构

- Michael - Tony-懒得设计
写几篇关于信息架构的文章,系统地输出我理解的信息架构. 发了一篇关于招信息架构实习生的博客,收到不少简历. 但谈起信息架构,多数不了解,稍微了解的扯了很多很偏的东西. 随手搜索了一下,我发现了原因:. 1 《web信息架构》这本书太概念,太学术. 2 有人绑架了“信息架构”这个词,拿出去唬人,内容都是皮毛或者是根本和信息架构不沾边的东西.