mcpField
A
azure-messaging-workflows

azure-messaging-workflows

github.com/composio-community云与 DevOps1442 次安装23 周前更新
代码仓库

关于 azure-messaging-workflows

面向 Claude 的技能,用于设计和实现基于 Azure 的消息工作流。它涵盖架构与服务选择,并关注可靠性、故障处理和可观测性。

主要功能

  1. 01设计异步消息架构
  2. 02选择 Azure 消息服务
  3. 03配置队列、主题和路由
  4. 04构建生产者与消费者
  5. 05规划重试和死信处理
  6. 06监控并扩展事件处理

适用场景

  1. 01用队列解耦微服务
  2. 02构建事件驱动的订单处理
  3. 03创建云端事件管道
  4. 04改善分布式系统故障恢复

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/composio-community/opencode-skills --skill azure-messaging-workflows

安装后在 Claude Code 中输入/azure-messaging-workflows确认已加载。

详细介绍

Azure 消息工作流

概述

此技能可帮助 Claude 使用 Microsoft Azure 云服务设计、实现和管理消息系统。

工作流侧重于:

  • 异步通信
  • 事件驱动架构
  • 队列系统
  • 发布/订阅消息传递
  • 分布式工作流
  • 可扩展的云通信
  • 可靠的消息传递
  • 云原生集成系统

目标是构建具备以下特性的消息管道:

  • 可扩展
  • 容错
  • 松耦合
  • 事件驱动
  • 可用于生产环境

此工作流强调分布式系统中的可靠性、可观测性和可扩展性。


设置

开始之前:

  1. 创建 Azure 帐户: https://azure.microsoft.com

  2. 安装 Azure CLI:

npm install -g azure-cli

或参阅: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli

  1. 登录 Azure:
az login
  1. 创建 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 应该:

  1. 设计队列架构
  2. 配置消息路由
  3. 实现生产者和使用方
  4. 处理重试和故障
  5. 监控事件流
  6. 确保消息持久性
  7. 动态扩展使用方

最终结果应:

  • 保持容错能力
  • 高效扩展
  • 支持异步处理
  • 提高系统可靠性
  • 减少服务间耦合

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 应:

  1. 优先采用异步通信模式
  2. 针对分布式系统故障进行设计
  3. 有目的地选择 Azure 消息服务
  4. 保持服务松耦合
  5. 实现完善的可观测性系统
  6. 优化云原生通信的可扩展性

工作流应优化以下方面:

  • 可靠性
  • 可扩展性
  • 韧性
  • 运行状态可见性
  • 分布式系统稳定性

最佳实践

  • 使用队列解耦服务
  • 谨慎实现重试
  • 始终配置死信队列
  • 持续监控消息流
  • 保持消费者具备幂等性
  • 尽早验证扩展行为
  • 优先保障分布式系统的可观测性

说明

  • 与紧密耦合的架构相比,异步系统的扩展能力显著更强
  • 可靠的消息传递系统需要强大的故障处理能力
  • 可观测性对于分布式云系统至关重要
  • Azure 消息传递服务解决不同的扩展性和可靠性问题
  • 松散耦合的系统能够提升部署灵活性和韧性

评论

支持 Markdown