技术选型与工具链：实时计算引擎、存储与API网关

说实话，技术选型这件事，我见过太多团队一上来就追新。Flink 火就全上 Flink，Redis 快就全塞 Redis。结果呢？半年后运维想哭，业务方想骂人。今天咱们就聊聊，搭建实时数据服务目录时，到底该怎么选这些组件。

我个人习惯，选型前先问三个问题：数据量级多大？实时性要求多高？团队运维能力在哪？这三个问题没想清楚，后面全是坑。

实时计算引擎：Flink vs Spark Streaming

先说结论：如果做纯实时，我选 Flink；如果批流一体，Spark Streaming 也能打。但别急着站队，咱们拆开看。

Flink：真正的实时

Flink 的事件驱动架构，每条数据进来立刻处理。延迟能做到毫秒级。我在项目中遇到过这样一个场景：用户下单后需要实时更新推荐列表。用 Flink，订单事件一到，推荐模型立刻刷新。用户体验提升很明显。

Flink 的几个关键优势：

• Exactly-Once 语义：分布式快照机制，数据不丢不重
• 事件时间处理：乱序数据也能准确计算
• 状态管理：内置 RocksDB，大状态也不怕

Spark Streaming：批流一体

Spark Streaming 的微批次模式，延迟通常在秒级。但它的优势在于生态。如果你团队已经用 Spark 做离线，那 Spark Streaming 的学习成本几乎为零。

我曾经在一个项目里，白天跑实时，晚上跑离线，一套代码搞定。运维省心不少。

对比维度	Flink	Spark Streaming
延迟	毫秒级	秒级
状态管理	强（RocksDB）	弱（依赖外部存储）
SQL 支持	成熟	成熟
运维复杂度	中高	中
批流一体	需额外配置	原生支持

存储选型：Elasticsearch、MySQL、Redis

存储选型，说白了就是查什么、怎么查、多快查。实时数据服务目录里，这三种存储各司其职。

Elasticsearch：全文搜索与聚合

ES 的核心场景是搜索。数据目录里，用户要搜「订单金额大于 1000 的北京用户」，ES 几毫秒就能返回。我习惯用 ES 做数据索引层，把元数据、标签、业务字段都倒排进去。

但 ES 不是万能的。写入频繁的场景，ES 的 refresh 间隔会让你头疼。我一般设 5-10 秒，兼顾实时性和写入性能。

MySQL：结构化元数据

别笑，MySQL 在实时目录里依然有用。数据源的连接信息、字段映射关系、权限配置，这些结构化数据放 MySQL 最稳。我见过有人非要用 ES 存这些，结果查询复杂到想哭。

MySQL 的定位是配置中心。数据量不大，但要求强一致。读写分离、主从同步，这些基本功别省。

Redis：缓存与状态

Redis 的定位很明确：热数据缓存。实时目录里，用户频繁查询的元数据、最近 10 分钟的统计结果，放 Redis 里。TTL 设个 5 分钟，过期自动淘汰。

我曾经踩过一个坑：把全量元数据都塞 Redis。结果内存爆了，还导致缓存穿透。后来改成只缓存热点数据，冷数据走 ES，问题解决。

存储	核心场景	数据量	一致性要求	延迟
Elasticsearch	搜索、聚合	TB 级	最终一致	毫秒级
MySQL	配置、元数据	GB 级	强一致	毫秒级
Redis	缓存、状态	GB 级	最终一致	微秒级

API网关：Kong vs Nginx

网关层，说白了就是统一入口。认证、限流、路由、日志，这些脏活累活交给网关。

Kong：功能全面

Kong 基于 OpenResty，插件生态丰富。认证插件（JWT、OAuth2）、限流插件、日志插件，开箱即用。我习惯用 Kong 做API 管理平台，所有实时数据服务统一注册到 Kong。

Kong 的缺点？重。部署需要 PostgreSQL 或 Cassandra 做数据存储。小团队运维起来有点吃力。

Nginx：轻量灵活

Nginx 的定位是反向代理。如果你只需要简单的路由和限流，Nginx 就够了。配合 Lua 脚本，也能实现不少功能。

我曾经在一个小项目里，直接用 Nginx + Lua 做网关。路由、限流、鉴权，几百行 Lua 搞定。运维成本极低。

对比维度	Kong	Nginx
功能丰富度	高（插件生态）	低（需自研）
运维复杂度	中高	低
性能	中	高
扩展性	强（插件机制）	中（Lua 脚本）
适用场景	大型 API 管理	轻量代理

整体架构图

下面这张图，是我在项目中常用的实时数据服务目录架构。你看一眼，心里就有数了。

你看，整个链路很清晰。数据源进来，Flink 做实时计算，结果分三层存储，最后通过网关统一暴露。每个环节都有明确的选型依据。