microservices-patterns
実証済みパターンでマイクロサービスアーキテクチャを設計
マイクロサービスによる分散システムの構築は、サービス境界、サービス間通信、耐障害性において複雑さをもたらします。このスキルは、サービス分解、イベント駆動アーキテクチャ、サガ調整、サーキットブレーカー実装のための実証済みパターンを提供し、レジリエントでスケーラブルなシステムの構築を支援します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「microservices-patterns」を使用しています。 eコマースプラットフォームをマイクロサービスにどのように分解すべきですか?
期待される結果:
- eコマースプラットフォームの場合、ビジネス機能を中心にサービスを整理することをお勧めします:
- 1. **Order Service** - 注文ライフサイクル、カート、注文履歴を管理
- 2. **Payment Service** - 決済処理、返金、支払い方法を処理
- 3. **Inventory Service** - 商品在庫、予約、倉庫の場所を追跡
- 4. **Catalog Service** - 商品リスト、検索、カテゴリ管理
- 5. **User Service** - 認証、プロフィール、設定
- 6. **Shipping Service** - 配送追跡、ラベル生成、配送業者統合
- 各サービスは独自のデータベースを所有し、明確に定義されたAPIまたはイベントを通じて通信します。Order ServiceはOrderCreatedイベントを公開し、PaymentおよびInventoryサービスがそれぞれの操作を非同期に処理するために消費します。
「microservices-patterns」を使用しています。 注文フルフィルメントサガで支払いが失敗した場合、どのように処理すればよいですか?
期待される結果:
- OrderFulfillmentSagaで支払いステップが失敗した場合、サガオーケストレーターは逆順で補償アクションをトリガーします:
- 1. 支払い失敗 - 支払いに対する補償は不要
- 2. 在庫を補償: InventoryService.release(reservation_id)を呼び出して予約を解放
- 3. 注文を補償: OrderService.cancel(order_id)を呼び出して注文をキャンセル
- 4. エラー詳細を含む失敗結果をクライアントに返す
- 重要なのは、各補償アクションを冪等に設計し、補償自体が部分的に失敗する可能性があるケースを処理することです。すべての補償アクションをログに記録し、必要に応じてオペレーターに手動介入のアラートを送信します。
「microservices-patterns」を使用しています。 サーキットブレーカーがすぐに開いてしまうのはなぜですか?どのように調整すべきですか?
期待される結果:
- サーキットブレーカーは、スライディングウィンドウ内で障害がfailure_thresholdを超えると開きます。一般的な原因と解決策:
- **開きすぎる場合:**
- - failure_thresholdを増やす(5の代わりに10を試す)
- - recovery_timeoutを増やす(30秒の代わりに60秒を試す)
- - 閉じる前に複数の成功を要求するsuccess_thresholdを追加
- **開いたままになりすぎる場合:**
- - より速いテストのためにrecovery_timeoutを減らす
- - トラフィック量に基づく適応的なしきい値を使用
- **ベストプラクティス:**
- - サービスの通常のエラー率に基づいてfailure_thresholdを設定
- - 典型的な障害期間より長くrecovery_timeoutを設定
- - パラメータを調整するためにサーキット状態の変化を監視
セキュリティ監査
安全Static analysis detected 36 patterns across 2 files. All findings evaluated as false positives or safe educational content. The 18 weak crypto alerts match on words like design and description in documentation. The 11 external command alerts are markdown code fences for syntax highlighting. Network patterns are legitimate example URLs for teaching microservices communication. No actual security risks identified.
リスク要因
🌐 ネットワークアクセス (7)
品質スコア
作れるもの
モノリスからマイクロサービスへの移行
Strangler Figパターンを適用して、レガシーモノリスから機能を段階的に抽出し、システムの安定性を維持しながら独立してデプロイ可能なサービスに移行します。
イベント駆動型注文処理の構築
Order、Payment、Inventoryサービスが、失敗したトランザクションに対するサガベースの補償を伴ってKafkaイベントを通じて非同期に通信する注文管理システムを設計します。
サービス呼び出しへのレジリエンスの追加
サーキットブレーカーと指数バックオフによる再試行を実装して、カスケード障害からサービスを保護し、部分的な障害下でのシステム全体の信頼性を向上させます。
これらのプロンプトを試す
{application_type}アプリケーションをマイクロサービスに分解するのを手伝ってください。アプリケーションには次の主要機能があります:{list_functions}。サービス境界をどのように定義し、どの分解戦略を使用すべきですか?マイクロサービスアーキテクチャ用のAPIゲートウェイパターンを設計してください。次のサービスがあります:{list_services}。ゲートウェイは認証、レート制限、リクエスト集約をどのように処理すべきですか?次のステップを含む{business_process}のサガパターンを実装するのを手伝ってください:{list_steps}。各ステップにどのような補償アクションを定義すべきで、部分的な障害をどのように処理すべきですか?{service_name}サービスが時折レイテンシスパイクを経験します。サーキットブレーカーのパラメータ(failure_threshold、recovery_timeout、success_threshold)をどのように設定し、既存のHTTPクライアントと統合すべきですか?ベストプラクティス
- 疎結合と高凝集性を確保するため、技術層ではなくビジネス機能に沿った明確なサービス境界を定義する
- システムのレジリエンスを向上させ、ブロッキング依存関係を削減するため、結果整合性を許容できる操作には非同期イベント駆動通信を使用する
- サービス間呼び出しには常にサーキットブレーカーを実装し、クライアントが課すタイムアウト予算よりも短いタイムアウトを設定する
回避
- 分散モノリス - 共有データベースや同期的な依存関係のチェーンを通じて密結合されたマイクロサービスを作成し、独立したデプロイメントの利点を失う
- おしゃべりなサービス - 単一のユーザーリクエストを完了するために数十回の往復呼び出しを必要とするサービスを設計し、レイテンシと障害ポイントを増加させる
- すべて同期 - すべてのサービス間通信にリクエスト-レスポンス通信を使用し、密結合を生み出し、独立したスケーリングと障害分離を妨げる