阅读 60

打造百亿级大数据日志网关

前言

大数据一直是技术社区的热门话题,是从事大型服务架构的攻城狮必修之课。

岳鹰全景监控平台作为大数据应用系统,每时每刻都需要处理大量的日志流量,今天我们将通过本文,为大家介绍岳鹰是如何打造大数据日志网关(简称网关),以满足以下需求:

QPS 数十万
日PV 数百亿
流量带宽 Gbps级别
日流量 数十TB
RTT <=40ms
数据安全性
服务可用性 99.99%

背景

一个监控系统大致包括四个阶段:日志采集上报、日志存储、统计与分析、数据展示,具体如下所示

1.png
而作为整个链路的数据入口,可以把网关想象为通往皇城前的守门将,所有的数据流入都需要经过其“把关”,才能到达下游被处理
2.png

业务特性

概括来说,网关其核心设计要素主要有安全、高可用、大流量、高并发以及成本5大特性,如下图:

3.png

安全性

作为一个对外暴露的服务,安全性必定是凌驾于一切之上的。除常见的物理层、网络层、系统层的安全防御以外,在应用层,我们通过以下手段保证数据安全性:

4.png

  • Https——作用不多说,请自行Google
  • Params Verify——常规的入参信息校验
  • Time Verify——请求超时校验
  • Sign Verify——签名校验,通过请求信息、应用标识、应用秘钥生成
  • Business Verify——业务级校验,如App是否存在有效、数据是否被限流等
  • Encrypt/Decrypt——数据加密上报,网关解密处理
  • No Store——本地无存储,防止服务器被黑客入侵导致数据泄漏

除此以外,还有防刷判断、请求重复判断、限流熔断等一些列保障措施,这个后面会有专门文章解读,敬请期待...^v^!

高可用

可用性决定了整个平台的数据可用性(若垮掉整个下游都不会再有数据),因此需要有以下策略保证其服务可用性:

5.png
整个架构非常经典,各核心职责:

  1. 日志数据由应用端利用SDK通过互联网上报至合适的服务节点;
  2. 由统一服务层,完成https数据解密、请求路由、负载均衡操作;
  3. 具体的业务操作由日志网关应用负载进行业务层处理;
  4. 过程当中需要用到的相关业务数据,通过Redis集群加载,并利用广播机制实现实时数据刷新;
  5. 当日志完成初步处理后,会发往Kafka集群,并供下游服务使用; ##大流量&高并发 如上文说述,网关需要
  • 处理 百亿级以上/日 日志上报请求(按16小时分布计算,QPS达十万级别)。
  • 接收 约数十TB/日流量(按16小时分布计算,需要带宽Gbps级别)。
  • 毫秒级请求响应能力(否则有可能影响调用端的整体性能,或丢失数据)。

偶遇极端情况,还会呈几何级别上涨(想了解如何处理这种极端情况,请期待后面推文)。可见要解决这一问题,比“安全性”、“可用性”要困难的多。在说解决方案之前,我们不妨先大概了解下整个上报的处理流程:

6.png

核心(长耗时)的处理逻辑集中在“请求校验”、“业务处理”两个环节。当中又可以划分为“CPU密集型”和“I/O密集型”(小乌龟图标位置)操作。

CPU密集型

网关并非复杂运算形应用,针对纯CPU操作的优化其实非常有限。值得注意的是,现代主流的编程语言(如Java、Node等),其在逻辑运算能力上的差异一般不会很大(当然不同技术有其特殊的优化手段),而在实际情况下,提升硬件性能、利用负载均衡这两个手段效果会最为明显。

7.png

I/O密集型

I/O操作一般都会比纯CPU/内存操作要慢得多,当中又要细分为本地I/O和网络I/O两种:

