アーキテクチャテンプレート「マイクロサービスのマクロ共有トランザクション」

投稿者： Denis Tsyplakov 、ソリューションアーキテクト、DataArt

問題の声明

マイクロサービスアーキテクチャを構築するとき、特にモノリシックアーキテクチャをマイクロサービスに移行するときの問題の1つは、多くの場合トランザクションです。 各マイクロサービスは、独自の機能グループを担当し、場合によってはこのグループに関連付けられたデータを制御し、自律的にまたは他のマイクロサービスにリクエストを送信することにより、ユーザーリクエストに対応できます。 さまざまなマイクロサービスによって制御されるデータの一貫性を確保する必要があるまで、これはすべて正常に機能します。



たとえば、このアプリケーションは大規模なオンラインストアで動作します。 とりわけ、相互に弱く相互接続された3つの事業領域があります。

1. 倉庫-何を、どこで、どのように、どのくらいの期間保管したか、特定のタイプの商品が現在何個在庫されているかなど
2. 商品の送付-梱包、出荷、配達の追跡、遅延に関する苦情の分析など
3. 商品が海外に送られた場合の商品の移動に関する税関報告の維持（実際、この場合、特別に何かを作成する必要があるかどうかはわかりませんが、ドラマを追加するプロセスに国のサービスを接続します）。

これらの3つの領域にはそれぞれ多くのばらばらな機能が含まれており、複数のマイクロサービスとして表すことができます。



1つの問題があります。 人が製品を購入し、それを梱包し、宅配便で送ったとします。 とりわけ、倉庫内の商品の単位が1つ少ないことを示す必要があります。これは、商品の配送プロセスが開始されたこと、および商品が中国に送られた場合、税関の書類を処理するためです。 プロセスの2番目または3番目の段階でアプリケーションがクラッシュした場合（たとえば、ノードがクラッシュした場合）、データは一貫性のない状態になります。そのような障害はごくわずかであり、ビジネスにとって非常に不愉快な問題（税関職員の訪問など）につながります。



この種の古典的なモノリシックアーキテクチャでは、データベース内のトランザクションによって問題が簡単かつエレガントに解決されます。 しかし、マイクロサービスを使用するとどうなりますか？ すべてのサービスから同じデータベースを使用する場合（あまり洗練されていませんが、この場合は可能です）、このデータベースの操作は異なるプロセスから行われ、プロセス間でトランザクションを引き伸ばすことはできません。

解決策

この問題にはいくつかの解決策があります。

1. 奇妙なことに、問題を無視できる場合があります。 障害が1か月に1回しか発生せず、その結果を手動で削除することでビジネスに許容できる費用がかかることがわかっている場合、そのい見え方に注意を払うことはできません。 税関の申し立てを無視できるかどうかはわかりませんが、特定の状況下でもこれが可能であると考えられます。
2. 補償（罰金を支払うなど、税関に対する金銭的補償ではありません）は、処理手順を複雑にするさまざまなステップのグループですが、失敗したプロセスを検出して処理できます。 たとえば、操作を開始する前に、出荷操作を開始していることを特別なサービスに書き込み、最後にすべてが正常に終了したことをマークします。 その後、定期的に不完全な操作があるかどうかを確認し、操作がある場合は、3つすべてのデータベースを調べて、データを一貫した状態にしようとします。 これは完全に機能する方法ですが、処理ロジックが大幅に複雑になり、操作ごとに行うのは非常に苦痛です。
3. 2フェーズトランザクション、厳密に言えば、アプリケーションに関連して分散されるトランザクションを作成できるXA +仕様は、少数の人が好み、さらに重要なのは少数の人が構成できる非常に重いメカニズムです。 さらに、軽量のマイクロサービスでは、イデオロギー的に弱い互換性があります。
4. 原則として、トランザクションはコンセンサス問題の特殊なケースであり、多数の分散コンセンサスシステムを使用して問題を解決できます（大まかに言えば、キーワードpaxos、raft、zookeeper、etcd、consulでグーグルであるすべてのもの）。 しかし、倉庫活動の広範囲で分岐したデータの実際のアプリケーションでは、これらはすべて2フェーズトランザクションよりもさらに複雑に見えます。
5. キューと結果整合性（長期的な一貫性）-タスクを3つの非同期タスクに分割し、データを順次処理し、サービス間でキューからキューに渡し、配信確認メカニズムを使用します。 この場合、コードはそれほど複雑ではありませんが、留意すべき点がいくつかあります。
   
   
   • キューは、「1回以上」の配信を保証します。つまり、同じメッセージを再配信する場合、サービスはこの状況を正しく処理し、商品を2回出荷しないようにする必要があります。 これは、たとえば注文の一意のUUIDを使用して実行できます。
   • 各時点のデータはわずかに矛盾します。 つまり、商品は最初に倉庫から消えてから、少し遅れて発送の注文が作成されます。 後で、税関データが処理されます。 この例では、これは完全に正常であり、ビジネスに問題はありませんが、そのようなデータの動作が非常に不快になる場合があります。
   • その結果、最初のサービスが何らかのデータをユーザーに返さなければならない場合、最終的にユーザーのブラウザーにデータを配信する一連の呼び出しは非常に重要です。 主な問題は、ブラウザーが要求を同期的に送信し、通常は同期応答を予期することです。 非同期のリクエスト処理を行う場合、ブラウザへのレスポンスの非同期配信を構築する必要があります。 従来、これはWebソケットを介して、またはブラウザからサーバーへの新しいイベントの定期的な要求を介して行われます。 たとえば、SocksJSなど、このリンクを構築するいくつかの側面を簡素化するメカニズムがありますが、それでも複雑さが増します。

