消息服务 + Serverless 函数计算如何助力企业降本提效？

背景

MQ消费引入的2个问题:

1. 如何以低成本、高吞吐、低延时的方式将消息数据从 Message Service 输送给下游消费服务？
2. 如何快速构建免运维、按需弹性伸缩算力的消息消费服务？

名词解释

• FC 函数计算
• connector 连接器
• EventBridge 事件总线

架构演进: 传统 -> serverless

MQ -> connector -> FC

connector 功能:

1. Transform：以 UDF 方式自定义数据清洗逻辑，同时支持 JsonPath 语法简单提取数据；
2. Filter：减少无用消息的后续处理，提供多种过滤匹配规则，如：前后缀匹配、数值匹配、IP 地址匹配等；
3. Window：提供窗口能力，可按照消息数量和间隔时间对消息做聚合推送。可提升消息处理吞吐，降低消息处理成本；
4. Real Time：从 Message Service 拉取消息到推送目标服务延时毫秒级别；
5. 自定义并发消费能力：并发安全的消费消息，提升吞吐能力；
6. 弹性计算资源：下游计算服务根据负载自动扩缩容，无需关心服务器资源水位问题；
7. Monitoring + Logging + Tracing：提供了丰富的监控指标和日志分析助力开发者监控系统状态、定位异常；
8. 完备的异常保障机制：自定义重试策略 + 容错机制 + 死信队列 + 限流 + 反压；

降本提效功能

• window: 本质是批处理
• Transform

• Template: 支持 JsonPath
• UDF（User Define Function 用户自定义函数）

• Filter

• 对敏感字、非法文字、关键字进行过滤；
• 对某些具有攻击性的 IP 进行消息拦截；

• Real Time
• 自定义并发消费能力
• 高可用保护策略

• 重试
• 死信队列
• 容错策略
• 反压

• 弹性计算资源

Connector 结构

• poll: 从上游拉去消息
• transform/filter: 消息处理(转换/过滤)
• sink: 推送给下游

客户案例: 广告平台 - 用户浏览信息清洗

最佳实践: kafka -> Connector -> FC

总结 & 展望

serverless 系统优势

• 降本
• 提效