消息服务 + Serverless 函数计算如何助力企业降本提效？
背景
MQ消费引入的2个问题:
- 如何以低成本、高吞吐、低延时的方式将消息数据从 Message Service 输送给下游消费服务？
- 如何快速构建免运维、按需弹性伸缩算力的消息消费服务？
名词解释
- FC 函数计算
- connector 连接器
- EventBridge 事件总线
架构演进: 传统 -> serverless
MQ -> connector -> FC
connector 功能:
- Transform：以 UDF 方式自定义数据清洗逻辑，同时支持 JsonPath 语法简单提取数据；
- Filter：减少无用消息的后续处理，提供多种过滤匹配规则，如：前后缀匹配、数值匹配、IP 地址匹配等；
- Window：提供窗口能力，可按照消息数量和间隔时间对消息做聚合推送。可提升消息处理吞吐，降低消息处理成本；
- Real Time：从 Message Service 拉取消息到推送目标服务延时毫秒级别；
- 自定义并发消费能力：并发安全的消费消息，提升吞吐能力；
- 弹性计算资源：下游计算服务根据负载自动扩缩容，无需关心服务器资源水位问题；
- Monitoring + Logging + Tracing：提供了丰富的监控指标和日志分析助力开发者监控系统状态、定位异常；
- 完备的异常保障机制：自定义重试策略 + 容错机制 + 死信队列 + 限流 + 反压；
降本提效功能
- window: 本质是批处理
- Transform
- Template: 支持 JsonPath
- UDF（User Define Function 用户自定义函数）
- Filter
- 对敏感字、非法文字、关键字进行过滤；
- 对某些具有攻击性的 IP 进行消息拦截；
- Real Time
- 自定义并发消费能力
- 高可用保护策略
- 重试
- 死信队列
- 容错策略
- 反压
- 弹性计算资源
Connector 结构
- poll: 从上游拉去消息
- transform/filter: 消息处理(转换/过滤)
- sink: 推送给下游
客户案例: 广告平台 - 用户浏览信息清洗
最佳实践: kafka -> Connector -> FC
总结 & 展望
serverless 系统优势
- 降本
- 提效
