构建亿级前端读服务

标签: 架构 | 发表时间:2015-08-02 22:13 | 作者:张开涛
出处:http://ifeve.com

作者:张开涛

从入职京东到现在,做读服务已经一年多的时间了,经历了各种亿级到百亿级的读服务;这段时间也进行了一些新的读服务架构尝试,从架构到代码的编写,各个环节都进行了反复尝试,压测并进行调优,希望得到一个自己满意的读服务架构。

一些设计原则

  • 无状态
  • 数据闭环
  • 缓存银弹
  • 并发化
  • 降级开关
  • 限流
  • 切流量
  • 其他

无状态

如果设计的应用是无状态的,那么应用就可以水平扩展,当然实际生产环境可能是这样子的: 应用无状态,配置文件有状态。比如不同的机房需要读取不同的数据源,此时就需要通过配置文件指定。

数据闭环

如果依赖的数据来源特别多,此时就可以考虑使用数据闭环,基本步骤:

1、数据异构:通过如MQ机制接收数据变更,然后原子化存储到合适的存储引擎,如redis或持久化KV存储;

2、数据聚合:这步是可选的,数据异构的目的是把数据从多个数据源拿过来,数据聚合目的是把这些数据做个聚合,这样前端就可以一个调用拿到所有数据,此步骤一般存储到KV存储中;

3、前端展示:前端通过一次或少量几次调用拿到所需要的数据。

这种方式的好处就是数据的闭环,任何依赖系统出问题了,还是能正常工作,只是更新会有积压,但是不影响前端展示。

另外此处如果一次需要多个数据,可以考虑使用Hash Tag机制将相关的数据聚合到一个实例,如在展示商品详情页时需要:商品基本信息:p:123:, 商品规格参数:d:123:,此时就可以使用冒号中间的123作为数据分片key,这样相同id的商品相关数据就在一个实例。

 

缓存银弹

缓存对于读服务来说可谓抗流量的银弹。

浏览器端缓存

设置请求的过期时间,如响应头Expires、Cache-control进行控制。这种机制适用于如对实时性不太敏感的数据,如商品详情页框架、商家评分、评价、广告词等;但对于如价格、库存等实时要求比较高的,就不能做浏览器端缓存。

CDN缓存

有些页面/活动页/图片等服务可以考虑将页面/活动页/图片推送到离用户最近的CDN节点让用户能在离他最近的节点找到想要的数据。一般有两种机制:推送机制(当内容变更后主动推送到CDN边缘节点),拉取机制(先访问边缘节点,当没有内容时回源到源服务器拿到内容并存储到节点上),两种方式各有利弊。 使用CDN时要考虑URL的设计,比如URL中不能有随机数,否则每次都穿透CDN,回源到源服务器,相当于CDN没有任何效果。对于爬虫可以返回过期数据而选择不回源。

接入层缓存

对于没有CDN缓存的应用来说,可以考虑使用如Nginx搭建一层接入层,该接入层可以考虑如下机制实现:

1、URL重写:将URL按照指定的顺序或者格式重写,去除随机数;

2、一致性哈希:按照指定的参数(如分类/商品编号)做一致性Hash,从而保证相同数据落到一台服务器上;

3、proxy_cache:使用内存级/SSD级代理缓存来缓存内容;

4、proxy_cache_lock:使用lock机制,将多个回源合并为一个,减少回源量,并设置相应的lock超时时间;

5、shared_dict:此处如果架构使用了nginx+lua实现,可以考虑使用lua shared_dict进行cache,最大的好处就是reload缓存不丢失。

此处要注意,对于托底/异常数据不应该让其缓存,否则用户会在很长一段时间看到这些数据。

应用层缓存

如我们使用Tomcat时可以使用堆内缓存/堆外缓存,堆内缓存的最大问题就是重启时内存中的缓存丢失,如果此时流量风暴来临可能冲垮应用;还可以考虑使用local redis cache来代替堆外内存;或者在接入层使用shared_dict来将缓存前置,减少风暴。

分布式缓存