ほとんどの場合、後者のオプションが最も受け入れられます。 処理要求はそれほど複雑ではありませんが、数倍長く動作しますが、原則として、この種の操作では受け入れられます。 また、繰り返されるリクエストを遮断するために、もう少し複雑なデータ編成が必要ですが、これについてもそれほど複雑なことはありません。



概略的に、キューと結果整合性を使用してトランザクションを処理するためのオプションの1つは次のようになります。

1. ユーザーが購入すると、これに関するメッセージがキューに送信されます（たとえば、RabbitMQクラスター、またはGoogle Cloud Platformで作業している場合-Pub / Sub）。 キューは永続的であり、1回以上の配信を保証し、トランザクションです。つまり、メッセージを処理するサービスが突然ドロップしても、メッセージは失われませんが、サービスの新しいインスタンスに再度配信されます。
2. メッセージがサービスに到着すると、倉庫内の商品に出荷準備ができているとマークが付けられ、次に「商品の出荷準備ができました」というメッセージがキューに送信されます。
3. 次のステップで、ディスパッチを担当するサービスは、ディスパッチの準備状況に関するメッセージを受信し、ディスパッチタスクを作成して、「商品のディスパッチが計画されています」というメッセージを送信します。
4. 発送が計画されているというメッセージを受け取った次のサービスは、税関の事務処理のプロセスを開始します。

さらに、サービスによって受信された各メッセージは一意性がチェックされ、そのようなUUIDを持つメッセージがすでに処理されている場合、無視されます。



ここでは、各時点のデータベースベースはわずかに一貫性のない状態にあります。つまり、倉庫内の商品はすでに配送プロセスにあるとマークされていますが、配送タスク自体はまだ存在せず、数秒で表示されます。 しかし同時に、99.999％（実際、この数はキューサービスの信頼性のレベルに等しい）により、送信タスクが表示されることが保証されています。 ほとんどの企業では、これは受け入れられます。

そのときの記事は何ですか？

この記事では、マイクロサービスアプリケーションのトランザクションの問題を解決する別の方法について説明します。 マイクロサービスは、各サービスに独自のデータベースがある場合に最適に機能しますが、中小規模のシステムでは、原則としてすべてのデータが最新のリレーショナルデータベースに簡単に収まります。 これは、ほぼすべての内部エンタープライズシステムに当てはまります。 つまり、多くの場合、異なる物理マシン間でデータを厳密に共有する必要はありません。 同じデータベースのテーブルの無関係なグループに異なるマイクロサービスのデータを保存できます。 これは、古いモノリシックアプリケーションをサービスに分割し、コードを既に分割しているが、データがまだ1つのデータベースにある場合に特に便利です。 ただし、トランザクションの分割の問題は依然として残っています。トランザクションはネットワーク接続と、それに応じてこの接続を開いたプロセスに厳密に結び付けられており、別のプロセスがあります。 になる方法



上記では、問題を解決するいくつかの一般的な方法を説明しましたが、さらに、すべてのデータが同じデータベースにある特別な場合に別の方法を提供したいと思います。 このプロジェクトでこのメソッドを実装しようとすることはお勧めしませんが、記事で紹介するのは十分に興味があります。 突然、特定の場合に便利になります。



