帮助设计与评估企业系统集成方案,覆盖遗留改造、网关、事件与失效模式。
该技能材料显示其为开源的纯提示词/文档型企业集成设计知识包,不要求密钥、未声明远程端点,也未表现出执行代码或访问本地数据的能力。基于现有材料,整体风险较低,主要仅需留意其来源社区采用度和维护状态信息有限。
材料明确标注无需密钥或环境变量,未见请求 API token、账号凭证或其他敏感认证信息,凭证泄露与滥用风险低。
未声明任何远程端点,且系统检查项为 prompt-only;从提供内容看更像本地知识说明/提示模板,不体现向外部服务发送用户数据的行为。
材料仅包含企业集成模式说明与设计建议,未见本机起进程、执行脚本、调用 shell 或请求系统级执行权限的描述。
未描述读取或写入本地文件、数据库、剪贴板、浏览器内容或其他资源的能力;按现有信息看不涉及数据访问授权。
来源为 GitHub 上的开源仓库,具备可审计性,这显著降低风险;但许可证未声明、star 为 0、维护状态未知,社区验证与持续维护证据有限,建议在纳入生产前复核仓库内容与更新情况。
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "system-type-enterprise-integration" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-enterprise-integration/SKILL.md 2. 保存为 ~/.claude/skills/system-type-enterprise-integration/SKILL.md 3. 装好后重载技能,告诉我可以用了
请基于绞杀者模式、反腐层和 API 网关,为一个核心单体 ERP 逐步迁移到微服务设计集成方案。请给出分阶段路线图、系统边界、数据同步方式、主要风险与回滚策略。
一份分阶段的遗留改造集成方案,说明模式选型、迁移顺序、接口治理和风险控制。
我们需要在 CRM、订单系统、库存系统和计费系统之间实现跨系统流程。请比较同步 API 编排与事件驱动集成,分析 canonical data model、event-carried state transfer 的适用性,以及常见失败模式和补偿机制。
一份架构评估建议,包含集成方式对比、数据模型建议、故障处理与一致性权衡。
请审查以下企业集成架构:外部请求先经过 API 网关,再调用中台服务,部分流程通过消息总线同步到旧系统。请从耦合、数据一致性、反腐层设计、可观测性、重试风暴和级联故障角度列出主要风险,并给出改进建议。
一份集成架构风险清单与优化建议,帮助发现脆弱点并提升稳定性。
Patterns, failure modes, and anti-patterns for connecting, modernizing, and orchestrating enterprise systems.
Enterprise integration is the art of making systems talk to each other when they were never designed to. Every pattern trades coupling for something — throughput, consistency, simplicity, or debuggability. The right choice depends on what you can afford to lose.
| Topology | Description | Coupling | Failure domain | Debuggability | When it works |
|---|---|---|---|---|---|
| Point-to-point | Direct connections between each pair of systems. N systems → N×(N-1)/2 connections. | Tightest — every system knows every other system's interface | Localized but unpredictable — one system's outage cascades differently depending on who depends on it | Easy when there are 3 systems, impossible at 15 | Small number of integrations (<5 systems), throwaway prototypes, or when two systems genuinely have a 1:1 relationship that won't grow |
| Hub-and-spoke (ESB) | Central bus mediates all communication. Systems only know the bus. | Moderate — systems decouple from each other but couple to the bus | Centralized — the bus is a SPOF for everything | Good — the bus logs everything (in theory) | When you need protocol translation, message transformation, and routing in one place. When governance requires a central integration team. When the number of systems is moderate (10–30) and the integration team has the capacity. |
| Event mesh / event backbone | Distributed event infrastructure (Kafka, Pulsar, etc.). Systems publish and subscribe to topics. No central broker logic. | Loosest — producers don't know consumers exist | Distributed — broker failure is partial, consumer failure is isolated | Harder — requires distributed tracing, topic monitoring, consumer lag tracking | When you have many (30+) systems, event-driven architectures, and teams that can own their own consumers. When you need to replay events for recovery or new consumers. |
Synchronous (request/reply). System A calls System B and waits for a response. The caller's latency includes the callee's latency. The caller's availability depends on the callee's availability.
When it's right:
When it creates coupling nightmares:
Asynchronous (fire-and-forget / event-driven). System A publishes a message or event and moves on. System B processes it whenever it can.
When it's right:
When it creates coupling nightmares:
…
帮助设计可离线运行的边缘系统,处理同步、冲突恢复与弱网故障场景。
用于按七步法系统审查架构设计,识别风险、权衡并产出改进建议。
用 Unix/Linux 设计哲学评估系统方案的可组合性、简洁性与关注点分离。
帮助用户设计或评估基于 Azure 的系统架构与运维方案
帮助设计与评估数据管道架构,覆盖批流处理、调度、质量与故障策略。
帮助设计和评估多租户SaaS的平台隔离、计量计费与稳定性方案
帮助设计和评估事件驱动、消息驱动与异步工作流系统架构。
帮助设计与评估实时协作系统的连接、同步、冲突处理与故障模式
帮助你设计或评估Web服务架构、API模式、扩展性与可靠性问题。
帮助设计或评估单页应用架构,涵盖路由、状态、性能与离线能力。
帮助设计或评估命令行工具与开发者 SDK 的架构、兼容性和使用体验
帮助设计与评估去中心化点对点系统的架构模式与关键机制