背景
京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动，并对外提供页面访问服务的系统。其高时效性、灵活性等特征，极受青睐，已发展成京东几个重要流量入口之一。近几次大促，系统所承载的 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 服务。如果想学习 Java 工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty 源码的朋友可以加我的 Java 进阶 qun：694549689，里面有阿里大牛直播讲解技术，以及 Java 大型互联网技术的视频免费分享给大家。
1. 具有 1-5 工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。
2. 在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3. 如果没有工作经验，但基础非常扎实，对 java 工作机制，常用设计思想，常用 java 开发框架掌握熟练的可以加。
通过测试对比，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 载，一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托，对活动系统新架构做了一次简单整理分享给大家，希望能给大家带来一丝帮助。第一次在网上做分享，难免有些没有考虑周全的地方，以后会慢慢的多分享一些自己的心得，大家一起成长。最后再来点心灵鸡汤。。。
The post 京东活动系统– 亿级流量架构应对之术 appeared first on Linuxeden开源社区.
http://ift.tt/2DHaNaT
没有评论:
发表评论