その本質は非常にシンプルです。 トランザクションはネットワーク接続に関連付けられており、データベースは、オープンネットワーク接続のその端に誰が座っているかを実際には知りません。 彼女は気にしません、主なことは正しいコマンドがソケットに送信されることです。 通常、ソケットはクライアント側の1つのプロセスに排他的に属していることは明らかですが、これを回避するには少なくとも3つの方法があります。

1.データベースコードを変更する

独自のデータベースアセンブリを作成してコードを変更できるデータベースのデータベースコードレベルでは、接続間でトランザクションを転送するためのメカニズムを実装します。 クライアントの観点からどのように機能するか：

1. トランザクションを開始し、いくつかの変更を行い、トランザクションを次のサービスに転送します。
2. DBにトランザクションのUUIDを提供し、N秒待機するように指示します。 この時間中にこのUUIDとの別の接続が来ない場合、トランザクションをロールバックし、もしそうなら、トランザクションに関連付けられたすべてのデータ構造を新しい接続に転送し、その作業を続けます。
3. UUIDを次のサービス（つまり、別のプロセス、場合によっては別のVM）に渡します。
4. その中で、接続を開き、DBコマンドを指定します-指定されたUUIDでトランザクションを続行します。
5. 別のプロセスによって開始されたトランザクションの一部として、データベースを引き続き使用します。

このメソッドは使用するのが最も軽量ですが、データベースコードの変更が必要です。アプリケーションプログラマは通常これを行わず、多くの特別なスキルが必要です。 ほとんどの場合、データベースプロセスとデータベース間でデータを転送する必要があります。データベースのコードは、全体として安全に変更できます-PostgreSQL。 さらに、これは管理されていないサーバーでのみ機能します。RDSやCloud SQLでは使用できません。



概略的には、次のようになります。

2.ソケットの操作

2番目に思い浮かぶのは、ソケットによるデータベース接続の微妙な操作です。 複数のクライアントからのコマンドを、データベースへの1つのコマンドストリーム内の特定のポートに向ける「リバースソケットプロキシ」を作成できます。



実際、このアプリケーションはpgBouncerと非常によく似ていますが、標準機能に加えて、クライアントからのバイトストリームを操作し、コマンドで1つのクライアントを別のクライアントに置き換えることができます。



私はこの方法を強く嫌います。その実装のために、サーバーとクライアントの間を循環するバイナリパケットをクリーンアップする必要があります。 そして、まだ多くのシステムプログラミングが必要です。 完全を期すためだけに持ってきました。

3.ゲートウェイJDBC

ゲートウェイJDBCドライバーを作成できます。特定のデータベース用の標準JDBCドライバーを使用し、PostgreSQLにします。 クラスをラップし、そのすべての外部メソッドへのHTTPインターフェイスを作成します（HTTPではなく、違いはわずかです）。 次に、別のJDBCドライバーを作成します。これは、すべてのメソッド呼び出しをJDBCゲートウェイにリダイレクトするファサードです。 つまり、実際には、既存のドライバーを2つに分け、これらの半分をネットワーク経由で接続しています。 次のコンポーネント図を取得します。







NB！：ご覧のとおり、3つのオプションはすべて類似しています。唯一の違いは、接続を転送するレベルと、これに使用するツールです。





その後、ドライバーに、方法1で説明したUUIDトランザクションで基本的に同じトリックを行うように指示します。



Javaアプリケーションコードでは、このメソッドの使用は次のようになります。

サービスA-トランザクションの開始

以下は、トランザクションを開始し、データベースに変更を加え、それを別のサービスに渡して完了するためのサービスのコードです。 コードでは、JDBCクラスを直接使用します。 もちろん、2019年には誰もこれを行いませんが、簡単にするために、コードは単純化されています。

