如何设计一个麻雀般的微型分布式架构?

设计该系统初衷是基于描绘业务(或机器集群)存储模型,分析代理缓存服务器磁盘存储与回源率的关系。系统意义是在腾讯云成本优化过程中,量化指导机房设备扩容。前半部分是介绍背景,对CDN缓存模型做一些理论思考。后半部分会实际操作搭建一个微型但是五脏俱全的分布式通用系统架构,最后赋予该系统一些跟背景相关的功能,解决成本优化中遇到的实际问题。

缓存服务器存储模型架构(背景):

img

图1 存储模型

腾讯CDN的线上路由是用户à分布于各地区各运营商的OC->SOC->SMid->源站。各个层级节点部署的都是缓存服务器。来自用户的部分请求流量命中服务器,另一部分产生回源流量。

随着业务带宽自然增长,用户端带宽增长,假设业务回源率不变的情况下,磁盘缓存淘汰更新(淘汰)速率变快,表现为以下业务瓶颈(iowait变高、回源带宽变高,由于磁盘空间大小受限的缓存淘汰导致回源率变高)。

为了说明这个原理。我们假设两个极端:一个是设备磁盘容量无限大,业务过来的流量缓存只受源站缓存规则受限。只要缓存没过期,磁盘可以无限缓存,回源流量只需要首次访问的流量,所以这个回源量(率)只跟业务特性(重复率)有关系。另一个极端是磁盘极限小(归零),那么无论业务设置缓存是否过期,客户端访问量都是1比1的回源量。假设业务平均的缓存周期是1个小时。那么这1个小时的首次缓存带宽(同一cache key的多次访问,我们认为是一次)将是这个硬盘的所需要的空间。这个大小是合理的,可以保证磁盘足够容纳业务的量。假设这个量达不到,或者本来达到了,但是由于业务自然增长了,1个小时内地首次缓存带宽变多,硬盘空间也不够用。

设备扩容是个解决办法。但是压测系统在这之前,没有客观数据证明需要扩容多大设备。或者扩容多少设备没有进行灰度验证,设备到位拍脑袋直接线上部署机器。我们在实验机器进行线上日志的重放,模拟出存储模拟曲线,来指导线上机房合理的设备存储。这就是建设重放日志系统的意义。

麻雀虽小,五脏俱全的重放日志模型(总览)

这一章,我们定义了下列模块:

模拟日志服务器:下载线上某个机房的一段时间周期的访问日志。一个日志存放10分钟访问记录。机房有几台机器就下载几份日志。日志服务器同时提供任务分片信息的查询服务。假设我们需要重放任务id为pig_120t的任务切片。下图既为任务切片详情。

img

图2 日志服务器的日志分片文件

任务控制器:启动任务或者结束任务总开关。任务分配均匀分配给具体的肉鸡和代理服务器。插入任务到Task Pool中,收集服务端的实时总流量、回源流量、总请求次数和回源次数数据并插入到回源率结果数据表。

肉鸡:轮询Task Pool的任务表。如果有任务,则按照任务明细(时间、线上机房ip)向日志服务器请求下载该分片的日志。重放请求到指定的代理服务器。

代理服务端:提供实时回源数据查询服务。并且安装nws缓存服务器等组件,该机器等同于线上机房的软件模块。

实时展示界面:可随时查看实时回源率和一些任务异常状态信息。

图3为客户端和服务端的互动图。图4是任务控制端在任务进行中和其他模块的联动过程。

img

图3 肉鸡和代理服务端的架构

img

图4 控制端的任务联动过程

分布式系统特点

日志重放模型核心是一个高性能压测系统,但是需要添加一些逻辑:日志下载、日志分析重构、结果数据收集、数据上报展示。分布式系统核心是:是否做到了可拓展、可恢复、简易搭建、容错、自动化。以下内容会一一展开。

先说说高性能:在一个通用模型中。我们模拟线上日志,这个系统要做到高效、因为我们的重放日志速度要比线上的qps还要快。机器的重放速度决定了分析结果的速度。同时更快的速度,所需要的肉鸡资源更少。笔者在python各个url请求库和golang中,最终敲定使用了golang实现肉鸡。golang做到了和原生c+epoll一样快的速度,但是代码实现容易多了。理论上我们对一台做过代理端性能瓶颈分析。线上日志比模拟日志更复杂,qps适度下降是必然的。Golang这个客户端达到预期目标。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpsgsx.html