マイクロサービストランザクションをサポートするサンプルアプリケーションを作成する
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
このチュートリアルでは、ScalarDB でマイクロサービストランザクションをサポートするサンプルアプリケーションを作成する方法について説明します。
概要
このチュートリアルでは、ScalarDB の2フェーズコミットインターフェースを使用したトランザクションを通じてアイテムを注文し、信用枠で支払いを行うことができるサンプル電子商取引アプリケーションを作成するプロセスを示します。
サンプルアプリケーションには、database-per-service pattern に基づく Customer Service と Order Service という2つのマイクロサービスがあります。
- Customer Service は、信用枠情報、信用限度額、信用合計などの顧客情報を管理します。
- Order Service は、注文の確定や注文履歴の取得などの注文操作を担当します。
各サービスには gRPC エンドポイントがあります。クライアントはエンドポイントを呼び出し、サービスも各エンドポイントを呼び出します。
サンプルアプリケーションで使用するデータベースは Cassandra と MySQL です。 Customer Service と Order Service は、それぞれ ScalarDB を介して Cassandra と MySQL を使用します。

図に示されているように、両方のサービスは、Consensus Commit プロトコルに使用される小さな Coordinator データベースにアクセスします。データベースはサービスに依存せず、Consensus Commit のトランザクションメタデータを高可用性の方法で管理するために存在します。
サンプルアプリケーションでは、セットアップと説明を簡単にするために、Coordinator データベースを Order Service の同じ Cassandra インスタンスに共存させています。または、Coordinator データベースを別のデータベースとして管理することもできます。
サンプルアプリケーションは ScalarDB の使用方法を示すことに重点を置いているため、アプリケーション固有のエラー処理、認証処理、および同様の機能はサンプルアプリケーションに含まれていません。ScalarDB での例外処理の詳細については、例外の処理方法を参照してください。
さらに、サンプルアプリケーションの目的上、各サービスには1つのコンテナがあるため、サービス間のリクエストルーティングは不要です。ただし、実稼働環境では、スケーラビリティと可用性のために各サービスに複数のサーバーまたはホストがあるため、2フェーズコミットインターフェイスを使用したトランザクションでは、サービス間のリクエストルーティングを検討する必要があります。要求ルーティングの詳細については、2フェーズコミットインターフェイスを使用したトランザクションでのリクエストルーティング を参照してください。
サービスエンドポイント
サービスで定義されているエンドポイントは次のとおりです。
-
Customer Service
getCustomerInfopaymentpreparevalidatecommitrollbackrepayment
-
Order Service
placeOrdergetOrdergetOrders