关于 azure-messaging-workflows
面向 Claude 的技能,用于设计和实现基于 Azure 的消息工作流。它涵盖架构与服务选择,并关注可靠性、故障处理和可观测性。
主要功能
- 01设计异步消息架构
- 02选择 Azure 消息服务
- 03配置队列、主题和路由
- 04构建生产者与消费者
- 05规划重试和死信处理
- 06监控并扩展事件处理
适用场景
- 01用队列解耦微服务
- 02构建事件驱动的订单处理
- 03创建云端事件管道
- 04改善分布式系统故障恢复
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ composio-community/ opencode-skills --skill azure-messaging-workflows安装后在 Claude Code 中输入/azure-messaging-workflows确认已加载。
详细介绍
Azure 消息工作流
概述
此技能可帮助 Claude 使用 Microsoft Azure 云服务设计、实现和管理消息系统。
工作流侧重于:
- 异步通信
- 事件驱动架构
- 队列系统
- 发布/订阅消息传递
- 分布式工作流
- 可扩展的云通信
- 可靠的消息传递
- 云原生集成系统
目标是构建具备以下特性的消息管道:
- 可扩展
- 容错
- 松耦合
- 事件驱动
- 可用于生产环境
此工作流强调分布式系统中的可靠性、可观测性和可扩展性。
设置
开始之前:
-
创建 Azure 帐户: https://azure.microsoft.com
-
安装 Azure CLI:
npm install -g azure-cli
或参阅: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
- 登录 Azure:
az login
- 创建 Azure 资源。
推荐的服务:
- Azure Service Bus
- Azure Queue Storage
- Azure Event Grid
- Azure Event Hubs
- Azure Functions
推荐的工具:
- VS Code
- Azure Portal
- Azure CLI
- Docker
- GitHub Actions
可选项:
- Kubernetes
- Terraform
- 监控仪表板
- 分布式追踪系统
所需输入
- 消息传递需求
- 事件工作流
- 应用架构
- 吞吐量预期
- 可靠性要求
可选项:
- 现有微服务
- API 系统
- 队列使用方
- 监控系统
何时使用此技能
在以下情况下使用此技能:
- 构建分布式系统
- 实现异步工作流
- 解耦微服务
- 大规模处理事件
- 创建发布/订阅架构
- 管理云事件管道
- 扩展后端通信系统
- 提高云应用的可靠性
何时不应使用
以下情况请勿使用此技能:
- 小型单体应用
- 完全同步的工作流
- 无需分布式通信的系统
- 仅限本地运行的单进程应用
示例用例
使用 Azure 消息服务构建事件驱动的订单处理管道。
Claude 应该:
- 设计队列架构
- 配置消息路由
- 实现生产者和使用方
- 处理重试和故障
- 监控事件流
- 确保消息持久性
- 动态扩展使用方
最终结果应:
- 保持容错能力
- 高效扩展
- 支持异步处理
- 提高系统可靠性
- 减少服务间耦合
Azure 消息传递核心原则
1. 优先采用异步通信
消息系统应减少服务间的直接依赖。
避免使用:
- 紧密耦合的 API 调用链
- 阻塞式通信
应使用:
- 队列
- 事件
- 发布/订阅系统
- 后台处理
异步系统可提升:
- 可扩展性
- 可靠性
- 弹性
2. 针对故障进行设计
分布式系统经常会发生故障。
Claude 应主动处理:
- 重试
- 死信队列
- 重复事件
- 超时
- 使用方崩溃
- 瞬时云服务故障
可靠的系统需要:
- 平稳恢复
- 可观测性
- 容错能力
3. 选择合适的 Azure 服务
不同的 Azure 消息工具适用于不同的问题。
Azure Service Bus
最适合:
- 企业级消息传递
- 有序传递
- 可靠队列
- 事务
Azure Queue Storage
最适合:
- 简单的队列工作流
- 轻量级异步任务
- 高性价比的消息传递
Azure Event Grid
最适合:
- 事件路由
- 响应式云工作流
- 无服务器集成
Azure Event Hubs
最适合:
- 高吞吐量事件流
- 遥测管道
- 分析数据摄取
Claude 应根据以下因素选择服务:
- 吞吐量
- 可靠性
- 顺序要求
- 架构目标
4. 保持服务松耦合
消息系统应:
- 隔离服务
- 减少依赖
- 提升可扩展性
- 支持独立部署
良好的解耦有助于提升:
- 可维护性
- 韧性
- 部署灵活性
避免:
- 紧密同步的服务
- 共享状态耦合
- 脆弱的编排链
5. 监控一切
消息系统需要可观测性。
Claude 应协助实现:
- 日志记录
- 链路追踪
- 队列监控
- 故障告警
- 重试跟踪
- 吞吐量分析
良好的可观测性有助于提升:
- 调试能力
- 扩展能力
- 运行可靠性
工作流
1. 定义消息架构
首先确定:
- 生产者
- 消费者
- 事件类型
- 队列要求
- 吞吐量预期
定义:
- 同步与异步的边界
- 重试策略
- 传递保证
- 扩展策略
2. 选择 Azure 消息服务
根据以下因素选择:
- Service Bus
- Queue Storage
- Event Grid
- Event Hubs
考量因素:
- 事件量
- 顺序要求
- 持久性
- 架构复杂度
Claude 应优先考虑:
- 可靠性
- 可扩展性
- 运维简便性
3. 配置队列和主题
创建:
- 队列
- 订阅
- 主题
- 路由规则
配置:
- 重试策略
- 死信队列
- 消息 TTL
- 扩展设置
确保:
- 容错能力
- 传递可靠性
- 可预测的路由行为
4. 构建生产者和消费者
实现:
- 消息发布者
- 队列消费者
- 事件处理程序
- 后台工作进程
验证:
- 序列化一致性
- 幂等性
- 重试安全性
- 吞吐量处理能力
避免:
- 脆弱的消息解析
- 阻塞式工作流
- 不安全的重试
5. 妥善处理故障
实现:
- 重试
- 死信处理
- 后备系统
- 超时管理
- 监控告警
Claude 应主动防止:
- 无限重试循环
- 消息丢失
- 静默故障
- 重复处理错误
6. 监控并扩展
跟踪:
- 队列深度
- 处理延迟
- 故障率
- 吞吐量
- 消费者健康状况
扩展:
- 工作进程实例
- 事件处理器
- 无服务器消费者
确保:
- 高负载下处理稳定
- 运行状态可见
- 资源使用高效
7. 验证生产就绪情况
部署前验证:
- 重试行为
- 死信处理
- 可观测性
- 扩展行为
- 安全配置
确保:
- 系统保持容错能力
- 工作流可预测地扩展
- 故障可恢复
输出要求
最终输出应包括:
- 可扩展的消息架构
- Azure 原生队列系统
- 可靠的事件处理工作流
- 可观测性管道
- 容错的分布式通信
- 可用于生产环境的云消息系统
工作流本身应保持:
- 可扩展
- 有韧性
- 松耦合
- 可观测
- 云原生
执行策略(针对 AI Agent)
Agent 应:
- 优先采用异步通信模式
- 针对分布式系统故障进行设计
- 有目的地选择 Azure 消息服务
- 保持服务松耦合
- 实现完善的可观测性系统
- 优化云原生通信的可扩展性
工作流应优化以下方面:
- 可靠性
- 可扩展性
- 韧性
- 运行状态可见性
- 分布式系统稳定性
最佳实践
- 使用队列解耦服务
- 谨慎实现重试
- 始终配置死信队列
- 持续监控消息流
- 保持消费者具备幂等性
- 尽早验证扩展行为
- 优先保障分布式系统的可观测性
说明
- 与紧密耦合的架构相比,异步系统的扩展能力显著更强
- 可靠的消息传递系统需要强大的故障处理能力
- 可观测性对于分布式云系统至关重要
- Azure 消息传递服务解决不同的扩展性和可靠性问题
- 松散耦合的系统能够提升部署灵活性和韧性
评论
支持 Markdown