建構分散式系統需要在服務邊界、通訊模式和資料一致性之間取捨。這項技能提供經過驗證的模式和程式碼範例，用於分解單體架構、實現服務間的彈性通訊，以及有效管理分散式交易。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“microservices-patterns”。 分析這個電子商務單體，包含訂單、付款、庫存、配送和使用者帳戶模組。建議微服務邊界。
预期结果:
根據領域驅動設計原則，以下是建議的服務邊界：1) 訂單服務 - 擁有訂單生命週期和訂單狀態；2) 付款服務 - 處理付款處理和退款；3) 庫存服務 - 管理庫存水準和預訂；4) 目錄服務 - 產品資訊和定價；5) 配送服務 - 履約和配送追蹤。使用者帳戶應作為跨系統共享的身份識別服務的一部分。每個服務應擁有自己的資料庫，並發布領域事件以實現最終一致性。
正在使用“microservices-patterns”。 為訂單履約設計事件驅動通訊。什麼時候應該使用事件而非直接服務呼叫？
预期结果:
在以下情況使用事件：1) 多個服務需要對同一事件做出反應（OrderCreated 觸發庫存預訂、配送標籤生成、客戶通知）；2) 可以接受時間解耦（庫存可以在幾秒後預訂）；3) 您希望服務之間保持鬆耦合。在以下情況使用直接同步呼叫：1) 您需要立即回應（下單前檢查庫存）；2) 呼叫者沒有回應無法繼續；3) 需要強一致性。對於訂單履約，非同步發布 OrderCreated 事件以處理庫存和配送，但在下單時使用同步呼叫檢查庫存可用性。
正在使用“microservices-patterns”。 顯示帶有補償邏輯的訂單付款 saga 模式。
预期结果:
OrderPaymentSaga 步驟：1) ReserveOrder - 建立待處理訂單；補償：CancelOrder。2) ProcessPayment - 向客戶收費；補償：RefundPayment。3) ConfirmInventory - 預訂項目；補償：ReleaseInventory。4) CompleteOrder - 標記訂單確認；補償：MarkOrderFailed。執行：如果步驟 2（付款）失敗，按反向執行補償動作：ReleaseInventory（步驟 3 補償）、CancelOrder（步步驟 1 補償）。這確保系統在任何故障後都能回滾到一致的狀態。
安全审计
安全All 29 static analysis findings are false positives from markdown code examples in educational documentation. The skill contains only documentation files (SKILL.md and implementation-playbook.md) with Python code samples demonstrating microservices patterns. No executable code, scripts, or actual security risks present. The 'external_commands' and 'network' patterns detected are from code block delimiters and example URLs in instructional content.
质量评分
你能构建什么
分解單體應用程式
軟體架構師計劃將大型 Rails 單體分解為專注的服務。使用此技能來識別邊界上下文、定義服務邊界，並規劃 strangler fig 遷移策略。
設計事件驅動通訊
後端工程師正在實作服務之間的非同步訊息傳遞。使用此技能在 Kafka、RabbitMQ 或雲端原生訊息之間選擇、設計事件結構描述，並實作具有適當錯誤處理的事件處理常式。
實作彈性模式
平台工程師正在建立服務間通訊的可靠性。使用此技能來應用熔斷器、實作指數退避重試邏輯，並防止分散式系統中的連鎖故障。
试试这些提示
分析此單體應用程式 [描述領域和模組]，並建議微服務邊界。透過業務能力和 DDD 子領域將相關功能分組。解釋每個建議服務邊界的原因。
我需要 [服務 A] 與 [服務 B] 通訊以實現 [特定用例]。比較同步 REST 與非同步事件驅動方法。根據延遲、一致性需求和失敗處理建議最佳模式。
為 [涉及多個服務的業務流程] 設計 saga 編排。識別每個交易步驟、定義失敗的補償動作，並展示具有錯誤處理的執行流程。
我的服務呼叫 [外部服務/相依項目] 時會遇到間歇性故障。設計具有適當失敗閾值、復原超時和回退行為的熔斷器。以 [您偏好的語言] 顯示程式碼。
最佳实践
- 從模組化單體開始，只有在有明確的業務邊界和營運需求時才提取服務
- 根據領域驅動設計的業務能力和邊界上下文（而非技術層）來設計服務
- 優先使用非同步事件驅動通訊而非同步 REST，以實現更好的鬆耦合和彈性
- 為所有服務間呼叫實作熔斷器、指數退避重試和超時
- 應用每服務資料庫模式以避免共享資料庫耦合，並實現獨立部署
- 使用分散式追蹤和結構化日誌來觀察跨服務邊界的請求
避免
- 分散式單體 - 必須一起部署並共享資料庫的服務，削弱了微服務的優勢
- 冗長的服務 - 服務之間過多的同步呼叫造成緊密耦合和延遲
- 共享資料庫 - 多個服務存取同一個資料庫會造成綱要鎖定和部署依賴
- 忽略失敗模式 - 假設網路可靠、服務始終可用，或訊息必定傳遞
- 過早採用微服務 - 在了解領域和營運負擔之前就以微服務開始新專案