一种机制就是废弃分布式缓存,改成应用local redis cache,即在应用所在服务器中部署一个redis,然后使用主从机制同步数据。如果数据量不大这种架构是最优的;如果数据量太大,单服务器存储不了,还可以考虑分片机制将流量分散到多台;或者直接就是分布式缓存实现。常见的分片规则就是一致性哈希了。


如上图就是我们一个应用的架构:

1、首先接入层读取本地proxy cache / local cache;

2、如果不命中,会读取分布式redis集群;

3、如果还不命中,会回源到tomcat,然后读取堆内cache;如果没有,则直接调用依赖业务获取数据;然后异步化写到redis集群;

因为我们使用了nginx+lua,第二、三步可以使用lua-resty-lock非阻塞锁减少峰值时的回源量;如果你的服务是用户维度的,这种非阻塞锁不会有什么大作用。

并发化

假设一个读服务是需要如下数据:

1、数据A  10ms

2、数据B  15ms

3、数据C   20ms

4、数据D   5ms

5、数据E   10ms

那么如果串行获取那么需要:60ms;

而如果数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C;那么我们可以这样子来获取数据:

那么如果并发化获取那么需要:30ms;能提升一倍的性能。

假设数据E还依赖数据F(5ms),而数据F是在数据E服务中获取的,此时就可以考虑在此服务中在取数据A/B/D时预取数据F,那么整体性能就变为了:25ms。

降级开关

对于一个读服务,很重要的一个设计就是降级开关,在设计降级开关时主要如下思路:

1、开关集中化管理:通过推送机制把开关推送到各个应用;

2、可降级的多级读服务:比如只读本地缓存、只读分布式缓存、或者只读一个默认的降级数据;

3、开关前置化:如架构是nginx—>tomcat,可以将开关前置到nginx接入层,在nginx层做开关,请求不打到后端应用。

限流

目的是防止恶意流量,恶意攻击,可以考虑如下思路:

1、恶意流量只访问cache;

2、对于穿透到后端应用的可以考虑使用nginx的limit模块处理;

3、对于恶意ip可以使用如nginx deny进行屏蔽。

大部分时候是不进行接入层限流的,而是限制流量穿透到后端薄弱的应用层。

切流量

对于一个大型应用,切流量是非常重要的,比如多机房有机房挂了、或者有机架挂了、或者有服务器挂了等都需要切流量,可以使用如下手段进行切换:

1、DNS:切换机房入口;

2、LVS/HaProxy:切换故障的nginx接入层;

3、Nginx:切换故障的应用层;

另外我们有些应用为了更方便切换,还可以在nginx接入层做切换,通过nginx进行一些流量切换,而没有通过如LVS/HaProxy做切换。

其他

不需要cookie的应用使用无状态域名,如3.cn;

接入层请求头过滤,只转发有用的请求头到后端应用;

数据过滤逻辑前置,比如在接入层进行请求参数的合法性过滤;

内网设置合理的连接、读、写超时时间;

根据需要开启gzip压缩减少流量;

使用unix domain socket减少本机连接数;

内网考虑使用http长连接;

响应请求时,考虑响应头加上服务器ip等信息,方便调试。

 

我们处理的读服务大部分都是KV的,因此抗流量的思路就是大量缓存;而且怎么让缓存怎么更接近用户,离用户越近速度就越快。再一个点就是要考虑好降级方案,在异常情况下应用不被拖垮拖死。我们系统大量使用了如nginx+lua+redis技术,使用这些技术解决了我们很多读服务问题。

原文来自 http://jinnianshilongnian.iteye.com/blog/2232271

相关 [前端 服务] 推荐:

构建亿级前端读服务

- - 并发编程网 - ifeve.com
从入职京东到现在,做读服务已经一年多的时间了,经历了各种亿级到百亿级的读服务;这段时间也进行了一些新的读服务架构尝试,从架构到代码的编写,各个环节都进行了反复尝试,压测并进行调优,希望得到一个自己满意的读服务架构. 如果设计的应用是无状态的,那么应用就可以水平扩展,当然实际生产环境可能是这样子的: 应用无状态,配置文件有状态.

使用 Nginx 构建前端日志统计服务

