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

前言

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

岳鹰全景监控平台做为大数据应用系统，每时每刻都须要处理大量的日志流量，今天咱们将经过本文，为你们介绍岳鹰是如何打造大数据日志网关（简称网关），以知足如下需求：

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

背景

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

而做为整个链路的数据入口，能够把网关想象为通往皇城前的守门将，全部的数据流入都须要通过其“把关”，才能到达下游被处理

业务特性

归纳来讲，网关其核心设计要素主要有安全、高可用、大流量、高并发以及成本5大特性，以下图：

安全性

做为一个对外暴露的服务，安全性一定是凌驾于一切之上的。除常见的物理层、网络层、系统层的安全防护之外，在应用层，咱们经过如下手段保证数据安全性：

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

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

高可用

可用性决定了整个平台的数据可用性（若垮掉整个下游都不会再有数据），所以须要有如下策略保证其服务可用性：

整个架构很是经典，各核心职责：

1. 日志数据由应用端利用SDK经过互联网上报至合适的服务节点；
2. 由统一服务层，完成https数据解密、请求路由、负载均衡操做；
3. 具体的业务操做由日志网关应用负载进行业务层处理；
4. 过程中须要用到的相关业务数据，经过Redis集群加载，并利用广播机制实现实时数据刷新；
5. 当日志完成初步处理后，会发往Kafka集群，并供下游服务使用； ##大流量&高并发 如上文说述，网关须要

• 处理 百亿级以上/日 日志上报请求（按16小时分布计算，QPS达十万级别）。
• 接收 约数十TB/日流量（按16小时分布计算，须要带宽Gbps级别）。
• 毫秒级请求响应能力（不然有可能影响调用端的总体性能，或丢失数据）。

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

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

CPU密集型

网关并不是复杂运算形应用，针对纯CPU操做的优化其实很是有限。值得注意的是，现代主流的编程语言（如Java、Node等），其在逻辑运算能力上的差别通常不会很大（固然不一样技术有其特殊的优化手段），而在实际状况下，提高硬件性能、利用负载均衡这两个手段效果会最为明显。

I/O密集型

I/O操做通常都会比纯CPU/内存操做要慢得多，当中又要细分为本地I/O和网络I/O两种：

解决这方面问题，咱们的手段是：

• 数据压缩上报——提升网络传输速度，减小带宽耗损。

• 合并上报——减小并发请求数，提高压缩质量。

• 分阶段请求处理——http请求处理其实是分多个阶段的（如Nginx就分了11个阶段），能够把大量用于校验的信息（该类信息一般比较小），经过http头部传输，并在header处理阶段完成校验操做；若检验失败就能够直接不处理报文体内容，这样能够减小非必要的流量处理，节省资源&提高效率。

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

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

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

• 数据缓冲 & 中转——在大数据分析处理的场景，咱们须要对数据进行不一样类型的加工处理（如统计、聚合、筛选、过滤等），若这些操做都在一次请求中完整处理，耗时会很是长。所以咱们使用异步缓冲机制，利用消息中间件对数据进行缓冲，并中转至下游运算，这样能够大大下降RT，提高TPS&QPS。

• 调整日志输出级别——上线后的应用，调整较低的日志输出级别（如error），能够减小本地磁盘的写入操做。

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

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

• 网络成本——如何在不影响（小影响）性能效果下，下降网络资源耗损。

• 维护成本——如何经过更多DevOps工具（部署、测试、监控），减小人工成本投入。

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

• ..... #技术选型

  在选型的道路上，咱们纠结了好久（也踩了不少坑）。最初咱们曾用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——其它经常使用组件，提供如多级缓存组件、并发锁、日志、各种方法库等能力
• ......

技术架构

说那么多，仍是来个图比较实际：

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

小结

因为篇幅关系，大数据日志网关的介绍就到此为止，若你们想深刻了解更多内容，欢迎各位关注咱们，深刻讨论～（小编又要回去码代码了）。