8.png
解决这方面问题,我们的手段是:

  • 数据压缩上报——提高网络传输速度,减少带宽耗损。

  • 合并上报——减少并发请求数,提升压缩质量。

  • 分阶段请求处理——http请求处理实际上是分多个阶段的(如Nginx就分了11个阶段),可以把大量用于校验的信息(该类信息通常比较小),通过http头部传输,并在header处理阶段完成校验操作;若检验失败就可以直接不处理报文体内容,这样可以减少非必要的流量处理,节省资源&提升效率。

  • 跨系统调用——利用中间件代替直接的跨系统访问,拥有更高性能同时,降低性能不稳定风险。

  • 高性能中间件选型——用Redis替代传统DB作为数据源、用Kakfa作为消息中转替代直接的下游系统访问。

  • 多级缓存——把不常变的数据,利用本地->集群缓存->物理存储方式进行缓存,减少I/O操作及运算耗时。

  • 数据缓冲 & 中转——在大数据分析处理的场景,我们需要对数据进行不同类型的加工处理(如统计、聚合、筛选、过滤等),若这些操作都在一次请求中完整处理,耗时会非常长。因此我们使用异步缓冲机制,利用消息中间件对数据进行缓冲,并中转至下游运算,这样可以大大降低RT,提升TPS&QPS。

  • 调整日志输出级别——上线后的应用,调整较低的日志输出级别(如error),可以减少本地磁盘的写入操作。

  • 线性落盘——针对需要写盘的操作,可以统一写到全局缓冲区,然后用独立线程/进程进行落盘操作,减少不规律I/O操作。 当然以上的方案是需要根据实际情况权衡使用,如使用缓存会导致变化响应慢、使用线性落盘数据会有丢失风险等。 ##成本 作为一个如此大流量、高并发的产品,我们需要承受各类硬件、网络、维护等的高成本投入(当然还有其它),因此在技术方案上,我们必须要考虑这个因素:

  • 硬件成本——如何提升同等级别设备下,单实例的运作效率。

  • 网络成本——如何在不影响(小影响)性能效果下,降低网络资源耗损。

  • 维护成本——如何通过更多DevOps工具(部署、测试、监控),减少人工成本投入。

  • 人力成本——包括学习成本、实施成本、问题跟进成本。

  • ..... #技术选型

    9.png
    在选型的道路上,我们纠结了很久(也踩了很多坑)。最初我们曾用SpringBoot(Web层用原生Servlet,MVC性能很差!)实现了一个日志上报的demo,在16核8G内存下(并做一定配置调优),跑出单机1W+QPS的成绩。但干了Java那么久,又好像没怎么听过用Java Web来做高并发大流量网关的(Go、NodeJs:我们这方面精通!!!)。 于是我们开展了一波又一波的研讨,包括同类竞品分析、各类技术调研、各种性能评测等等(有机会再分享下我们的选型经过)。最终我们综合各方面因素,最终选型——OpenResty(Go、NodeJs:What?!) ##OpenResty简介 OpenResty是一个基于 Nginx 与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。 总结特点:

  • 基于 Nginx 与 Lua 的高性能 Web 平台(利用Nginx扩展机制,通过模块方式集成Nginx运行进程)

  • 部署简单方便

  • 专注超高并发、扩展性极高的动态 Web 应用、服务和动态网关

  • 非堵塞I/O、协程同步模型(比较适合密集小文件I/O请求场景)

  • 支持细粒度请求事件控制(结合上文提及的分阶段请求处理)

  • 学习成本低,轻量级Lua脚本语言(与nodejs相像),支持JIT

  • 有成功案例,也有同类应用场景案例

  • 同时根据评测,在相同硬件环境、业务逻辑的前提下,OpenResty都会有比较明显的性能优势。

但是,它也有一些不足的地方:

  • 冷门技术,学习成本高
  • 语法有点不习惯,特别是数组索引是从1开始!!!
  • "集成大量精良库",支持并不完善
  • 配套的开发、测试工具不丰富
  • 运行性能与编码实现方式非常密切,一不小心就可以掉30~40%性能
  • ......太多了,有机会再分享

能力扩展

正如上面说到,OpenResty原生的支持不算十分强大,为了更好的落地这个方案,我们还是做了一定扩展,包括:

  • lmf-mvc——纯lua编写的mvc框架,提供多层交互模型,解决原生配置复杂且实现混乱问题
  • lmf-redis——纯lua编写的Redis组件库,支持更多redis部署模型以及更多能力特性
  • lmf-commons——其它常用组件,提供如多级缓存组件、并发锁、日志、各类方法库等能力
  • ......

技术架构

说那么多,还是来个图比较实际:

10.png
新的方案为我们带来了更高的性能提升,在相同硬件情况下,新的方案QPS提升了3倍以上。同时硬件层面的提升对性能的影响也能起到更明显的效果。

小结

由于篇幅关系,大数据日志网关的介绍就到此为止,若大家想深入了解更多内容,欢迎各位关注我们,深入讨论~(小编又要回去码代码了)。