//    , ,  “” //   Class.forName("org.postgresql.FacadeDriver"); var connection = DriverManager.getConnection( "jdbc:postgresqlfacade://hostname:port/dbname","username", "password"); //  -    statement = dbConnection.createStatement(); var statement.executeUpdate(“insert ...”); /* ,        . transactionUUID(int)  -,     ,   JDBC gateway-.  ResultSet        Varchar,  UUID.            .   ,         UUID.  60 —  ,    .        , , JDBCTemplate.      ResultSet */ var rs = statement.executeQuery(“select transactionUUID(60)”); String uuid = extractUUIDFromResultSet(rs); //      remoteServiceProxy.continueProcessing(uuid, otherParams); //          //     . closeEverything(); return;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスB-トランザクションの完了

 //     ,     // remoteServiceProxy.continueProcessing(...) //     . Class.forName("org.postgresql.FacadeDriver"); var connection = DriverManager.getConnection( "jdbc:postgresqlfacade://hostname:port/dbname","username", "password"); //     Gateway JDBC,    // .  continue transaction    ,   // gateway JDBC statement = dbConnection.createStatement(); statement.executeUpdate(“continue transaction ”+uuid); // ,    ,      //      statement.executeUpdate(“update ..."); //   connection.commit(); return;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のコンポーネントおよびフレームワークとの相互作用

このようなアーキテクチャソリューションの副作用の可能性を考慮してください。

接続プール

実際にはJDBCゲートウェイ内に実際の接続プールがあるので、サービス内の接続プールをオフにすると、別のサービスが使用できるサービス内の接続をキャプチャして保持するため、より適切です。



さらに、UUIDを受信して​​別のプロセスへの転送を待機した後、接続は基本的に動作不能になり、フロントエンドJDBCの観点からは自動的に閉じます。ゲートウェイJDBCの観点からは、誰にも与えずに保持する必要があります目的のUUIDが付属します。



つまり、ゲートウェイJDBCおよび各サービス内の接続プールの二重管理は、微妙で不快なエラーを引き起こす可能性があります。

JPA

JPAでは、2つの問題が考えられます。

1. トランザクション管理。 JPAをコミットするとき、エンジンはすべてのデータを保存したが、保存していないと考える場合があります。 ほとんどの場合、トランザクションを転送する前に手動でトランザクション管理とフラッシュ（）を行うことで問題を解決できます。
2. 2次キャッシュはほとんどの場合正しく動作しませんが、分散システムではその使用はいずれにせよ制限されます。

春のトランザクション

Springトランザクション管理メカニズムは、おそらく使用できないため、手動で管理する必要があります。 カスタムスコープを作成するなど、拡張できることはほぼ間違いありませんが、確かに、Spring Transactions拡張機能がどのように配置されているかを調べる必要がありますが、まだ検討していません。

長所と短所

長所

• ソーイング時に既存のモノリシックコードを変更する必要はありません。
• 実質的にコードを複雑にすることなく、複雑なクロスサーバートランザクションを記述できます。
• トランザクション実行のクロスサービストレースを実行できます。
• このソリューションは非常に柔軟です。配布が不要な従来のトランザクションを使用し、クロスサービスの相互作用が必要な操作に対してのみトランザクションを共有できます。
• プロジェクトチームは、新しいテクノロジを強制的に習得する必要はありません。 もちろん、新しい技術は優れていますが、タスク-必須かつ緊急です（昨日まで！）20人の開発者にリアクティブシステムの構築の概念を教えることは、非常に重要です。 ただし、20人全員が時間通りにトレーニングを完了するという保証はありません。

短所

• キューに入れられたソリューションとは対照的に、データベースレベルでスケーラブルでなく、実際には非モジュラーです。 すべてのクエリと負荷全体が収束する1つのデータベースがまだあります。 この意味で、ソリューションは行き詰まりです。後で負荷を増やしたり、データに応じてソリューションをモジュール化する場合は、すべてをやり直す必要があります。
• プロセス間、特にフレームワークで記述されたプロセス間でトランザクションを転送する場合は、非常に注意する必要があります。 セッションには独自の設定があり、さまざまなフレームワークでは、データベースとの接続が突然変更されると、誤動作が発生する可能性があります。 たとえば、PostgreSQLのセッション設定とトランザクションを参照してください。
• 地元の建築家のDataArtのチャットでアイデアを話したとき、同僚が私に最初に尋ねたのは、私が飲んでいるかどうか（いいえ、飲まない！） しかし、たとえば、このアイデアは最も普及しているものではなく、プロジェクトに実装すると、他の参加者にとっては非常に珍しいものになると思います。
• カスタムJDBCドライバーが必要です。 書き込みには時間がかかります。デバッグするか、ネットワーク通信エラーなどを含むエラーを探してください。

警告

もう一度警告します。このプロジェクトの自宅でこのトリックを繰り返そうとしないでください。なぜそれが必要なのかを明確に説明し、他に方法がないという説得力のある証拠がない限り。



4月1日からすべて！