- - SegmentFault 最新的文章
之前的几篇文章都是关于之前提到的 低代码平台的. 这个大的项目以 low code 为核心,囊括了编辑器前端、编辑器后端、C 端 H5、组件库、组件平台、后台管理系统前端、后台管理系统后台、统计服务、自研 CLI 九大系统. 今天就来说一下其中的 统计服务:目的主要是为了实现 H5 页面的分渠道统计(其实不仅仅是分渠道统计,核心是想做一个自定义事件统计服务,只是目前有分渠道统计的需求),查看每个渠道具体的 PV 情况.

安装淘宝开源web服务器tengine替换nginx并使用proxy_cache做前端代理

- - C1G军火库
Tengine是由淘宝网发起的Web服务器项目. 它在Nginx的基础上,针对大访问量网站的需求,添加了很多高级功能和特性. Tengine的性能和稳定性已经在大型的网站如淘宝网,天猫商城等得到了很好的检验. 它的最终目标是打造一个高效、稳定、安全、易用的Web平台. 目前稳定版[2013-11-22] Tengine-1.5.2.

前端技术

- - CSDN博客综合推荐文章
随着互联网产业的爆炸式增长,与之伴生的Web前端技术也在历经洗礼和蜕变. 尤其是近几年随着移动终端的发展,越来越多的人开始投身或转行至新领域,这更为当今的IT产业注入了新的活力. 尽管Web前端技术诞生至今时日并不长,但随着Web技术的逐渐深入,今后将会在以下几方面发力. JavaScript的兄弟们.

Web前端优化

- - JavaScript - Web前端 - ITeye博客
优点:直接使用浏览器内存的缓存数据,减少网站后台压力,用户体验(速度)好. 缺点:对于时时变化的动态页面,这种情况就不能容忍了,因为每次访问的都是第一次访问的内容,这样即使所请求的页面已经变化了,用户也不可能知道,所以此场景必须要消除这种缓存的影响. 延迟加载,将资源延迟到需要的时候的加载,例如detail页面,相关产品推荐,当用户浏览更多的信息往下拉动滚动时,才进行加载,异步加载可以大幅减少对后端资源的使用,在需要的时候加载,是资源合理使用常用的方式,但是也带来一个问题,当往下拉才去加载,如果性能不够好,用户的体验其实是不好的,“菊花”转动的时间会比较长,同时异步加载对前端性能的作用也是非常明显的,渲染的节点数量大幅减少.

Web 前端测试

- - Web前端 - ITeye博客
Web 网站测试流程和方法(转载). 进行正式测试之前,应先确定如何开展测试,不可盲目的测试. 一般网站的测试,应按以下流程来进行:. 1)使用HTML Link Validator将网站中的错误链接找出来;. 2)测试的顺序为:自顶向下、从左到右;. 3)查看页面title是否正确. (不只首页,所有页面都要查看);.

前端xss攻击

- - SegmentFault 最新的文章
实习的时候在项目中有接触过关于xss攻击的内容,并且使用了项目组中推荐的一些常用的防xss攻击的方法对项目进行了防攻击的完善. 但一直没有时间深入了解这东西,在此,做一个简单的梳理. xss跨站脚本攻击(Cross Site Scripting),是一种经常出现在web应用中的计算机安全漏洞,它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入的恶意html代码会被执行,从而达到恶意用户的特殊目的.

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定,里面规定了服务禁语和礼貌用语,看了大乐. 3、乘车高峰车厢内拥挤时,禁语:“快往里走,站在前面又没有钞票检. ”文明语:“请尽量往里走,照顾没有上车的乘客”. 4、车子抛锚,禁语:“车子抛锚没有办法,人都要生毛病的,车子坏了也正常. ”文明语:“对不起,车子出现故障修一下,请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式,Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading failure),导致雪崩效应.

初识前端模板

- slackware - 百度泛用户体验
“模板”这个词,可能很多人第一印象是后端的技术(Smarty,Velocity等),但本文要讲的却不是后端的概念,而是前端开发中所使用到的一种技术,也就是“前端模板”技术. 模板的工作原理可以简单地分成两个步骤:模板解析(翻译)和数据渲染. 这两个步骤可分别部署在前端或后端来执行. 如果都放在后端执行,则是像Smarty这样的后端模板,而如果都放在前端来执行,则是我们要探讨的前端模板.