JP2023543831A - マイクロサービスベースのサービスメッシュシステムおよびサービス指向アーキテクチャ管理方法 - Google Patents

Abstract

本出願は、データ処理技術の分野に関し、具体的には、マイクロサービスベースのサービスメッシュシステムおよびサービス指向アーキテクチャ管理方法に関する。システムは、第1のノードを含む。第1のノードは、第1のホストおよび第1のデータカードを含む。第1のデータカードは、第1のホストに挿入される。第1のデータカードと第1のホストとの間に第1のデータチャネルが確立される。第1のポッドは、第1のホスト上で動作する。第1のポッドには、第1のマイクロサービスが設けられる。第1のデータカードは、ネットワークにアクセスし、ネットワークを使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信し、サービス指向アーキテクチャ管理ポリシーに基づいて、第1のホストによって第1のデータチャネルを介して第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行する。第1のアクセス要求は、第2のマイクロサービスに対する第1のマイクロサービスのアクセス要求であり、第1のポッドから第1のホストによって取得される。システムは、ホストに挿入されたデータカードを使用することにより、ホストからのアクセス要求に対してサービス指向アーキテクチャ管理を実行し、それにより、ホストリソースを節約し、サービス指向アーキテクチャ管理効率を改善する。

Description

本出願は、データ処理分野に関し、具体的には、マイクロサービスベースのサービスメッシュシステムおよびサービス指向アーキテクチャおよびサービス指向アーキテクチャ指向アーキテクチャ管理方法に関する。

サービスメッシュ（service mesh）技術は、従来のインターネットプロトコル（internet protocol，IP）ネットワークに基づくアプリケーションネットワーク技術である。サービスメッシュ技術に基づいて、サービス間の発見およびルーティングは、IPアドレスに直接基づくのではなく、サービスメタデータ情報（サービス名およびサービスバージョンを含むがこれらに限定されない）に基づく。サービスメッシュ技術は、マイクロサービスアーキテクチャ（microservice architecture）における分散アプリケーションの非機能サービス指向アーキテクチャ管理ロジックをサービスプロセスからサイドカー（sidecar）に分離し、サービス間の接続、セキュリティ、フロー制御、グレーリリース、および観測機能を非侵入的に提供して、軽量サービスおよびインフラストラクチャベースのサービス指向アーキテクチャ管理を実装する。

ユーザ要件の発展に伴い、マイクロサービス規模およびマイクロサービス呼び出しの複雑さが急速に増大している。連続的な実行段階においてマイクロサービスを効率的に管理する方法は、サービスメッシュ技術の進化において重要な問題である。

本出願の実施形態は、ホストとは独立したデータカードを使用することによってアクセス要求に対してサービス指向アーキテクチャ管理を実行するために、マイクロサービスベースのサービスメッシュシステムおよびサービス指向アーキテクチャ管理方法を提供し、それによってホストリソースを節約し、サービス指向アーキテクチャ管理効率を改善する。

第1の態様によれば、本出願の一実施形態は、第1のノードを含むマイクロサービスベースのサービスメッシュシステムを提供する。第1のノードは、第1のホストおよび第1のデータカードを含む。第1のデータカードは、第1のホストに挿入される。第1のデータカードと第1のホストとの間に第1のデータチャネルが確立される。第1のポッドは、第1のホスト上で動作する。第1のポッドには、第1のマイクロサービスが設けられる。第1のデータカードは、ネットワークにアクセスし、ネットワークを使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信し、サービス指向アーキテクチャ管理ポリシーに基づいて、第1のホストによって第1のデータチャネルを介して第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行する。第1のアクセス要求は、第2のマイクロサービスに対する第1のマイクロサービスのアクセス要求であり、第1のポッドから第1のホストによって取得される。

言い換えれば、サービスメッシュシステム内のノードは、ホストの周辺デバイスを使用することによってアクセス要求に対してサービス指向アーキテクチャ管理を実行することができ、それによって、アクセス要求に対するサービス指向アーキテクチャ管理がホストリソースを占有するのを防ぎ、サービス指向アーキテクチャ管理効率を改善する。

1つの可能な実施態様では、サービス指向アーキテクチャ管理ポリシーは、第2のマイクロサービスと、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含む。第1のデータカードは、サービス指向アーキテクチャ管理ポリシーに基づいて、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスを決定し、第1のアクセス要求の宛先アドレスを第2のポッドのネットワークアドレスに設定し、第2のポッドが第1のホストに配置されていると決定し、第1のデータチャネルを介して第2のポッドに修正された第1のアクセス要求を送信するように構成される。

言い換えれば、本実施態様では、データカードは、同じノード上の異なるマイクロサービス間の呼び出しに対してサービス指向アーキテクチャ管理を実行することができる。

1つの可能な実施態様では、サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含む。第1のホストは、第1のポッドから、第3のマイクロサービスに対する第1のマイクロサービスの第2のアクセス要求を取得し、第1のデータチャネルを介して第1のデータカードに第2のアクセス要求を送信するようにさらに構成される。第1のデータカードは、サービス指向アーキテクチャ管理ポリシーに基づいて、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスを決定し、第2のアクセス要求の宛先アドレスを第3のポッドのネットワークアドレスに設定し、第3のポッドが第1のホストに配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信するように構成される。

言い換えれば、本実施態様では、データカードは、異なるノード上のマイクロサービス間の呼び出しに対してサービス指向アーキテクチャ管理を実行することができる。

1つの可能な実施態様では、第1のノードは、第1のネットワークインターフェースカードをさらに含む。第1のネットワークインターフェースカードは、第1のデータカードに接続されている。第1のデータカードは、第1のネットワークインターフェースカードを使用することによってネットワークにアクセスする。第1のデータカードは、第2のアクセス要求を第1のネットワークインターフェースカードに送信するように構成される。第1のネットワークインターフェースカードは、ネットワークを使用することによって第2のアクセス要求を送信するように構成される。

言い換えれば、本実施態様では、データカードは、特別に配置されたネットワークインターフェースカードを使用することによってネットワークと情報を交換することができ、それにより、データカードと外部との間の情報交換によって引き起こされるデータカードリソースのオーバーヘッドを低減する。

1つの可能な実施態様では、サービスメッシュシステムは、第2のノードをさらに含む。第2のノードは、第2のホストと、第2のデータカードと、第2のネットワークインターフェースカードとを含む。第2のデータカードは、第2のホストに挿入される。第2のデータカードと第2のホストとの間に第2のデータチャネルが確立される。第3のポッドは、第2のホスト上で動作する。第2のネットワークインターフェースカードは、第2のデータカードに接続されている。第2のネットワークインターフェースカードは、ネットワークにアクセスする。第1のデータカードは、第3のポッドが第1のホストに配置されていないと決定した場合、第2のアクセス要求に対してサービスメッシュ識別子を設定するようにさらに構成される。第2のネットワークインターフェースカードは、第1のネットワークインターフェースカードによって送信された第2のアクセス要求を受信し、第2のアクセス要求がサービスメッシュ識別子を搬送していると決定した場合、第2のデータカードに第2のアクセス要求を送信するように構成される。第2のデータカードは、第3のポッドが第2のホスト上に配置されていると決定した場合、第2のデータチャネルを介して第3のポッドに第2のアクセス要求を送信するように構成される。

言い換えれば、本実施態様では、第1のデータカードは、マイクロサービスへのアクセスを要求するために使用されるアクセス要求に対してサービスメッシュ識別子を追加することができる。したがって、ピアデバイスは、アクセス要求がサービスメッシュ識別子を搬送しているかどうかに基づいて、アクセス要求がマイクロサービスにアクセスするために使用されるかどうかを迅速に決定することができる。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストを含む。第3のホストおよび第1のホストは、ネットワークにアクセスする。第1のアプリケーションは、第1のホスト上で動作する。第2のアプリケーションは、第3のホスト上で動作する。第1のホストは、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションが第1のホスト上で動作していないと決定した場合、ネットワークを使用することによって第3のアクセス要求を送信するように構成される。第3のホストは、第1のホストによって送信された第3のアクセス要求を受信し、第3のアクセス要求を第2のアプリケーションに送信するように構成される。

言い換えれば、本実施態様では、サービスメッシュシステムは、異なるノード上の共通アプリケーション間の呼び出しを実装することができる。

1つの可能な実施態様では、第1のアプリケーションおよび第2のアプリケーションは、第1のホスト上で動作する。第1のホストは、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションが第1のホスト上で動作していると決定した場合、第3のアクセス要求を第2のアプリケーションに送信するように構成される。

言い換えれば、本実施態様では、サービスメッシュシステムは、同じノード上の異なる共通アプリケーション間の呼び出しを実装することができる。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストおよび第3のデータカードを含む。第3のデータカードは、第3のホストに挿入される。第3のデータカードと第3のホストとの間に第3のデータチャネルが確立される。第4のポッドは、第3のホスト上で動作する。第4のポッドには、第4のマイクロサービスが設けられる。第3のデータカードおよび第1のホストは、ネットワークにアクセスする。第1のアプリケーションは、第1のホスト上で動作する。第1のホストは、第3のデータカードのネットワークアドレスに対する第1のアプリケーションの第4のアクセス要求を取得し、ネットワークを使用することによって第4のアクセス要求を送信するように構成される。第3のデータカードは、第1のホストによって送信された第4のアクセス要求を受信し、第4のマイクロサービスのものである、第4のアクセス要求で搬送された識別子に基づいて、第3のデータチャネルを介して第4のマイクロサービスに第4のアクセス要求を送信するように構成される。

言い換えれば、本実施態様では、サービスメッシュシステムは、データカードを使用することによってマイクロサービスの共通アプリケーションの呼び出しを実装することができる。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストを含む。第3のアプリケーションは、第3のホスト上で動作する。第3のホストは、ネットワークにアクセスする。第1のホストは、第3のアプリケーションのネットワークアドレスに対する第1のマイクロサービスの第5のアクセス要求を取得し、第1のデータチャネルを介して第1のデータカードに第5のアクセス要求を送信するように構成される。第1のデータカードは、ネットワークを使用することによって第5のアクセス要求を送信するように構成される。第3のホストは、第5のアクセス要求を受信し、第5のアクセス要求を第3のアプリケーションに送信するように構成される。

言い換えれば、本実施態様では、サービスメッシュシステムは、データカードを使用することによって共通アプリケーションのマイクロサービスの呼び出しを実装することができる。

第2の態様によれば、本出願の一実施形態は、マイクロサービスベースのサービス指向アーキテクチャ管理方法を提供する。本方法は、マイクロサービスベースのサービスメッシュシステムに適用される。サービスメッシュシステムは、第1のノードを含む。第1のノードは、第1のホストおよび第1のデータカードを含む。第1のデータカードは、第1のホストに挿入される。第1のデータカードと第1のホストとの間に第1のデータチャネルが確立される。第1のポッドは、第1のホスト上で動作する。第1のポッドには、第1のマイクロサービスが設けられる。第1のデータカードは、ネットワークにアクセスする。本方法は、第1のデータカードが、ネットワークを使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信することを含む。第1のデータカードは、サービス指向アーキテクチャ管理ポリシーに基づいて、第1のホストによって第1のデータチャネルを介して第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行する。第1のアクセス要求は、第2のマイクロサービスに対する第1のマイクロサービスのアクセス要求であり、第1のポッドから第1のホストによって取得される。

1つの可能な実施態様では、サービス指向アーキテクチャ管理ポリシーは、第2のマイクロサービスと、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含む。第1のデータカードが、サービス指向アーキテクチャ管理ポリシーに基づいて、第1のホストによって第1のデータチャネルを介して第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行することは、第1のデータカードが、サービス指向アーキテクチャ管理ポリシーに基づいて、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスを決定し、第1のアクセス要求の宛先アドレスを第2のポッドのネットワークアドレスに設定することを含む。第1のデータカードは、第2のポッドが第1のホスト上に配置されていると決定し、第1のデータチャネルを介して第2のポッドに修正された第1のアクセス要求を送信する。

1つの可能な実施態様では、サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含む。本方法は、第1のホストが、第1のポッドから、第3のマイクロサービスに対する第1のマイクロサービスの第2のアクセス要求を取得し、第1のデータチャネルを介して第1のデータカードに第2のアクセス要求を送信することをさらに含む。第1のデータカードは、サービス指向アーキテクチャ管理ポリシーに基づいて、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスを決定し、第2のアクセス要求の宛先アドレスを第3のポッドのネットワークアドレスに設定する。第1のデータカードは、第3のポッドが第1のホスト上に配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信する。

1つの可能な実施態様では、第1のノードは、第1のネットワークインターフェースカードをさらに含む。第1のネットワークインターフェースカードは、第1のデータカードに接続されている。第1のデータカードは、第1のネットワークインターフェースカードを使用することによってネットワークにアクセスする。第1のデータカードが、第3のポッドが第1のホスト上に配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信することは、第1のデータカードが、第3のポッドが第1のホスト上に配置されていないと決定し、第2のアクセス要求を第1のネットワークインターフェースカードに送信することを含む。第1のネットワークインターフェースカードは、ネットワークを使用することによって第2のアクセス要求を送信する。

1つの可能な実施態様では、サービスメッシュシステムは、第2のノードをさらに含む。第2のノードは、第2のホストと、第2のデータカードと、第2のネットワークインターフェースカードとを含む。第2のデータカードは、第2のホストに挿入される。第2のデータカードと第2のホストとの間に第2のデータチャネルが確立される。第3のポッドは、第2のホスト上で動作する。第2のネットワークインターフェースカードは、第2のデータカードに接続されている。第2のネットワークインターフェースカードは、ネットワークにアクセスする。本方法は、第3のポッドが第1のホスト上に配置されていないと決定した場合に、第1のデータカードが第2のアクセス要求のサービスメッシュ識別子を設定することをさらに含む。第2のネットワークインターフェースカードは、第1のネットワークインターフェースカードによって送信された第2のアクセス要求を受信し、第2のアクセス要求がサービスメッシュ識別子を搬送していると決定した場合、第2のデータカードに第2のアクセス要求を送信する。第2のデータカードは、第3のポッドが第2のホスト上に配置されていると決定した場合、第2のデータチャネルを介して第3のポッドに第2のアクセス要求を送信する。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストを含む。第3のホストおよび第1のホストは、ネットワークにアクセスする。第1のアプリケーションは、第1のホスト上で動作する。第2のアプリケーションは、第3のホスト上で動作する。本方法は、第1のホストが、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションが第1のホスト上で動作していないと決定した場合に、ネットワークを使用することによって第3のアクセス要求を送信することをさらに含む。第3のホストは、第1のホストによって送信された第3のアクセス要求を受信し、第3のアクセス要求を第2のアプリケーションに送信する。

1つの可能な実施態様では、第1のアプリケーションおよび第2のアプリケーションは、第1のホスト上で動作する。本方法は、第1のホストが、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションが第1のホスト上で動作していると決定した場合に、第3のアクセス要求を第2のアプリケーションに送信することをさらに含む。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストおよび第3のデータカードを含む。第3のデータカードは、第3のホストに挿入される。第3のデータカードと第3のホストとの間に第3のデータチャネルが確立される。第4のポッドは、第3のホスト上で動作する。第4のポッドには、第4のマイクロサービスが設けられる。第3のデータカードおよび第1のホストは、ネットワークにアクセスする。第1のアプリケーションは、第1のホスト上で動作する。本方法は、第1のホストが、第3のデータカードのネットワークアドレスに対する第1のアプリケーションの第4のアクセス要求を取得し、ネットワークを使用することによって第4のアクセス要求を送信することをさらに含む。第3のデータカードは、第1のホストによって送信された第4のアクセス要求を受信し、第4のマイクロサービスのものである、第4のアクセス要求で搬送された識別子に基づいて、第3のデータチャネルを介して第4のマイクロサービスに第4のアクセス要求を送信する。

1つの可能な実施態様では、サービスメッシュシステムは、第3のノードをさらに含む。第3のノードは、第3のホストを含む。第3のアプリケーションは、第3のホスト上で動作する。第3のホストは、ネットワークにアクセスする。本方法は、第1のホストが、第3のアプリケーションのネットワークアドレスに対する第1のマイクロサービスの第5のアクセス要求を取得し、第1のデータチャネルを介して第1のデータカードに第5のアクセス要求を送信することをさらに含む。第1のデータカードは、ネットワークを使用することによって第5のアクセス要求を送信する。第3のホストは、第5のアクセス要求を受信し、第5のアクセス要求を第3のアプリケーションに送信する。

第2の態様で提供されるサービス指向アーキテクチャ管理方法は、第1の態様で提供されるサービスメッシュシステム内のノードによって実行される方法であることが理解されよう。したがって、サービス指向アーキテクチャ管理方法によって達成され得る有益な効果については、前述の対応する有益な効果を参照されたい。

第3の態様によれば、本出願の一実施形態は、ホストおよびデータカードを含むネットワークノードを提供する。データカードはホストに挿入される。ホストは、第1のプロセッサおよび第1のメモリを含む。第1のメモリは、第1のコンピュータ命令を記憶するように構成される。データカードは、第2のプロセッサおよび第2のメモリを含む。第2のメモリは、第2のコンピュータ命令を記憶するように構成される。ネットワークノードが動作すると、第1のプロセッサは第1のコンピュータ命令を実行し、第2のプロセッサは第2のコンピュータ命令を実行し、その結果、ネットワークノードは第2の態様で提供される方法を実行する。

第4の態様によれば、本出願の一実施形態は、コンピュータ記憶媒体を提供する。コンピュータ記憶媒体は、コンピュータ命令を含み、コンピュータ命令がネットワークノード上で実行されると、ネットワークノードは、第2の態様で提供される方法を実行することが可能になる。

第5の態様によると、本出願の一実施形態はコンピュータプログラム製品を提供する。コンピュータプログラム製品に含まれるプログラムコードがネットワークノードで使用されるプロセッサによって実行されると、第1の態様で提供される方法が実施される。

本出願の実施形態で提供されるサービスメッシュシステムおよびサービス指向アーキテクチャ管理方法によれば、独立して計算することができるデータカードを使用して、サービスを呼び出すために使用されるアクセス要求に対してサービス指向アーキテクチャ管理を実行することができ、その結果、サービス指向アーキテクチャ管理はもはやホストのコンピューティング資源を占有せず、それによってホストのコンピューティング資源を節約し、サービス指向アーキテクチャ管理効率を改善する。

サービス指向アーキテクチャ管理フレームワークを示す。 サービスメッシュシステムを示す。 サービスメッシュシステムを示す。 本出願の一実施形態によるサービスメッシュシステムを示す。 図4に示されるサービスメッシュシステムに基づくアプリケーション呼び出しのフローチャートである。 図4に示されるサービスメッシュシステムに基づくアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるノード初期化のフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるアプリケーション呼び出しのフローチャートである。 本出願の一実施形態によるサービス指向アーキテクチャ管理方法のフローチャートである。 本出願の一実施形態によるネットワークノードの概略ブロック図である。

以下、本発明の実施形態における技術的解決策を、添付の図面を参照して説明する。説明される実施形態は、本明細書の実施形態のすべてではなく、単なる一部にすぎないことは明らかである。

本明細書の説明において、「一実施形態」、「いくつかの実施形態」などへの言及は、本明細書の1つまたは複数の実施形態が、実施形態を参照して説明される特定の特徴、構造、または特性を含むことを示す。したがって、本明細書の異なる箇所に現れる「一実施形態では」、「いくつかの実施形態では」、「いくつかの他の実施形態では」、および「さらにいくつかの他の実施形態では」などの記述は、別の方法で特に強調されない限り、必ずしも同じ実施形態を指すものではなく、「すべてではないが1つまたは複数の実施形態」を意味する。

本明細書の説明では、特に明記しない限り、「／」は「または」を意味する。例えば、A／Bは、AまたはBを表し得る。本明細書では、「および／または」は、関連する対象間の関連関係のみを記述し、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、Aのみが存在する、AとBの両方が存在する、およびBのみが存在する、という3つの場合を表し得る。加えて、本明細書の実施形態の説明において、「複数の」は、2つまたは3つ以上を意味する。

本明細書の説明では、「第1」および「第2」という用語は単に説明を意図しており、相対的重要性の表示または含意、あるいは示された技術的特徴の数量の暗示的な表示として理解されるべきではない。したがって、「第1の」または「第2の」によって限定される特徴は、1つまたは複数の特徴を明示的または暗示的に含む場合がある。「含む」、「含有する」、「有する」という用語、およびそれらの変形はいずれも、別のやり方で具体的に強調される場合を除き、「含み、ただし限定されない」を意味する。

マイクロサービスアーキテクチャは、複雑なシステムを複数の小さなサービスまたはアプリケーションに分割するサービス指向アーキテクチャ（service oriented architecture，SOA）である。小さなサービスまたはアプリケーションは、マイクロサービスと呼ばれ得る。各マイクロサービスは、独立したサービスロジックを実装する役割を担う。マイクロサービスは、サービス機能に基づいて構築され、独立して展開され得る。マイクロサービスは、一連の機能を提供するために互いに依存している。マイクロサービスは、容易に理解および変更され、言語およびフレームワークの選択に柔軟性を提供する。

マイクロサービスアーキテクチャでは、SOA管理（service oriented architecture governance，SOA governance）とも呼ばれるサービス指向アーキテクチャ管理は、マイクロサービスアーキテクチャの採用および実装を管理するために使用されるプロセスである。

図1は、ソフトウェア開発キット（software development kit，SDK）に基づくサービス指向アーキテクチャ管理フレームワークを示す。フレームワークの典型的な用途は、springcloudおよびdubboを含む。このフレームワークでは、クライアント（client）またはサーバ（server）が、サービス指向アーキテクチャ管理機能を提供する。サービス指向アーキテクチャ管理機能は、通常、SDKによって実装される。フレームワークの開発段階では、フレームワークによって提供されるSDKを使用してクライアントまたはサーバを開発する必要がある。一般に、フレームワークの開発は、特定のプログラミング言語、例えばJavaのみをサポートする。フレームワークは、高性能および容易なデバッグを特徴とする。しかしながら、別のプログラミング言語の既存のクライアントまたはサーバはフレームワークに含まれ得ず、フレームワークを再構築することは困難であるため、侵入的な再構築が必要である。その結果、不必要なリスクや開発コストが引き起こされる。

図2は、コンテナクラスタの自動配備、自動スケーリング、および保守などの機能を実施することができるシステムを示す。コンテナを使用して、マイクロサービスを配備または設定することができる。

図2に示されるシステムは、アプリケーションまたはマイクロサービスのプロキシとしてPodレベルサイドカー（sidecar）を使用し、例えば、リンク暗号化、回路遮断器、トラフィック制限、グレーリリース、またはリンクトレースなど、ユーザに透過的なサービス指向アーキテクチャ管理機能を提供することができる。従来のネットワークプロキシとは異なり、Istioは、カーネルまたはハードウェア層でターゲットIPアドレスに対して負荷分散処理を単に実行するのではなく、サイドカーがターゲットサービスの発見および負荷分散を担当する。発呼側は、サービスの仮想アドレスまたは論理アドレスにアクセスするだけでよい。サイドカーは、サービスメタデータを実際にアクセス可能なネットワークアドレスに変換する方法を決定し、ネットワークアドレスに基づいて呼び出されたマイクロサービスにトラフィックを送信する。

図3は、Podレベルのサイドカーを展開することができる、またはノード（node）レベルのサイドカーを展開することができるシステムを示す。

図2に示されているシステムまたは図3に示されているシステムにかかわらず、サイドカーは、透過的なサービス指向アーキテクチャ管理機能をもたらし、また、過剰なホストリソース（例えば、CPUおよびメモリ）を占有する。特にパブリッククラウド環境では、大量のPodを配備する必要があり、これはホストリソースの余分なオーバーヘッドをもたらす。サービスがビジーである場合、サイドカーおよびマイクロサービスは、互いにリソースを先取りし得る。CPUに過負荷がかかると、入力／出力（I／O）を適時に処理することができない。その結果、サイドカーに輻輳が発生する可能性があり、リンク全体の遅延が増加する。

本出願の一実施形態は、マイクロサービスベースのサービスメッシュシステムを提供する。図4を参照されたい。サービスメッシュシステムは、ノード100を含むことができる。ノード100は、ホスト110、データカード120、およびネットワークインターフェースカード130を含むことができる。

ホスト110は、物理マシン、例えばサーバであってもよい。ホスト110上では、1つまたは複数のポッドが動作してもよい。各ポッドは、1つまたは複数の容器（container）を含むことができる。例えば、ポッドはK8sのPodであってもよい。ホスト110上には、1つまたは複数のマイクロサービスが配置されてもよい。各マイクロサービスは、ポッド内で設定または実行されてもよい。マイクロサービスは、マイクロサービスアプリケーションとも呼ばれ、独立したサービスロジックを実装することができる。複数のマイクロサービスは、呼び出しおよび呼び出し関係に基づいて対応するサービス機能を提供することができる。

データカード120は、独立したコンピューティングリソースを有するハードウェアデバイスである。例えば、データカード120は、専用のプロセッサ、専用のメモリなどを有する。例えば、データカード120は、ソフトウェア定義インフラストラクチャ（software defined infrastructure，SDI）であってもよい。データカード120は、SDIデータカードと呼ばれることもある。データカード120は、ホスト110の周辺機器として使用されてもよく、ホスト110に挿入される。データカード120は、ホスト110からのアクセス要求に対してサービス指向アーキテクチャ管理を実行することができる。例えば、ホスト110上のマイクロサービスに対応するサイドカーをデータカード120上に配備することができ、その結果、データカード120はサイドカーとして機能することができる。データカード120のコンピューティングリソースはホスト110のコンピューティングリソースから独立しているため、データカード120はサイドカーの役割を果たし、それにより、サービス指向アーキテクチャ管理を実行するときにサイドカーがホスト110のコンピューティングリソースを先取りするのを防ぐ。加えて、近くのデータカード120のコンピューティングリソースは、サイドカーの実行中に使用されてもよく、その結果、サービス指向アーキテクチャ管理効率が改善され得、ネットワーク遅延が低減され得る。

図4に示されるように、ホスト110とデータカード120との間にデータチャネル140が確立される。ホスト110は、データチャネル140を介してデータカード120にサービス指向アーキテクチャ管理を実行する必要があるアクセス要求を送信することができ、それにより、データカード120はアクセス要求に対して、例えば暗号化および負荷分散などのサービス指向アーキテクチャ管理を実行する。例えば、データチャネル140は、ペリフェラル・コンポネント・インタコネクト・エクスプレス（peripheral component interconnect express，PCIe）バスであってもよく、またはデータチャネル140はPCIeバス上で搬送される。一例では、データチャネル140は、遠隔直接メモリアクセス（remote direct memory access，RDMA）技術に基づいて、ホスト110によって送信されたアクセス要求を受信することができる。具体的には、ホスト110は、データチャネル140を介してデータカード120の記憶領域にアクセス要求を直接送信することができる。したがって、ホストとデータカードとの間の高速データ送信が実施され、ネットワーク遅延がさらに低減される。

ネットワークインターフェースカード130は、ネットワーク300にアクセスして、ネットワーク300にデータを送信し、ネットワーク300からデータを取得する。ネットワークインターフェースカード130は、ホスト110およびデータカード120に別々に通信可能に接続することができ、その結果、ネットワークインターフェースカード130は、ホスト110またはデータカード120から取得したデータをネットワーク300に送信し、ネットワーク300から取得したデータをホスト110またはデータカード120に送信することができる。例えば、ネットワークインターフェースカード130は、ホスト110に挿入される周辺機器であってもよい。一例では、ネットワークインターフェースカード130は、具体的にはSDIである。ネットワークインターフェースカード130は、SDIネットワークインターフェースカードとも呼ばれ得る。

いくつかの実施形態では、ネットワークインターフェースカード130およびデータカード120は、2つの独立したハードウェアカードまたはハードウェア装置であってもよい。いくつかの実施形態では、ネットワークインターフェースカード130およびデータカード120は、1つのハードウェアカードまたはハードウェア装置上に配置されてもよい。

いくつかの実施形態では、図4をさらに参照する。サービスメッシュシステムは、ノード200をさらに含むことができる。ノード200に含まれるホスト210、データカード220、ネットワークインターフェースカード230、およびデータチャネル240については、ホスト110、データカード120、ネットワークインターフェースカード130、およびデータチャネル140の上記の実装を参照されたい。ここでは詳細を繰り返さない。

サービスメッシュシステムは、より多くのノードをさらに含むことができる。各ノードについては、ノード100の実装を参照されたい。ここでは詳細を繰り返さない。

以上、本出願の本実施形態で提供されるサービスメッシュシステムの構造の一例について説明した。次に、異なる実施形態において、サービスメッシュシステムにおけるモジュールまたはコンポーネントの機能の一例について説明する。

図5Aおよび図5Bは、図4に示されるサービスメッシュシステムに基づくアプリケーション呼び出しのフローチャートである。

図5Aおよび図5Bに示されるように、ホスト110には、1つまたは複数のポッドが配置されてもよい。具体的には、ホスト110のオペレーティングシステム（例えば、Linux（登録商標））は、ユーザ空間とシステムカーネルとに分割されてもよい。1つまたは複数のポッドは、ユーザ空間内で動作することができる。1つまたは複数のポッドは、ポッド111およびポッド112を含んでもよい。ポッド111には、マイクロサービス1111およびネットワークポート1112が配置されている。マイクロサービス1111は、別のマイクロサービスまたはアプリケーションによって提供されるサービスを呼び出すために、アクセス要求を生成することができる。マイクロサービス1111によって提供されるサービスは、他のマイクロサービスまたはアプリケーションによって呼び出されてもよい。マイクロサービス1111は、ネットワークポート1112を介して外部にデータを送信したり、外部からデータを受信したりすることができる。ポッド112には、マイクロサービス1121およびネットワークポート1122が配置されている。マイクロサービス1121は、別のマイクロサービスまたはアプリケーションによって提供されるサービスを呼び出すために、アクセス要求を生成することができる。マイクロサービス1121によって提供されるサービスは、他のマイクロサービスまたはアプリケーションによって呼び出されてもよい。マイクロサービス1121は、ネットワークポート1122を介して外部にデータを送信したり、外部からデータを受信したりすることができる。

ホスト110には、共通アプリケーション113がさらに配置されてもよい。共通アプリケーションは、マイクロサービス以外のアプリケーション、例えば、セキュアシェルプロトコル（secure shell protocol，SSH）に基づくアプリケーションであってもよいし、リモートターミナルプロトコル（telnettelnet，telnet）に基づくアプリケーションであってもよい。共通アプリケーション113は、マイクロサービスが提供するサービスを呼び出してもよいし、他の共通アプリケーションを呼び出してもよい。共通アプリケーション113が提供するサービスは、マイクロサービスまたは他の共通アプリケーションから呼び出されてもよい。本出願のこの実施形態では、共通アプリケーションは、共通サービスと呼ばれることもある。

トラフィック遮断モジュール114は、ホスト110内にさらに配置されてもよい。トラフィック遮断モジュール114は、サービス指向アーキテクチャ管理を実行する必要があるアクセス要求を選択し、サービス指向アーキテクチャ管理を実行する必要があるアクセス要求をデータチャネル140を介してデータカード120に送信することができる。トラフィック遮断モジュール114は、システムカーネルに配置されてもよい。

具体的には、ホスト110上のマイクロサービスによって生成されたアクセス要求は、サービス識別子を含むことができる。アクセス要求は、ターゲットアプリケーションがアクセス要求を生成するマイクロサービスにサービスを提供するように、アクセス要求とアクセス要求のターゲットアプリケーションとの間のネットワーク接続を確立するように要求するために使用される。アクセス要求のターゲットアプリケーションは、他のマイクロサービスであってもよいし、共通アプリケーションであってもよい。一般に、サービス識別子は論理アドレスまたは記述情報であってもよく、特定のマイクロサービスまたはアプリケーションのネットワークアドレスではなく、またはマイクロサービスまたはアプリケーションを実行しているポッドのネットワークアドレスではない。サービス識別子は、サービスを記述または識別するために使用され得る。言い換えれば、サービス識別子は、サービス識別子が位置するアクセス要求によって要求されたサービスを記述または表すために使用される。一例では、サービス識別子は、サービス名、サービスバージョン番号などを含むことができる。一例では、サービス識別子は、アクセス要求に対してサービス指向アーキテクチャ管理を実行する必要があることを宣言または指示するために使用される事前設定情報であってもよい。トラフィック遮断モジュール114は、複数のサービス識別子を含む管理必須リストを有することができる。例えば、トラフィック遮断モジュール114は、制御プレーンプロキシから管理必須リストを取得することができる。制御プレーンプロキシにおける管理必須リストは、制御プレーンから取得され得る。一例では、管理必須リストは、制御プレーンプロキシによって生成され得る。別の例では、サービスメッシュシステムの開発者または運用および保守担当者は、制御プレーンで管理必須リストを構成することができる。

加えて、サービス指向アーキテクチャ管理が実行される必要があるアクセス要求に対してサービス指向アーキテクチャ管理が実行される前に、アクセス要求のターゲットアプリケーションは実際には決定されないことが理解されよう。サービス指向アーキテクチャ管理の動作は、アクセス要求内のサービス識別子に基づいてアクセス要求のターゲットアプリケーションを決定することである。

トラフィック遮断モジュール114は、ホスト110のユーザ空間からアクセス要求を取得し、アクセス要求内のサービス識別子が管理必須リスト内に位置するかどうかを決定する。アクセス要求内のサービス識別子が、管理必須リスト内に位置する場合、アクセス要求は、サービス指向アーキテクチャ管理が実行される必要があるアクセス要求であると決定することができ、アクセス要求は、データカード120に送信される。アクセス要求内のサービス識別子が、管理必須リストに位置していない場合、アクセス要求に対してサービス指向アーキテクチャ管理を実行する必要がないと決定することができ、アクセス要求は、ネットワークインターフェースカード130を使用することによってネットワーク300に直接送信することができ、その結果、アクセス要求は、ネットワーク300を使用することによって対応するノードに送信される。例えば、アクセス要求内のサービス識別子は、共通アプリケーションのネットワークアドレスであってもよく、ネットワークアドレスは、管理必須リスト内に位置しない。ネットワークインターフェースカード130は、ネットワークアドレスに基づいて対応するアプリケーションにサービス要求を直接送信することができる。

図5Aおよび図5Bをさらに参照する。データカード120は、通信プロキシ121、ユーザモードプロトコルスタック122、および制御プレーンプロキシ123を含むことができる。通信プロキシ121は、アクセス要求に対してサービス指向アーキテクチャ管理を実行し、例えば、アクセス要求を暗号化／復号し、アクセス要求によって要求されたサービスを提供するマイクロサービスまたはアプリケーションを決定することができる。例えば、通信プロキシ121は、サイドカーであってもよいし、サイドカーの機能を有していてもよい。より具体的には、一例では、通信プロキシ121は、K8sシステムにおけるサイドカーであってもよいし、K8sシステムにおけるサイドカーの機能を有してもよい。

ユーザモードプロトコルスタック122は、アクセス要求を通信プロキシ121に転送し、通信プロキシ121によって送信されたアクセス要求を別のモジュールまたはコンポーネントに転送するように構成されてもよい。ユーザモードプロトコルスタック122の特定の機能は、以下の特定の実施形態で説明される。ここでは詳細を繰り返さない。

ノード200は、ホスト210、データカード220、ネットワークインターフェースカード230、およびデータチャネル240を含む。ホスト210のユーザ空間側には、共通アプリケーション211、共通アプリケーション212、ポッド213、ポッド214が配置されている。ポッド213には、特別なマイクロサービス2131およびネットワークポート2132が配置されている。ポッド214には、特別なマイクロサービス2141およびネットワークポート2142が配置されている。トラフィック遮断モジュール215は、ホスト210のシステムカーネル側に配置される。データカード220は、通信プロキシ221、ユーザモードプロトコルスタック222、制御プレーンプロキシ223などを備えることができる。ノード200内のコンポーネントまたはモジュールの機能については、ノード100内の対応するコンポーネントまたはモジュールの前述の説明を参照されたい。ここでは詳細を繰り返さない。

サービスメッシュシステムが起動された後、サービスメッシュシステム内のノードを初期化することができる。図6を参照されたい。ノード100は一例として使用され、ノード100の初期化は以下のステップを含むことができる。

制御プレーンプロキシ123は、制御プレーンプロキシのインバウンドトラフィックおよびアウトバウンドトラフィックを遮断しないという指示をユーザモードプロトコルスタック122に送信するステップ601を実行することができる。制御プレーンプロキシ123のインバウンドトラフィックおよびアウトバウンドトラフィックは、制御プレーンプロキシ123によって送信されたデータおよび制御プレーンプロキシ123によって受信されたデータである。この指示は、制御プレーンプロキシのユーザ識別情報（user identity，UID）を含む。ユーザモードプロトコルスタック122は、制御プレーンプロキシのユーザ識別情報に基づいて、制御プレーンプロキシによって送信されたトラフィック（またはデータ）を遮断せず、制御プレーンに送信されたトラフィックを遮断しない場合がある。言い換えれば、ユーザモードプロトコルスタック122は、制御プレーンプロキシのユーザ識別情報に基づいて制御プレーンプロキシのインバウンドおよびアウトバウンドトラフィックを識別することができ、したがって、制御プレーンプロキシ123のインバウンドおよびアウトバウンドトラフィックを遮断することができないので、制御プレーンプロキシ123のインバウンドおよびアウトバウンドトラフィックは、ユーザモードプロトコルスタック122を自由に通過することができる。

制御プレーンプロキシ123は、制御プレーン400によって送信されたサービスリスト、サービス指向アーキテクチャ管理ポリシー、および特別なマイクロサービスリストを受信するステップ602を実行することができる。

制御プレーン400は、サービスメッシュにおける制御プレーンである。制御プレーン400は、管理および制御ノードと呼ばれてもよい。あるいは、制御プレーン400は、管理および制御ノード上で動作し、制御および管理機能を有するプログラムまたはモジュールであってもよい。

サービスリストは、サービス識別子と、サービス識別子に対応するサービスを提供することができるマイクロサービスまたはアプリケーションのネットワークアドレスとの間の対応関係のリストを含むことができる。マイクロサービスは、マイクロサービスの名前、サービス識別子、マイクロサービスを実行しているポッドのネットワークアドレスなどを制御プレーン400に登録することができる。例えば、ポッドのネットワークアドレスは、ポッドのIPアドレスおよびポート番号を含むことができる。したがって、制御プレーン400は、マイクロサービスを構築するサービス識別子とマイクロサービスを実行しているポッドのネットワークアドレスとの間の対応関係に基づいてサービスリストを取得することができる。

いくつかの実施形態では、サービスリストは、サービス指向アーキテクチャ管理ポリシーと呼ばれてもよく、またはサービス指向アーキテクチャ管理ポリシーは、サービスリストを含む。

いくつかの実施形態では、サービス指向アーキテクチャ管理ポリシーは、アクセス要求を暗号化するか復号化するか、およびアクセス要求に対して負荷分散を実行するかなどのポリシーを含み得る。さらに、サービス指向アーキテクチャ管理ポリシーの具体的な実装については、従来の技術の説明を参照されたい。ここでは詳細を繰り返さない。

特別なマイクロサービスリストは、1つまたは複数の特別なマイクロサービスの識別情報を含む。一般に、サービスメッシュシステムでは、マイクロサービスに接続するように要求するために使用されるアクセス要求に対して、サービス指向アーキテクチャ管理を2回実行する必要があることが理解されよう。1つは、送信側（例えば、ノード100）の通信プロキシによって実行されるサービス指向アーキテクチャ管理であり、もう1つは、受信側（例えば、ノード100）の通信プロキシによって実行されるサービス指向アーキテクチャ管理である。しかしながら、特別なマイクロサービスは特別である。具体的には、特別なマイクロサービスへの接続を要求するために使用されるアクセス要求に対して1回だけサービス指向アーキテクチャ管理を実行する必要がある。

引き続き図6を参照されたい。制御プレーンプロキシ123は、管理必須リストをトラフィック遮断モジュール114に送信するステップ603aを実行することができる。いくつかの実施形態では、管理必須リストは、サービスメッシュシステムの開発者または運用および保守担当者によって構成されてもよい。いくつかの実施形態では、制御プレーンプロキシ123は、サービスリストに基づいて、管理必須リストを自動的に生成することができる。上述したように、サービスリストは、サービス識別子と、サービス識別子に対応するサービスを提供することができるマイクロサービスまたはアプリケーションのネットワークアドレスとの間の対応関係のリストを含むことができる。制御プレーンプロキシ123は、サービスリスト内のサービス識別子を、管理必須リストとして使用することができる。管理必須リストを構成する2つの方法が上述されていることに留意されたい。しかしながら、本出願のこの実施形態で提供される解決策の具体的な実施中に、人手への依存をさらに低減するために、サービスリストに基づいて管理必須リストを自動的に生成する方法が使用される傾向がある。

制御プレーンプロキシ123は、特別なマイクロサービスリストをユーザモードプロトコルスタック122に送信するステップ603bを実行することができる。アクセス要求を受信すると、ユーザモードプロトコルスタック122は、接続を要求するためにアクセス要求が使用されるマイクロサービスが特別なマイクロサービスリストに位置するかどうかを決定することができる。接続を要求するためにアクセス要求が使用されるマイクロサービスが特別なマイクロサービスリストにある場合、ユーザモードプロトコルスタック122は、アクセス要求を通信プロキシ121に送信せず、アクセス要求をホスト110に直接送信する。

制御プレーンプロキシ123は、サービスリストおよびサービス指向アーキテクチャ管理ポリシーを通信プロキシ121に送信するステップ603cをさらに実行することができ、その結果、通信プロキシ121は、サービスリストおよびサービス指向アーキテクチャ管理ポリシーに基づいて、アクセス要求に対してサービス指向アーキテクチャ管理を実行することができる。具体的には、アクセス要求の接続ターゲットアプリケーションは、アクセス要求内のサービス識別子を使用することによってサービスリストに基づいて決定され得る。具体的には、アクセス要求のターゲットアプリケーションのネットワークアドレスが決定される。例えば、サービス指向アーキテクチャ管理ポリシーが暗号化ポリシーを含む場合、通信プロキシ121は、アクセス要求を暗号化することができる。

制御プレーンプロキシ123は、制御プレーン400から更新されたサービスリスト、更新されたサービス指向アーキテクチャ管理ポリシー、および更新された特別なマイクロサービスリストを受信するステップ604をさらに実行することができる。

制御プレーンプロキシ123は、更新された管理必須リストをトラフィック遮断モジュール114に送信するステップ605aをさらに実行することができる。いくつかの実施形態では、更新された管理必須リストは、更新されたサービスリストに基づいて制御プレーンプロキシ123によって生成され得る。

制御プレーンプロキシ123は、更新された特別なマイクロサービスリストをユーザモードプロトコルスタック122に送信するステップ605bをさらに実行することができる。

制御プレーンプロキシ123は、更新されたサービスリストおよび更新されたサービス指向アーキテクチャ管理ポリシーを通信プロキシ121に送信するステップ605dをさらに実行することができる。

ノード100の初期化は、前述のステップを使用することによって実施され得る。別のノードの初期化については、ノード100の初期化の実施態様を参照されたい。ここでは詳細を繰り返さない。

前述の初期化がサービスメッシュシステム内のノード上で実行された後、以下の呼び出しが実施され得る。

（1）ノード100上のマイクロサービスは、ノード100上の別のマイクロサービスを呼び出す。

（2）ノード100上のマイクロサービスは、ノード200上のサービスを呼び出す。

（3）ノード100上の共通アプリケーションは、ノード200上の共通アプリケーションを呼び出す。

（4）ノード100上のマイクロサービスは、ノード200上の特別なマイクロサービスを呼び出す。以下、特別なマイクロサービスについて具体的に説明する。ここでは詳細を繰り返さない。

（5）ノード200上の共通アプリケーションは、ノード200上の他の共通アプリケーションを呼び出す。

（6）ノード200は、ノード100のアクセス要求を転送する。

（7）ノード100上の共通アプリケーションは、ノード200上のマイクロサービスを呼び出す。

（8）ノード100上のマイクロサービスは、ノード200の共通アプリケーションを呼び出す。

次に、異なる実施形態において、前述の8つの呼び出しケースを具体的に説明する。

実施形態1：ノード100上のマイクロサービスは、ノード100上の別のマイクロサービスを呼び出す。

本実施形態では、マイクロサービス1111がマイクロサービス1121を呼び出すことが例に使用される。マイクロサービス1121がマイクロサービス1111に関連するサービスを提供できるように、マイクロサービス1111とマイクロサービス1121との間の通信接続を確立するために、マイクロサービス1111は、マイクロサービス1121に接続するために使用されるアクセス要求を生成することができる。このようにして、マイクロサービス1111は、マイクロサービス1121を呼び出す。マイクロサービスアーキテクチャでは、アクセス要求を生成するとき、マイクロサービス1111は、マイクロサービス1111がマイクロサービス1121に接続する必要があることを実際には知らず、どのサービスがマイクロサービス1111によって必要とされるかしか知らず、サービスのサービス識別子をアクセス要求にさらに追加するか、またはサービス識別子をアクセス要求の元の宛先アドレスとして使用することが理解されよう。アクセス要求に対してサービス指向アーキテクチャ管理を実行した後、通信プロキシは、マイクロサービス1111にサービスを実際に提供するターゲットアプリケーションを決定し、次いで、マイクロサービス1111とターゲットアプリケーションとの間の接続を確立するために、アクセス要求をターゲットアプリケーションに転送することができる。

次に、マイクロサービス1111がマイクロサービス1121を呼び出す具体的なデータ転送経路について、図7および図5Aおよび図5Bを参照して説明する。

マイクロサービス1111は、アクセス要求A1を生成することができる。アクセス要求A1は、マイクロサービス1121によって提供され得るサービスのサービス識別子を含んでもよい。例えば、アクセス要求A1は、ネットワークソケット（socket）接続要求であってもよい。アクセス要求A1内のサービス識別子は、アクセス要求A1の元のsocket宛先アドレス（destination，DST）と呼ばれてもよい。マイクロサービス1111は、アクセス要求A 1をトラフィック遮断モジュール114に送信するステップ701を実行することができる。トラフィック遮断モジュール114は、アクセス要求A1内のサービス識別子に基づいて、アクセス要求A1上でサービス指向アーキテクチャ管理が実行される必要があるかどうかを、管理必須リストを使用することによって決定することができる。アクセス要求A1内のサービス識別子がマイクロサービス1121に対応するサービス識別子であり、サービス識別子が管理必須リスト内にある場合、アクセス要求A1に対してサービス指向アーキテクチャ管理を実行する必要があると決定される。したがって、トラフィック遮断モジュール114は、アクセス要求A1をデータチャネル140に転送するステップ702を実行することができる。

例示的な例では、ステップ701およびステップ702のデータフローは図5Aの（1）に示され得る。マイクロサービス1111によって生成され得るアクセス要求A1は、ネットワークソケット（socket）接続要求であり得る。アクセス要求A1内のサービス識別子は、socket接続の元のsocket宛先アドレスとして使用され得る。アクセス要求A1は、トラフィック遮断モジュール114に送信され得る。トラフィック遮断モジュール114は、分析を通じて、サービス識別子に対応するサービスがサービスメッシュ内のサービスであることを知る。言い換えれば、サービス識別子に対応するサービスに対してサービス指向アーキテクチャ管理を実行する必要がある。トラフィック遮断モジュール114は、アクセス要求A1をデータチャネル140に転送する。

データチャネル140は、アクセス要求A1をユーザモードプロトコルスタック122に送信するステップ703を実行することができる。ステップ703については、図5Aの（2）を参照されたい。例えば、上述したように、データチャネル140は、PCIeバスであるか、またはPCIeバス上で搬送される。ステップ703において、データチャネル140の、ホスト110内に位置する端部は、アクセス要求A1をPCIeプロトコルの下でデータフローに変換し、変換されたデータフローをデータチャネル140を通じて送信することができる。データチャネル140の、データカード120内に位置する端部は、PCIeプロトコルの下でデータフローとして提示されたアクセス要求A1をsocket接続要求の形態に変換し、アクセス要求A1をユーザモードプロトコルスタック122に送信することができる。加えて、本出願のこの実施形態では、ユーザモードプロトコルスタック122は、ホスト110のオペレーティングシステムに組み込まれたネットワークプロトコルスタックから独立している。したがって、ホスト110とデータカード120との間のデータ交換によって引き起こされるシステムオーバーヘッドは回避または低減され得る。

ユーザモードプロトコルスタック122は、アクセス要求A1を通信プロキシ121に送信するステップ704を実行することができる。ステップ704については、図5Aの（2）を参照されたい。例えば、ユーザモードプロトコルスタック122は、アクセス要求A1内のサービス識別子、すなわち、アクセス要求A1の元のsocket宛先アドレスを記憶することができる。ユーザモードプロトコルスタック122は、アクセス要求A1のsocket宛先アドレスを通信プロキシ121のリスニングポート1のネットワークアドレスに更新することができ、したがって、アクセス要求A1をリスニングポート1に送信することができる。この場合、マイクロサービス1111とリスニングポート1との間にsocket接続またはソケットリンクが確立され得る。リスニングポート1は、通信プロキシ121のアウトバウンドトラフィック（outbound）リスニングポートとも呼ばれ得る。

通信プロキシ121は、リスニングポート1を介してアクセス要求A1を取得し、アクセス要求A1内のサービス識別子を取得することができる。ユーザモードプロトコルスタック122は、マイクロサービス1111とリスニングポート1との間のsocketリンク上に位置し、アクセス要求A1内にサービス識別子を記憶することが理解されよう。通信プロキシ121は、socketリンクを使用することによって、ユーザモードプロトコルスタック122からアクセス要求A1内のサービス識別子を取得することができる。

通信プロキシ121は、アクセス要求A1に対してサービス指向アーキテクチャ管理を実行するステップ705を実行することができる。具体的には、通信プロキシ121は、アクセス要求A1内のサービス識別子と、サービス指向アーキテクチャ管理ポリシーとに基づいて、サービス指向アーキテクチャ管理を実行することができる。サービス指向アーキテクチャ管理は、負荷分散を通じて、マイクロサービス1111のサービス識別子によって記述されるサービスを提供するアプリケーションを選択することを含み得る。本実施形態では、マイクロサービス1111のサービス識別子によって記述されるサービスを提供する選択されたアプリケーションはマイクロサービス1121であると決定されてもよい。言い換えれば、マイクロサービス1121がアクセス要求A1のターゲットアプリケーションであると決定されてもよい。例えば、アクセス要求A1のターゲットアプリケーションが決定された場合、アクセス要求A1のsocket宛先アドレスをマイクロサービス1121のネットワークアドレスに更新してもよい。マイクロサービス1121のネットワークアドレスは、具体的にはマイクロサービス1121を実行しているポッドのネットワークアドレス、すなわちポッド112のネットワークアドレスであってもよい。例えば、ポッド112のネットワークアドレスは、ポッド112のIPアドレスおよびポート番号を含んでもよい。

通信プロキシ121は、アクセス要求A1をユーザモードプロトコルスタック122に送信するステップ706を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A1のターゲットアプリケーションがこのノード上に位置していると決定するステップ707を実行することができる。次いで、ユーザモードプロトコルスタック122は、アクセス要求A1を通信プロキシ121のリスニングポート2に送信するステップ708を実行することができる。詳細については、図5Aの（3）および（6）を参照されたい。ユーザモードプロトコルスタック122は、アクセス要求A1の送信プロセスのユーザ識別情報（user identity，UID）に基づいて、ステップ706が通信プロキシ121によって実行されると決定し、アクセス要求A1内のsocket宛先アドレスに基づいて、アクセス要求A1のターゲットアプリケーション（すなわち、マイクロサービス1121）がこのノード（すなわち、ノード100）上に位置すると決定することができる。次いで、ユーザモードプロトコルスタック122は、ステップ706において、ユーザモードプロトコルスタック122がアクセス要求A1のインバウンド（inbound）トラフィックを受信して、通信プロキシ121のリスニングポート2にアクセス要求A1を転送すると決定することができる。これにより、マイクロサービスが別のローカルマイクロサービスを呼び出した場合でも、マイクロサービスが通信プロキシに対称的に2回入り、サービス指向アーキテクチャ管理を2回実行できることが保証される。リスニングポート2は、通信プロキシ121のインバウンドトラフィック（inbound）リスニングポートと呼ばれ得る。

通信プロキシ121は、再び受信されたアクセス要求A1に対してサービス指向アーキテクチャ管理を実行するステップ709を実行することができる。例えば、ステップ705のサービス指向アーキテクチャ管理では、アクセス要求A1内のサービスデータまたはユーザデータが暗号化される。この場合、ステップ709のサービス指向アーキテクチャ管理において、暗号化されたデータを復号することができる。

通信プロキシ121は、ユーザモードプロトコルスタック122に、サービス指向アーキテクチャ管理が再び実行されるアクセス要求A1を送信するステップ710を実行することができる。ステップ710を実行する前に、通信プロキシ121は、ユーザモードプロトコルスタック122によって提供されたアプリケーションプログラミングインターフェース（application programming interface，API）を呼び出して、アクセス要求A 1にサービス指向アーキテクチャ管理識別子を追加することができる。サービス指向アーキテクチャ管理識別子は、アクセス要求A1に対してサービス指向アーキテクチャ管理が2回実行され、ターゲットアプリケーションがローカルに展開されることを示すために使用される。

ユーザモードプロトコルスタック122は、アクセス要求A1をデータチャネル140に送信するステップ711を実行することができる。図5Aの（7）および（8）を参照されたい。ステップ710で送信されたアクセス要求A1を受信すると、ユーザモードプロトコルスタック122は、アクセス要求A1内で搬送されたサービス指向アーキテクチャ管理識別子に基づいて、アクセス要求A1がインバウンドトラフィックであり、ターゲットアプリケーションがこのノードのポッド内に位置すると決定することができる。したがって、データチャネル140にアクセス要求A1を送信するステップ711を実行することができる。

データチャネル140は、アクセス要求A1をトラフィック遮断モジュール114に送信するステップ712を実行することができる。図5Aの（8）を参照されたい。ステップ711で送信されたアクセス要求A1を受信すると、データチャネル140の、データカード120内に位置する端部は、アクセス要求A1をPCIeプロトコル下のデータフローに変換し、PCIeプロトコル下のデータフローをホスト110に送信することができる。PCIeの下のデータフローがデータチャネル140の、ホスト110に位置する端部に到達すると、PCIeの下のデータフローは、socket接続要求に変換されてもよい。

トラフィック遮断モジュール114は、具体的にはアウトバウンドトラフィック遮断モジュールである。言い換えれば、トラフィック遮断モジュール114は、ホスト110によって外部に送信されたトラフィックのみを遮断またはフィルタリングし、ホスト110によって外部から受信されたトラフィックをフィルタリングしない。ステップ712で送信されたアクセス要求A 1を受信すると、トラフィック遮断モジュール114は、アクセス要求A1のsocket宛先アドレス（すなわち、マイクロサービス1121のネットワークアドレス）に基づいて、ターゲットアプリケーション（すなわち、マイクロサービス1121）にアクセス要求A1を送信することができる。このようにして、マイクロサービス1111とマイクロサービス1121との間のsocket接続が確立され、マイクロサービス1111がマイクロサービス1121を呼び出すことができる。

実施形態2：ノード100上のマイクロサービスは、ノード200上のマイクロサービスを呼び出す。

本実施形態では、マイクロサービス1111がマイクロサービス2141を呼び出すことが例に使用される。マイクロサービス2141がマイクロサービス1111に関連するサービスを提供することができるように、マイクロサービス1111とマイクロサービス2141との間の通信接続を確立するために、マイクロサービス1111は、マイクロサービス2141に接続するために使用されるアクセス要求を生成することができる。このようにして、マイクロサービス1111は、マイクロサービス2141を呼び出す。マイクロサービスアーキテクチャでは、アクセス要求を生成するとき、マイクロサービス1111は、マイクロサービス1111がマイクロサービス2141に接続する必要があることを実際には知らず、どのサービスがマイクロサービス1111によって必要とされるかしか知らず、アクセス要求にサービスをさらに追加するか、またはサービスをアクセス要求の元の宛先アドレスとして使用することが理解されよう。アクセス要求に対してサービス指向アーキテクチャ管理を実行した後、通信プロキシは、マイクロサービス1111にサービスを実際に提供するターゲットアプリケーションを決定し、次いで、マイクロサービス1111とターゲットアプリケーションとの間の接続を確立するために、アクセス要求をターゲットアプリケーションに転送することができる。

次に、マイクロサービス1111がマイクロサービス2141を呼び出す具体的なデータ転送経路について、図8A、図8B、図5A、および図5Bを参照して説明する。

マイクロサービス1111は、アクセス要求A2を生成することができる。アクセス要求A2は、マイクロサービス2141によって提供され得るサービスのサービス識別子を含んでもよい。マイクロサービス1111は、アクセス要求A2をトラフィック遮断モジュール114に送信するステップ801を実行することができる。トラフィック遮断モジュール114は、アクセス要求A2内のサービス識別子に基づいて、アクセス要求A2上でサービス指向アーキテクチャ管理が実行される必要があるかどうかを、管理必須リストを使用することによって決定することができる。アクセス要求A2内のサービス識別子は、マイクロサービス2141に対応するサービス識別子であり、サービス識別子は、管理必須リスト内にある。したがって、アクセス要求A2に対してサービス指向アーキテクチャ管理を実行する必要があると決定される。したがって、トラフィック遮断モジュール114は、アクセス要求A2をデータチャネル140に転送するステップ802を実行することができる。

データチャネル140は、アクセス要求A2をユーザモードプロトコルスタック122に送信するステップ803を実行することができる。

ユーザモードプロトコルスタック122は、アクセス要求A2を通信プロキシ121に送信するステップ804を実行することができる。

ステップ801、ステップ802、ステップ803、およびステップ804の具体的な実行については、ステップ701、ステップ702、ステップ703、およびステップ704の前述の説明を参照されたい。ここでは詳細を繰り返さない。

通信プロキシ121は、アクセス要求A2に対してサービス指向アーキテクチャ管理を実行するステップ805を実行することができる。具体的には、通信プロキシ121は、アクセス要求A2内のサービス識別子と、サービス指向アーキテクチャ管理ポリシーとに基づいて、サービス指向アーキテクチャ管理を実行することができる。サービス指向アーキテクチャ管理は、負荷分散を通じて、マイクロサービス1111のサービス識別子によって記述されるサービスを提供するアプリケーションを選択することを含み得る。本実施形態では、マイクロサービス1111のサービス識別子によって記述されるサービスを提供する選択されたアプリケーションはマイクロサービス2141であると決定されてもよい。言い換えれば、マイクロサービス2141がアクセス要求A2のターゲットアプリケーションであると決定されてもよい。例えば、マイクロサービス2141がアクセス要求A2のターゲットアプリケーションであると決定された場合、アクセス要求A2のsocket宛先アドレスをマイクロサービス2141のネットワークアドレスに更新してもよい。特別なマイクロサービス2141は、アクセス要求A2のターゲットアプリケーションと呼ばれてもよく、特別なマイクロサービス2141のネットワークアドレスは、アクセス要求A2のターゲットアプリケーションアドレスと呼ばれてもよい。マイクロサービス2141のネットワークアドレスは、具体的にはマイクロサービス2141を実行しているポッドのネットワークアドレス、すなわちポッド214のネットワークアドレスであってもよい。例えば、ポッド214のネットワークアドレスは、ポッド214のIPアドレスおよびポート番号を含んでもよい。

通信プロキシ121は、アクセス要求A2をユーザモードプロトコルスタック122に送信するステップ806を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A2の実際のターゲットアプリケーションがこのノード上に位置していないと決定するステップ807を実行することができる。次いで、ユーザモードプロトコルスタック122は、アクセス要求A2にサービスメッシュ識別子を追加するステップ808を実行することができる。サービスメッシュ識別子は、アクセス要求A2のターゲットアプリケーションがマイクロサービスであることを示すために使用される。サービスメッシュ識別子の特定の形態は、カスタマイズされたフィールド、番号などであり得る。具体的な実施に際して、サービスメッシュシステムの開発者または運用および保守担当者は、サービスメッシュ識別子をカスタマイズすることができる。ユーザモードプロトコルスタック122は、アクセス要求A2のターゲットアプリケーションアドレスをカプセル化するステップ809をさらに実行することができる。上述したように、ステップ805で決定されたターゲットアプリケーションアドレスは、マイクロサービス2141のネットワークアドレスである。マイクロサービス2141は、ノード（すなわち、ノード200）上に位置することが理解されよう。ステップ809において、マイクロサービス2141のネットワークアドレスは、ノードのIPアドレスにカプセル化され得る。例えば、マイクロサービス2141のネットワークアドレスは、ポッド214のネットワークアドレスであってもよい。ポッド214のネットワークアドレスは、ポッド214のIPアドレスおよびポート番号を含んでもよい。ポッド214がノード200上に位置する場合、ステップ809において、マイクロサービス2141のネットワークアドレスは、ノード200のIPアドレスにカプセル化される。

加えて、ステップ806、ステップ807、ステップ808、およびステップ809の実行については、図5Aの（3）を参照されたい。具体的には、ステップ806において、アクセス要求A2は、通信プロキシ121によって送信されたアウトバウンドトラフィックとして使用され、ユーザモードプロトコルスタック122に送信される。ユーザモードプロトコルスタック122は、アクセス要求A2のデータフロー送信プロセスのUIDに基づいて、アウトバウンドトラフィックが通信プロキシ121によって送信されたと決定し、アクセス要求A2のターゲットアプリケーションアドレスに基づいて、ターゲットアプリケーションがこのノード（ノード100）上に位置していないと決定することができる。次に、アクセス要求A2に対してサービスメッシュ識別子の追加、ターゲットアプリケーションアドレスのカプセル化などが実行され得る。

次いで、ユーザモードプロトコルスタック122は、アクセス要求A2をネットワークインターフェースカード130に送信するステップ810を実行することができる。図5Aの（4）を参照されたい。外部に送信されたトラフィックを処理するとき、ネットワークインターフェースカードは、ネットワークを使用することによってターゲットノードのネットワークインターフェースカードにトラフィックを直接送信することができる。この実施形態に戻って、図8Aを参照されたい。ネットワークインターフェースカード130は、アクセス要求A2をネットワークインターフェースカード230に送信するステップ811を実行することができる。具体的には、ネットワークインターフェースカード130は、ネットワーク300を使用することによって、アクセス要求A2をネットワークインターフェースカード230に送信することができる。

図8Bを参照されたい。ネットワークインターフェースカード230は、アクセス要求A2からターゲットアプリケーションアドレスを復元するステップ812を実行し、アクセス要求A2がサービスメッシュ識別子を有すると決定するステップ813を実行することができる。図5Bの（10）をさらに参照されたい。アクセス要求A2を搬送するデータパケットを受信した後、ネットワークインターフェースカード230の物理ネットワークインターフェースカードは、アクセス要求A2のターゲットアプリケーションアドレスを復元し、アクセス要求A2がサービスメッシュ識別子を有するかどうかを決定することができる。

次いで、ネットワークインターフェースカード230は、アクセス要求A2をユーザモードプロトコルスタック222に送信するステップ814を実行することができる。あるいは、図5Bの（12）を参照されたい。ネットワークインターフェースカード230は、ネットワークインターフェースカード230とデータカード220との間の仮想ネットワークポートを介してアクセス要求A2をユーザモードプロトコルスタック222に転送する。

ユーザモードプロトコルスタック222は、アクセス要求A2のターゲットアプリケーションが特別なマイクロサービスではないと決定するステップ815を実行することができる。上述したように、初期化プロセスにおいて、ユーザモードプロトコルスタックは、特別なマイクロサービスリストを取得することができる。特別なマイクロサービスリストは、1つまたは複数の特別なマイクロサービスの識別情報を含む。識別情報は、ネットワークアドレスであってもよい。したがって、ステップ815において、ユーザモードプロトコルスタック222は、ターゲットアプリケーションのネットワークアドレスに基づいて、ターゲットアプリケーションが特別なマイクロサービスではないと決定することができ、すなわち、ターゲットアプリケーションのネットワークアドレスが特別なマイクロサービスリストに位置していないと決定することができる。アクセス要求A2のターゲットアプリケーションが特別なマイクロサービスではないと決定した後、ユーザモードプロトコルスタック222は、アクセス要求A2を通信プロキシ221に送信するステップ816を実行することができる。通信プロキシ221は、アクセス要求A2に対してサービス指向アーキテクチャ管理を再び実行することができる。例えば、アクセス要求A2内のサービスデータが復号される。次いで、通信プロキシ221は、ユーザモードプロトコルスタック222に、サービス指向アーキテクチャ管理が再び実行されるアクセス要求A2を送信するステップ818を実行することができる。ステップ818を実行する前に、通信プロキシ221は、ユーザモードプロトコルスタック222によって提供されたAPIを呼び出して、アクセス要求A2にサービス指向アーキテクチャ管理識別子を追加することができる。サービス指向アーキテクチャ管理識別子は、アクセス要求A2に対してサービス指向アーキテクチャ管理が実行され、ターゲットアプリケーションがローカルに（通信プロキシ221が位置するノードに）展開されることを示すために使用される。

ステップ815からステップ818の実行については、図5Bの（14）をさらに参照されたい。ユーザモードプロトコルスタック222が、アクセス要求A2のターゲットアプリケーションアドレスが非特別なマイクロサービスのアドレスではない、すなわち、ターゲットアプリケーションが特別なマイクロサービスではないと決定した場合、ユーザモードプロトコルスタック222は、アクセス要求A2を通信プロキシ221のリスニングポート3に転送する。リスニングポート3は、通信プロキシ221のインバウンドトラフィック用リスニングポートである。通信プロキシ221は、アクセス要求A2をインバウンドトラフィックとして記録し、アクセス要求A2に対してサービス指向アーキテクチャ管理を実行する。アクセス要求A2に対してサービス指向アーキテクチャ管理が実行され、アクセス要求A2がアップストリームモジュールまたはコンポーネントに送信されると、ユーザモードプロトコルスタック222のAPIは、アクセス要求A2にサービス指向アーキテクチャ管理識別子を追加するために呼び出され得る。

ユーザモードプロトコルスタック222は、アクセス要求A2をデータチャネル240に送信するステップ819を実行することができる。図5Bの（15）を参照されたい。ステップ818で送信されたアクセス要求A2を受信すると、ユーザモードプロトコルスタック222は、アクセス要求A2内で搬送されたサービス指向アーキテクチャ管理識別子に基づいて、アクセス要求A2がインバウンドトラフィックであり、ターゲットアプリケーションがこのノードのポッド内に位置すると決定することができる。したがって、データチャネル240にアクセス要求A2を送信するステップ819を実行することができる。

データチャネル240は、アクセス要求A2をトラフィック遮断モジュール215に送信するステップ820を実行することができる。図5Bの（15）を参照されたい。ステップ819で送信されたアクセス要求A2を受信すると、データチャネル240の、データカード120内に位置する端部は、アクセス要求A2をPCIeプロトコル下のデータフローに変換し、PCIeプロトコル下のデータフローをホスト210に送信することができる。PCIeの下のデータフローがデータチャネル240の、ホスト210に位置する端部に到達すると、PCIeの下のデータフローは、socket接続要求に変換されてもよい。

トラフィック遮断モジュール215は、具体的にはアウトバウンドトラフィック遮断モジュールである。言い換えれば、トラフィック遮断モジュール215は、ホスト210によって外部に送信されたトラフィックのみを遮断またはフィルタリングし、ホスト210によって外部から受信されたトラフィックをフィルタリングしない。ステップ820で送信されたアクセス要求A2を受信すると、トラフィック遮断モジュール215は、アクセス要求A2をマイクロサービスアプリケーション2141に送信するステップ821を実行することができる。具体的には、アクセス要求A2は、アクセス要求A2のsocket宛先アドレス（すなわち、マイクロサービス2141のネットワークアドレス）に基づいてターゲットアプリケーション（すなわち、マイクロサービス2141）に送信され得る。

したがって、マイクロサービス1111とマイクロサービス2141との間の接続が確立され、マイクロサービス1111がマイクロサービス2141を呼び出すことができる。例えば、アクセス要求A2は、具体的にはsocket接続要求であってもよく、マイクロサービス1111とマイクロサービス2141との間に確立された接続は、socket接続であってもよい。

実施形態3：ノード100上の共通アプリケーションは、ノード200上の共通アプリケーションを呼び出す。

次に、図9および図5Aおよび図5Bを参照して、共通アプリケーション113が共通アプリケーション211を呼び出す例が使用され、本実施形態で提供される解決策を説明する。

共通アプリケーション113はアクセス要求A3を生成することができ、アクセス要求A3のターゲットアプリケーションアドレスは、共通アプリケーション211のネットワークアドレスである。例えば、共通アプリケーション211のネットワークアドレスは、共通アプリケーション211のIPアドレスおよびポート番号を含んでもよい。図9を参照されたい。共通アプリケーション113は、アクセス要求A3をトラフィック遮断モジュール114に送信するステップ901を実行することができる。トラフィック遮断モジュール114は、共通アプリケーションのネットワークアドレスが管理必須リストに位置していないと判断することができ、アクセス要求A3をホスト110の仮想ネットワークポートに送信するステップ902をさらに実行することができ、その結果、ホスト110の仮想ネットワークポートは、ネットワークインターフェースカード130にアクセス要求A3を送信するステップ903を実行することができる。図5Aの（9）をさらに参照されたい。共通アプリケーション113は、アクセス要求A3を送信してもよい。トラフィック遮断モジュール114は、アクセス要求A3のターゲットアプリケーションが共通アプリケーションであると決定し、仮想ネットワークポートを介してネットワークインターフェースカード130にアクセス要求を直接送信する。

ネットワークインターフェースカード130は、アクセス要求A3のターゲットアプリケーションアドレスをカプセル化するステップ904を実行することができる。具体的には、図5Aの（5）に示されるように、アクセス要求A3のターゲットアプリケーションがノード100以外のノードに位置することを検出すると、ネットワークインターフェースカード130は、ターゲットアプリケーションアドレスをカプセル化することができる。ターゲットアプリケーションアドレスは、ターゲットアプリケーションが位置するノードのアドレスにカプセル化されてもよい。例えば、ターゲットアプリケーションアドレスは共通アプリケーション211のネットワークアドレスであり、共通アプリケーションはノード200上に位置するので、ネットワークアドレスはノード200のIPアドレスにカプセル化され得る。例えば、共通アプリケーション211のネットワークアドレスは、共通アプリケーション211のIPアドレスおよびポート番号を含んでもよい。

ネットワークインターフェースカード130は、アクセス要求A3をネットワークインターフェースカード230に送信するステップ905をさらに実行することができる。具体的には、図5Aの（5）を参照されたい。ネットワークインターフェースカード130は、物理ネットワークインターフェースカードを使用することによってアクセス要求A3をネットワーク300に送信することができ、次いで、ネットワーク300は、アクセス要求A3の宛先アドレス（すなわち、ステップ904でカプセル化後に取得されたアドレス）に基づいて、アクセス要求A3をネットワークインターフェースカード230に転送することができる。

アクセス要求A3を受信した後、ネットワークインターフェースカード230は、アクセス要求A3のターゲットアプリケーションアドレスを復元するステップ906を実行することができる。すなわち、ステップ906において、ステップ904でカプセル化されたターゲットアプリケーションアドレスが復元され得る。

ネットワークインターフェースカード230は、アクセス要求A3がサービスメッシュ識別子を有していないと決定するステップ907を実行することができる。サービス要求A3はデータカード120を通過せず、したがってサービスメッシュ識別子を有さないことが理解されよう。ネットワークインターフェースカード230は、ターゲットアプリケーションアドレスがサービスメッシュゲートウェイアドレスではないと決定するステップ908をさらに実行することができる。サービスメッシュゲートウェイアドレスは、通信プロキシのリスニングポートのアドレスである。例えば、図5Bのリスニングポート3は、ノード200のサービスメッシュゲートウェイアドレスとして使用され得る。次いで、ネットワークインターフェースカード230は、アクセス要求A3をホスト210の仮想ネットワークポートに送信するステップ909を実行することができる。ホスト210の仮想ネットワークポートは、アクセス要求A3をトラフィック遮断モジュール215に送信するステップ910を実行することができる。トラフィック遮断モジュール215は、アクセス要求A3を共通アプリケーション211に送信するステップ911を実行することができる。

ステップ907からステップ911の実行については、図5Bの（11）をさらに参照されたい。ネットワークインターフェースカード230が、アクセス要求A3がサービスメッシュ識別子を有しておらず、ターゲットアプリケーションアドレスがサービスメッシュゲートウェイアドレスではないと決定することができる場合、ネットワークインターフェースカード230は、仮想ネットワークポートを介してアクセス要求A3をホスト210に転送することができる。そして、ホスト210のシステムカーネルは、アクセス要求A3を共通アプリケーション211に直接送信してもよい。

したがって、共通アプリケーション113と共通アプリケーション211との接続を確立し、共通アプリケーション113が共通アプリケーション211を呼び出すようにしてもよい。例えば、アクセス要求A3は、具体的にはsocket接続要求であってもよく、共通アプリケーション113と共通アプリケーション211との間に確立された接続は、socket接続であってもよい。

実施形態4：ノード100上のマイクロサービスは、ノード200上の特別なマイクロサービスを呼び出す。

特別なマイクロサービスは、一般に、第2の通信プロキシ（例えば、サイドカー）を介さずに接続できるアプリケーションを含むが、これに限定されない。言い換えれば、そのターゲットアプリケーションが特別なマイクロサービスであるアクセス要求は、2回目のサービス指向アーキテクチャ管理を受けることなくターゲットアプリケーションに到達することができ、それによってソースアプリケーションとターゲットアプリケーションとの間の接続を実施する。ソースアプリケーションは、アクセス要求を生成するアプリケーションである。典型的な特別なマイクロサービスは、トラフィック制限サービスを提供するマイクロサービス、データ収集サービスを提供するマイクロサービスなどを含む。

特別なマイクロサービスを呼び出すシナリオでは、ホストのユーザ空間内のマイクロサービスによって開始されたアクセス要求が通信プロキシを初めて通過するとき、通信プロキシは、アクセス要求に対してサービス指向アーキテクチャ管理を実行するために特別なマイクロサービスを能動的に呼び出す必要がある。例えば、通信プロキシは、トラフィック制限サービスを提供するマイクロサービスを呼び出し、アクセス要求がトラフィック制限閾値を超えるかどうかを決定することができる。アクセス要求がトラフィック制限閾値を超える場合、通信プロキシは、アクセス要求を開始したマイクロサービスに失敗応答を返すことができる。アクセス要求が通信プロキシを初めて通過するとき、通信プロキシは、データ収集サービスをさらに呼び出して、ネットワーク呼び出しトポロジ図を作成するために、収集されたリンク呼び出しデータをデータ収集サービスに報告することができる。

特別なマイクロサービスはサービスメッシュ内のマイクロサービスであるため、そのターゲットアプリケーションが特別なマイクロサービスであるアクセス要求を遮断するために使用される遮断ソリューションをネットワークインターフェースカード内に構成することは困難である。その結果、初めてサービス指向アーキテクチャ管理が実行されるアクセス要求が通信プロキシに再び送信され、不必要なサービス指向アーキテクチャ管理を引き起こす可能性がある。この問題を解決するために、この実施形態では、アクセス要求のターゲットアプリケーションが特別なマイクロサービスであるかどうかは、アクセス要求のターゲットアプリケーションが特別なマイクロサービスではない場合に、アクセス要求が2回目に通信プロキシを通過することなくホストに直接送信され得るように、ユーザモードプロトコルスタック内の特別なマイクロサービスリストを使用することによって決定することができる。

次に、図10A、図10B、図5A、および図5Bを参照して、本実施形態における解決策を説明するために、ノード100上のマイクロサービス1111がノード200上の特別なマイクロサービス2131を呼び出す例が使用される。

マイクロサービス1111は、アクセス要求A4を生成することができる。アクセス要求A4は、特別なマイクロサービス2131によって提供され得るサービスのサービス識別子を含んでもよい。マイクロサービス1111は、アクセス要求A4をトラフィック遮断モジュール114に送信するステップ1001を実行することができる。トラフィック遮断モジュール114は、アクセス要求A4内のサービス識別子に基づいて、アクセス要求A4上でサービス指向アーキテクチャ管理が実行される必要があるかどうかを、管理必須リストを使用することによって決定することができる。アクセス要求A4内のサービス識別子は、特別なマイクロサービス2131に対応するサービス識別子であり、サービス識別子は、管理必須リスト内に位置する。したがって、アクセス要求A4に対してサービス指向アーキテクチャ管理を実行する必要があると決定される。したがって、トラフィック遮断モジュール114は、アクセス要求A4をデータチャネル140に転送するステップ1002を実行することができる。

データチャネル140は、アクセス要求A4をユーザモードプロトコルスタック122に送信するステップ1003を実行することができる。

ユーザモードプロトコルスタック122は、アクセス要求A4を通信プロキシ121に送信するステップ1004を実行することができる。

ステップ1001、ステップ1002、ステップ1003、およびステップ1004の具体的な実行については、ステップ701、ステップ702、ステップ703、およびステップ704の前述の説明を参照されたい。ここでは詳細を繰り返さない。

通信プロキシ121は、アクセス要求A4に対してサービス指向アーキテクチャ管理を実行するステップ1005を実行することができる。具体的には、通信プロキシ121は、アクセス要求A4内のサービス識別子と、サービス指向アーキテクチャ管理ポリシーとに基づいて、サービス指向アーキテクチャ管理を実行することができる。サービス指向アーキテクチャ管理は、負荷分散を通じて、マイクロサービス1111のサービス識別子によって記述されるサービスを提供するアプリケーションを選択することを含み得る。この実施形態では、マイクロサービス1111のサービス識別子によって記述されるサービスを提供する選択されたアプリケーションは、特別なマイクロサービス2131であると決定されてもよい。すなわち、特別なマイクロサービス2131がアクセス要求A4のターゲットアプリケーションであると決定されてもよい。例えば、特別なマイクロサービス2131がアクセス要求A4のターゲットアプリケーションであると決定された場合、アクセス要求A4のsocket先アドレスを特別なマイクロサービス2131のネットワークアドレスに更新してもよい。特別なマイクロサービス2131は、アクセス要求A4のターゲットアプリケーションと呼ばれてもよく、特別なマイクロサービス2131のネットワークアドレスは、アクセス要求A4のターゲットアプリケーションアドレスと呼ばれてもよい。特別なマイクロサービス2131のネットワークアドレスは、特別なマイクロサービス2131を実行しているポッドのネットワークアドレス、すなわちポッド213のネットワークアドレスであってもよい。例えば、ポッド213のネットワークアドレスは、ポッド213のIPアドレスおよびポート番号を含んでもよい。

通信プロキシ121は、アクセス要求A4をユーザモードプロトコルスタック122に送信するステップ1006を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A4のターゲットアプリケーションがこのノード上に位置していないと決定するステップ1007を実行することができる。次いで、ユーザモードプロトコルスタック122は、アクセス要求A4にサービスメッシュ識別子を追加するステップ1008を実行することができる。サービスメッシュ識別子については、図8Aおよび図8Bに示される実施形態の前述の説明を参照されたい。ここでは詳細を繰り返さない。ユーザモードプロトコルスタック122は、アクセス要求A4のターゲットアプリケーションアドレスをカプセル化するステップ1009をさらに実行することができる。上述したように、ステップ1005で決定されたターゲットアプリケーションアドレスは、特別なマイクロサービス2131のネットワークアドレスである。特別なマイクロサービス2131は、ノード（すなわち、ノード200）上に位置することが理解されよう。ステップ1009において、特別なマイクロサービス2131のネットワークアドレスは、ノードのアドレスにカプセル化され得る。例えば、特別なマイクロサービス2131のネットワークアドレスは、ポッド213のネットワークアドレスを含んでもよい。ポッド213は、ノード200上に位置する。ステップ1009において、特別なマイクロサービス2131のネットワークアドレスは、ノード200のIPアドレスにカプセル化され得る。

加えて、ステップ1006、ステップ1007、ステップ1008、およびステップ1009の実行については、図5Aの（3）を参照されたい。具体的には、ステップ1006において、アクセス要求A4は、通信プロキシ121によって送信されたアウトバウンドトラフィックとして使用され、ユーザモードプロトコルスタック122に送信される。ユーザモードプロトコルスタック122は、アクセス要求A4のデータフロー送信プロセスのUIDに基づいて、アウトバウンドトラフィックが通信プロキシ121によって送信されたと決定し、アクセス要求A4のターゲットアプリケーションアドレスに基づいて、ターゲットアプリケーションがこのノード（ノード100）上に位置していないと決定することができる。次に、アクセス要求A4に対してサービスメッシュ識別子の追加、ターゲットアプリケーションアドレスのカプセル化などが実行され得る。

次いで、ユーザモードプロトコルスタック122は、アクセス要求A4をネットワークインターフェースカード130に送信するステップ1010を実行することができる。図5Aの（4）を参照されたい。外部に送信されたトラフィックを処理するとき、ネットワークインターフェースカードは、ネットワークを使用することによってターゲットノードのネットワークインターフェースカードにトラフィックを直接送信することができる。この実施形態に戻って、図10Aを参照されたい。ネットワークインターフェースカード130は、アクセス要求A4をネットワークインターフェースカード230に送信するステップ1011を実行することができる。具体的には、ネットワークインターフェースカード130は、ネットワーク300を使用することによって、アクセス要求A4をネットワークインターフェースカード230に送信することができる。

図10Bを参照されたい。ネットワークインターフェースカード230は、アクセス要求A4からターゲットアプリケーションアドレスを復元するステップ1012を実行し、アクセス要求A4がサービスメッシュ識別子を有すると決定するステップ1013を実行することができる。図5Bの（10）をさらに参照されたい。アクセス要求A4を搬送するデータパケットを受信した後、ネットワークインターフェースカード230の物理ネットワークインターフェースカードは、アクセス要求A4のターゲットアプリケーションアドレスを復元し、アクセス要求A4がサービスメッシュ識別子を有するかどうかを決定することができる。

次いで、ネットワークインターフェースカード230は、アクセス要求A4をユーザモードプロトコルスタック222に送信するステップ1014を実行することができる。あるいは、図5Bの（12）を参照されたい。ネットワークインターフェースカード230は、ネットワークインターフェースカード230とデータカード220との間の仮想ネットワークポートを介してアクセス要求A4をユーザモードプロトコルスタック222に転送する。

ユーザモードプロトコルスタック222は、アクセス要求A4のターゲットアプリケーションが特別なマイクロサービスであると決定するステップ1015を実行することができる。上述したように、初期化プロセスにおいて、ユーザモードプロトコルスタックは、特別なマイクロサービスリストを取得することができる。特別なマイクロサービスリストは、1つまたは複数の特別なマイクロサービスの識別情報を含む。識別情報は、ネットワークアドレスであってもよい。したがって、ステップ1015において、ユーザモードプロトコルスタック222は、ターゲットアプリケーションのネットワークアドレスに基づいて、ターゲットアプリケーションが特別なマイクロサービスであると決定することができ、すなわち、ターゲットアプリケーションのネットワークアドレスが特別なマイクロサービスリストに位置していると決定することができる。

アクセス要求A4のターゲットアプリケーションが特別なマイクロサービスであると決定した後、ユーザモードプロトコルスタック222は、アクセス要求A4をデータチャネル240に送信するステップ1016を実行することができる。データチャネル240は、アクセス要求A4をトラフィック遮断モジュール215に送信するステップ1017を実行することができる。トラフィック遮断モジュール215は、アクセス要求A4を特別なマイクロサービス2131に送信するステップ1018を実行することができる。

ステップ1016からステップ1018の実行については、図5Bの（13）を参照されたい。アクセス要求A4のターゲットアプリケーションが特別なマイクロサービス2131であると決定した後、ユーザモードプロトコルスタック222は、アクセス要求A4をデータチャネル240に直接送信することができる。アクセス要求A4がsocket接続要求であり、データチャネル240の、データカード120に位置する端部がアクセス要求A4を受信すると、端部は、アクセス要求A4をPCIeプロトコル下のデータフローに変換し、PCIeプロトコル下のデータフローをホスト210に送信することができる。PCIeの下のデータフローがデータチャネル240の、ホスト210に位置する端部に到達すると、PCIeの下のデータフローは、socket接続要求の形でアクセス要求A4に変換されてよい。ホスト210のシステムカーネルは、アクセス要求A4を特別なマイクロサービス2131に直接送信してもよい。

したがって、マイクロサービス1111と特別なマイクロサービス2131との接続が確立され、マイクロサービス1111が特別なマイクロサービス2131を呼び出すことができる。例えば、アクセス要求A4は、具体的にはsocket接続要求であってもよく、マイクロサービス1111と特別なマイクロサービス2131との間の確立された接続は、socket接続であってもよい。

実施形態5：ノード200上の共通アプリケーションは、ノード200上の別の共通アプリケーションを呼び出す。

次に、図11および図5Aおよび図5Bを参照して、共通アプリケーション212が共通アプリケーション211を呼び出す例を使用して、本実施形態で提供される解決策を説明する。

図11を参照されたい。共通アプリケーション212はアクセス要求A5を生成することができ、アクセス要求A5のターゲットアプリケーションアドレスは、共通アプリケーション211のネットワークアドレスである。共通アプリケーション212は、アクセス要求A5をトラフィック遮断モジュール215に送信するステップ1101を実行することができる。トラフィック遮断モジュール215は、アクセス要求A5のターゲットアプリケーションが共通アプリケーション211であると決定することができる。トラフィック遮断モジュール215は、アクセス要求A5を共通アプリケーション211に送信するステップ1102を実行することができる。

図5Bの（17a）を参照されたい。共通アプリケーション212によって開始されるアクセス要求の対象のアプリケーションは、共通アプリケーション211である。ホスト210のシステムカーネル内のトラフィック遮断モジュール215は、共通アプリケーション212が接続を要求するターゲットアプリケーションがローカルホスト上の共通アプリケーション211であると決定することができ、共通アプリケーション212によって開始されたアクセス要求を共通アプリケーション211にさらに直接送信することができる。

そのため、共通アプリケーション212と共通アプリケーション211との接続を確立し、共通アプリケーション212が共通アプリケーション211を呼び出すようにしてもよい。

実施形態6：ノード200は、ノード100のアクセス要求を転送する。

サービスメッシュシステムは、ノード500をさらに含むことができる。ネットワークの制限により、ノード100とノード500との間に直接通信接続はない。その結果、ノード100上のマイクロサービスによって送信されたアクセス要求をノード500に直接送信することは困難である。この場合、ノード100上のマイクロサービスがノード500上のアプリケーション（マイクロサービスまたは共通アプリケーションであり得る）を呼び出す必要があるとき、ノード200は、ノード500によって送信されたアクセス要求をノード100に転送することができる。言い換えれば、ノード200は、ノード100とノード500との間の中継ノードとして機能するために、中継サービスを提供することができる。中継サービスは、サービスメッシュ内のサービスである。言い換えれば、中継サービスは、1つまたは複数のマイクロサービスによって提供されてもよい。一例では、中継サービスは、具体的にはノード内の通信プロキシによって提供されてもよい。

次に、図12A、図12B、図5A、および図5Bを参照して、マイクロサービス1111がノード500上のサービスを呼び出す例を使用して、本実施形態で提供される解決策を説明する。

マイクロサービス1111は、ノード500上のアプリケーションを呼び出すように要求するために使用されるアクセス要求A6を生成することができる。説明を簡単にするために、ノード500上にあり、アクセス要求A6によって呼び出されるように要求されたアプリケーションは、アプリケーションBと呼ばれる場合がある。ノード100とノード500との間に直接通信接続がなく、アクセス要求A6がsocket接続要求である場合、マイクロサービス1111は、アプリケーションBのネットワークアドレスをアクセス要求A6の層C1のヘッダにカプセル化し、中継サービスのサービス識別子をアクセス要求A6の層C2の宛先アドレスとして使用する。層C2内の宛先アドレスは、アクセス要求A6の直接アドレスであり、アクセス要求A6の転送経路上のモジュールまたはコンポーネントは、層C2内の宛先アドレスを直接識別し、宛先アドレスに基づいてアクセス要求A6をルーティングすることができる。サービスメッシュシステムでは、マイクロサービス1111がアクセス要求を生成するとき、層C2内にあり、アクセス要求に対してマイクロサービス1111によって設定される宛先アドレスはサービス識別子であり、特定のモジュールまたはコンポーネントのアドレスではないことが理解されよう。サービス識別子は、アクセス要求が層C2内の宛先アドレスに基づいて通信プロキシに転送されることができるように、アクセス要求に対してサービス指向アーキテクチャ管理が実行される必要があることを識別するために使用される。例えば、層C2は、トランスポート層またはネットワーク7層プロトコルの第4層であってもよい。層C1は、層C2の上層である。例えば、層C1は、アプリケーション層またはネットワーク7層プロトコルにおける第7層であってもよい。

マイクロサービス1111は、アクセス要求A6をトラフィック遮断モジュール114に送信するステップ1201を実行することができる。トラフィック遮断モジュール114は、アクセス要求A6に対してサービス指向アーキテクチャ管理を実施する必要があると決定するために、アクセス要求A6のトランスポート層内の宛先アドレス、すなわち、中継サービスのサービス識別子が、管理必須リスト内に位置すると決定することができる。

トラフィック遮断モジュール114は、アクセス要求A6をデータチャネル140に転送するステップ1202を実行することができる。データチャネル140は、アクセス要求A6をユーザモードプロトコルスタック122に送信するステップ1203を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A6を通信プロキシ121に送信するステップ1204を実行することができる。

ステップ1201、ステップ1202、ステップ1203、およびステップ1204の具体的な実行については、ステップ701、ステップ702、ステップ703、およびステップ704の前述の説明、ならびに図5Aの（1）および（2）の前述の説明を参照されたい。ここでは詳細を繰り返さない。

通信プロキシ121は、アクセス要求A6に対してサービス指向アーキテクチャ管理を実行するステップ1205を実行することができる。具体的には、通信プロキシ121は、アクセス要求A6のための中継サービスを提供するアプリケーションを決定するために、アクセス要求A6内の層C1内のサービス識別子およびサービス指向アーキテクチャ管理ポリシーに基づいて、サービス指向アーキテクチャゲートウェイを実行することができる。例えば、ステップ1205において、ノード200内の通信プロキシ221がアクセス要求A6に対して中継サービスを提供すると決定されるように設定され得る。言い換えれば、通信プロキシ221がアクセス要求A6のターゲットアプリケーションであり、通信プロキシ221のネットワークアドレスがアクセス要求A6のターゲットアプリケーションアドレスであると決定される。そして、通信プロキシ121は、アクセス要求A6の層C2の宛先アドレスを、通信プロキシ221のネットワークアドレスに更新してもよい。例えば、通信プロキシ221のネットワークアドレスは、具体的にはリスニングポート3のネットワークアドレスであってもよい。通信プロキシ121は、ステップ1206において、更新されたアクセス要求A6をユーザモードプロトコルスタック122に送信することができる。

ユーザモードプロトコルスタック122は、アクセス要求A6のターゲットアプリケーションがこのノード上に位置していないと決定するステップ1207を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A6にサービスメッシュ識別子を追加するステップ1208を実行し、アクセス要求A6のターゲットアプリケーションアドレスをカプセル化するステップ1209を実行することができる。具体的には、通信プロキシ221のネットワークアドレスは、ノード200のIPアドレスにカプセル化されてもよい。ユーザモードプロトコルスタック122は、アドレスがカプセル化されているアクセス要求A6をネットワークインターフェースカード130に送信するステップ1210をさらに実行することができる。ネットワークインターフェースカード130は、アクセス要求A6をネットワークインターフェースカード230に送信するステップ1211を実行することができる。

ネットワークインターフェースカード230は、アクセス要求A6のターゲットアプリケーションアドレスを復元するステップ1212を実行し、アクセス要求A6がサービスメッシュ識別子を有すると決定するステップ1213を実行することができる。次いで、ネットワークインターフェースカード230は、アクセス要求A6をユーザモードプロトコルスタック222に送信するステップ1214を実行することができる。

ユーザモードプロトコルスタック222は、アクセス要求A6のターゲットアプリケーションが特別なマイクロサービスではないと決定するステップ1215を実行することができる。次に、ステップ1216において、ユーザモードプロトコルスタック222は、アクセス要求A6を通信プロキシ221に送信することができる。

ステップ1205からステップ1216の具体的な実行については、図8Aおよび図8Bのステップ805から816ならびに図5Aおよび図5Bの（2）、（3）、（4）、（10）、（12）、および（14）の前述の説明を参照されたい。ここでは詳細を繰り返さない。

引き続き図12Bを参照する。通信プロキシ221は、アプリケーションBのネットワークアドレスを取得するために、アクセス要求A6の層C1のヘッダを解析するステップ1217を実行することができる。通信プロキシ221は、アクセス要求A6に対してサービス指向アーキテクチャ管理を実行することをスキップすることができるが、アクセス要求A6のターゲットアプリケーションアドレスをアプリケーションBのネットワークアドレスに更新するステップ1218を実行する。言い換えれば、アクセス要求A6のターゲットアプリケーションがアプリケーションBに更新される。次に、更新されたアクセス要求A6をユーザモードプロトコルスタック222に送信するステップ1220を実行することができる。例えば、ステップ1220において、通信プロキシ221は、ユーザモードプロトコルスタック222のAPIを呼び出して、アクセス要求A6にサービス指向アーキテクチャ管理識別子を追加することができる。

ステップ1217から1220の実行については、図5Bの（15）を参照されたい。通信プロキシ221は、アクセス要求A6をインバウンドトラフィックとして記録し、アクセス要求A6のデータパケット内の内容（すなわち、層C1の内容）に基づいて、ノード200がアクセス要求A6の中継ノードであると決定することができる。このようにして、通信プロキシ221は、後続のサービス指向アーキテクチャ管理をスキップし、アクセス要求A6のターゲットアプリケーションアドレスをアプリケーションBのアドレスに更新し、アクセス要求A6はインバウンドトラフィックであるため、ユーザモードプロトコルスタック222のAPIを呼び出して、アクセス要求A6にサービス指向アーキテクチャ管理識別子を追加する。

ユーザモードプロトコルスタック222は、アクセス要求A6のターゲットアプリケーションがこのノード（ノード200）上に位置していないと決定するステップ1221を実行し、アクセス要求A6のターゲットアプリケーションアドレスをカプセル化するステップ1222を実行することができる。例えば、アプリケーションBのネットワークアドレスは、ノード500のIPアドレスにカプセル化されてもよい。一例では、アプリケーションBがマイクロサービスである場合、ユーザモードプロトコルスタック222は、アクセス要求A6にサービスメッシュ識別子をさらに追加することができる。次いで、ステップ1223において、ユーザモードプロトコルスタック222は、アクセス要求A6をネットワークインターフェースカード230に送信することができる。ネットワークインターフェースカード230は、アクセス要求A6をノード500に送信するステップ1224を実行することができる。

ステップ1221から1224の実行については、図5Bの（16）を参照されたい。ユーザモードプロトコルスタック222は、アクセス要求A6のターゲットアプリケーションがこのノード上に位置していないと決定し、アクセス要求A6のサービス指向アーキテクチャ管理識別子に基づいて、アクセス要求A6がインバウンドトラフィックであると決定することができる。この場合、ユーザモードプロトコルスタック222は、サービスメッシュ識別子をアクセス要求A6に追加し、ターゲットアプリケーションアドレスをカプセル化し、次いで、ネットワーク300を使用することによってアクセス要求A6をノード500に送信するために、ネットワークインターフェースカード230を使用することによってアクセス要求A6をネットワーク300に送信することができる。

前述の解決策によれば、ノードと別のノードとの間に直接通信接続がない場合、ノード間の間接通信を実施するために、別のノードが中継ノードとして使用され得る。

実施形態7：ノード100上の共通アプリケーションは、ノード200上のマイクロサービスを呼び出す。

一般的なアプリケーションがマイクロサービスを呼び出す必要があるシナリオでは、通信プロキシはインバウンドゲートウェイとして構成することができる。インバウンドゲートウェイは、サービスメッシュゲートウェイとも呼ばれ得る。アクセス要求の宛先アドレスがサービスメッシュゲートウェイアドレスであるとき、アクセス要求がサービスメッシュ識別子を含まない場合であっても、ネットワークインターフェースカードはアクセス要求をデータカードに送信することができ、その結果、データカードは、アクセス要求に対してサービス指向アーキテクチャ管理を実行し、アクセス要求を対応するマイクロサービスに送信する。このようにして、共通アプリケーションは、マイクロサービスを呼び出す。

次に、図13A、図13B、図5A、および図5Bを参照して、共通アプリケーション113がマイクロサービス2141を呼び出す例を使用して、本実施形態で提供するマイクロサービスを共通アプリケーションが呼び出す解決策を説明する。

共通アプリケーション113は、ノード200のサービスメッシュゲートウェイアドレスを初期宛先アドレスとして使用するアクセス要求A7を生成することができる。また、サービス要求A7は、共通アプリケーション113によって必要とされるサービスのサービス識別子をさらに含んでもよい。サービス識別子については、前述の説明を参照されたい。ここでは詳細を繰り返さない。例えば、アクセス要求A7はデータパケットであってもよく、サービス識別子はデータパケットのアプリケーション層のヘッダにカプセル化されてもよい。加えて、アクセス要求A7の宛先アドレスは、通常トランスポート層に位置することが理解されよう。

共通アプリケーション113は、アクセス要求A7をネットワークインターフェースカード130に送信するステップ1301を実行することができる。図5Aの（5）を参照されたい。アクセス要求A7がトラフィック遮断モジュール114を通過すると、トラフィック遮断モジュール114は、アクセス要求A7の初期宛先アドレスが管理必須リスト内にないと決定する。例えば、アクセス要求A7の初期宛先アドレスは、トランスポート層に位置するアドレスであってもよい。すなわち、トラフィック遮断モジュール114は、アクセス要求A7のトランスポート層のアドレスが管理必須リスト内にないと決定する。さらに、トラフィック遮断モジュール114は、仮想ネットワークポートを介してネットワークインターフェースカード130にアクセス要求A7を送信することができる。

ネットワークインターフェースカード130は、アクセス要求A7の初期宛先アドレスをカプセル化するステップ1302を実行することができる。例えば、初期宛先アドレスとして使用されるサービスメッシュゲートウェイアドレスは、通信プロキシ221のリスニングポートのネットワークアドレスであってもよい。リスニングポートのネットワークアドレスは、ノード200のIPアドレスにカプセル化され得る。

ネットワークインターフェースカード130は、その初期宛先アドレスがカプセル化されているアクセス要求A7をネットワークインターフェースカード230に送信するステップ1303を実行することができる。詳細については、図5Bの（10）を参照されたい。ステップ1303において、アクセス要求A7は、ネットワークインターフェースカード130の物理ネットワークインターフェースカードを介してネットワーク300に入ることができ、ネットワーク300によって転送された後にネットワークインターフェースカード230の物理ネットワークインターフェースカードによって受信され得る。

ネットワークインターフェースカード230は、アクセス要求A7の初期宛先アドレスを復元するステップ1304を実行することができる。すなわち、サービスメッシュゲートウェイアドレスが復元される。ネットワークインターフェースカード230は、アクセス要求A7をユーザモードプロトコルスタック222に送信するステップ1305を実行することができる。図5Bの（17b）および（12）を参照されたい。ネットワークインターフェースカード230は、アクセス要求A7の初期宛先アドレスがサービスメッシュゲートウェイアドレスであると決定することができる。アクセス要求A7の初期宛先アドレスがサービスメッシュゲートウェイアドレスである場合、アクセス要求A7がサービスメッシュ識別子を有していなくても、ネットワークインターフェースカード230は、仮想ネットワークポートを介してユーザモードプロトコルスタック222にアクセス要求A7を送信することができる。

ユーザモードプロトコルスタック222は、アクセス要求A7の初期宛先アドレスがサービスメッシュゲートウェイアドレスであると決定するステップ1306を実行することができ、次いで、アクセス要求A7を通信プロキシ221に送信するステップ1307を実行することができる。例えば、図5Bの（14）を参照されたい。初期宛先アドレスは、具体的には通信プロキシ221のリスニングポート3のネットワークアドレスに設定されてもよい。初期宛先アドレスが特別なマイクロサービスのアドレスではなく、アクセス要求A7がサービスメッシュ識別子を有していないと決定した場合、ユーザモードプロトコルスタック222は、アクセス要求A7を通信プロキシ221のリスニングポート3に送信することができる。

通信プロキシ221は、アクセス要求A7によって実際に要求されたサービスを決定するステップ1308を実行することができる。上述したように、アクセス要求A7はサービス識別子を搬送し、サービス識別子は、共通アプリケーション113によって要求されたサービスを示すために使用される。サービス識別子は、アクセス要求A7のアプリケーション層のヘッダ内にあってもよい。通信プロキシ221は、サービス識別子を取得するために、アクセス要求A7を解析することができ、例えば、アクセス要求A7のアプリケーション層のヘッダを解析することができる。サービス識別子を取得した後、通信プロキシ221は、アクセス要求A7に対してサービス指向アーキテクチャ管理を実行するステップ1309を実行することができる。具体的には、サービス識別子によって示されるサービスを提供するために使用されるマイクロサービスは、サービスリストおよびサービス指向アーキテクチャ管理ポリシーを使用することによって、サービス識別子に基づいて決定され得る。この実施形態では、サービス識別子によって示されるサービスを提供するためにマイクロサービス2141が使用されると決定されてもよい。次に、通信プロキシ221は、アクセス要求A7をユーザモードプロトコルスタック222に送信するステップ1310を実行することができる。ステップ1308からステップ1310の実行については、図5Bの（14）を参照されたい。通信プロキシ221は、リスニングポート3を介してアクセス要求A7を受信すると、アクセス要求A7をインバウンドトラフィックとして記録することができる。アクセス要求A7に対してサービス指向アーキテクチャ管理が実行された後、アクセス要求A7がアップストリームモジュールまたはコンポーネントに送信されると、ユーザモードプロトコルスタック222のAPIは、アクセス要求A7にサービス指向アーキテクチャ管理識別子を追加するために呼び出され得る。

本実施形態では、サービスのサービス識別子は、略してサービスの識別子と呼ばれる場合がある。

ユーザモードプロトコルスタック222は、アクセス要求A7をマイクロサービス2141に送信するステップ1311を実行することができる。ステップ1311の具体的なプロセスについては、図8Bのステップ819から821の前述の説明を参照されたい。ここでは詳細を繰り返さない。

したがって、共通アプリケーション113とマイクロサービス2141との接続を確立し、共通アプリケーション113がマイクロサービス2141を呼び出すようにしてもよい。例えば、アクセス要求A7は、具体的にはsocket接続要求であってもよく、共通アプリケーション113とマイクロサービス2141との間に確立された接続は、socket接続であってもよい。

実施形態8：ノード100上のマイクロサービスは、ノード200の共通アプリケーションを呼び出す。

サービスメッシュシステムにおけるいくつかの共通アプリケーションは、マイクロサービスによって呼び出され得る。この実施形態では、これらの共通アプリケーションがマイクロサービスによって呼び出されることを可能にするために、これらの共通アプリケーションによって提供されるサービスのサービス識別子を事前定義することができる。サービスCが一例として使用される。サービスCのサービス識別子は、サービスCを記述または示す情報であってもよい。サービスCは、共通アプリケーションによって提供されてもよい。これらの共通アプリケーションによって提供されるサービスのサービス識別子は、管理必須リストに設定されてもよい。この実施形態では、説明を容易にするために、共通アプリケーションによって提供されるサービスのサービス識別子は、共通アプリケーションのサービス識別子と呼ばれてもよい。例えば、共通アプリケーションのサービス識別子は、共通アプリケーションのネットワークアドレスであってもよい。一例では、共通アプリケーションのネットワークアドレスは、共通アプリケーションのIPアドレスおよびポート番号を含んでもよい。

上述したように、管理必須リストは、サービスメッシュシステムの開発者または運用および保守担当者によって事前構成されてもよい。管理必須リストが構成されると、マイクロサービスによって呼び出され得る共通アプリケーションのサービス識別子が、管理必須リストに追加されてもよい。管理必須リストが共通アプリケーションのサービス識別子を含む場合、通信プロキシのサービス指向アーキテクチャ管理を受け入れるために、共通アプリケーションのサービス識別子を搬送するアクセス要求をデータカードに送信することができる。したがって、共通アプリケーションのサービス識別子は、アクセス要求に対してサービス指向アーキテクチャ管理を実行する必要があることを宣言するために使用される。

いくつかの実施形態では、サービスリストはまた、サービス識別子と共通アプリケーションのネットワークアドレスとの間の対応関係を含むことができ、その結果、通信プロキシは、サービス識別子に基づいてアクセス可能なネットワークアドレスを決定することができる。サービスリストは、ネットワークアドレスに対応するアプリケーションのタイプを含み、アプリケーションのタイプは、マイクロサービスと共通アプリケーションとに分類され得る。具体的には、サービスリストは、ネットワークアドレスに対応するアプリケーションがマイクロサービスであるか共通アプリケーションであるかを記録する。

管理必須リストおよびサービスリストの具体的な構成方法については、図6に示される実施形態の前述の説明を参照されたい。ここでは詳細を繰り返さない。

次に、図14A、図14B、図5A、および図5Bを参照して、マイクロサービス1111が共通アプリケーション211を呼び出す例を使用して、マイクロサービスが本実施形態で提供される共通アプリケーションを呼び出す解決策を説明する。

マイクロサービス1111が共通アプリケーション211によって提供されるサービスを使用する必要があるとき、マイクロサービス1111は、アクセス要求A8を生成し、アクセス要求A8の初期宛先アドレスとしてサービスのサービス識別子を使用することができる。

マイクロサービス1111は、アクセス要求A8をトラフィック遮断モジュール114に送信するステップ1401を実行することができる。トラフィック遮断モジュール114は、アクセス要求A8の初期宛先アドレスまたはアクセス要求A8で搬送されたサービス識別子が管理必須リスト内にあると決定することができ、トラフィック遮断モジュール114は、アクセス要求A8をデータチャネル140に送信するステップ1402を実行することができる。データチャネル140は、アクセス要求A8をユーザモードプロトコルスタック122に送信するステップ1403を実行することができる。ユーザモードプロトコルスタック122は、アクセス要求A8を通信プロキシ121に送信するステップ1404を実行することができる。ステップ1401から1404の実行については、図7のステップ701から704ならびに図5Aの（1）および（2）の前述の説明を参照されたい。ここでは詳細を繰り返さない。

通信プロキシ121は、アクセス要求A8に対してサービス指向アーキテクチャ管理を実行するステップ1405を実行することができる。サービス指向アーキテクチャ管理は、アクセス要求A8で搬送されたサービス識別子に基づいて、サービスリストを使用することによって、および負荷分散ポリシーに基づいて、サービス識別子によって記述されたサービスを提供することができるアプリケーションを決定することを含んでもよい。決定されたアプリケーションは、共通アプリケーション211に設定されてもよい。ステップ1405の後、共通アプリケーション211のネットワークアドレスがアクセス要求A8のターゲットアプリケーションアドレスとして決定され、それに対応して、共通アプリケーション211がアクセス要求A8のターゲットアプリケーションとして決定される。

通信プロキシ121は、アクセス要求A8に非サービスメッシュ識別子を追加するステップ1406を実行することができる。非サービスメッシュ識別子は、非サービスメッシュ識別子を搬送するアクセス要求のターゲットアプリケーションがマイクロサービスではないことを示すために使用される。上述したように、サービスリストは、ネットワークアドレスに対応するアプリケーションのタイプを記録する。共通アプリケーション211のネットワークアドレスがアクセス要求A8のターゲットアプリケーションアドレスとして決定されたと決定されると、アクセス要求A8のターゲットアプリケーションはサービスメッシュ内のマイクロサービスではなく共通アプリケーションであると決定され得る。したがって、非サービスメッシュ識別子は、アクセス要求A8に追加され得る。例えば、通信プロキシ121は、APIを呼び出して、アクセス要求A8に非サービスメッシュ識別子を追加してもよい。

ステップ1406を実行した後、通信プロキシ121は、アクセス要求A8をユーザモードプロトコルスタック122に送信するステップ1407を実行することができる。

ユーザモードプロトコルスタック122は、アクセス要求A8のターゲットアプリケーションがこのノード上に位置していないと決定し、アクセス要求A8が非サービスメッシュ識別子を有すると決定するステップ1408を実行することができる。次いで、ユーザモードプロトコルスタック122は、アクセス要求A8のターゲットアプリケーションアドレスをカプセル化するステップ1409を実行することができる。具体的には、アクセス要求A8のターゲットアプリケーションアドレスは、ノード200のIPアドレスにカプセル化されてもよい。

次いで、ユーザモードプロトコルスタック122は、アクセス要求A8をネットワークインターフェースカード130に送信することができる。アクセス要求A8を受信すると、ネットワークインターフェースカード130は、アクセス要求A8をネットワークインターフェースカード230に送信するステップ1411を実行することができる。

アクセス要求A8を受信すると、ネットワークインターフェースカード230は、アクセス要求A8のターゲットアプリケーションアドレスを復元するステップ1412を実行することができる。ステップ1413およびステップ1414をさらに実行することができる。ステップ1413では、アクセス要求A8がサービスメッシュ識別子を有していないと決定することができ、アクセス要求A8が非サービスメッシュ識別子を有すると決定することができる。ステップ1414において、アクセス要求A8のターゲットアプリケーションアドレスはサービスメッシュゲートウェイアドレスではないと決定される。したがって、ネットワークインターフェースカード230は、アクセス要求A8を共通アプリケーション211に直接送信するステップ1415を実行することができる。

図5Bの（11）を参照されたい。A8がサービスメッシュ識別子を有さず、アクセス要求A8のターゲットアプリケーションアドレスがサービスメッシュゲートウェイアドレスではない場合、ネットワークインターフェースカード230はもはやアクセス要求A8をデータカード220に送信しないが、仮想ネットワークポートを介してアクセス要求A8をホスト210に直接送信し、その結果、ホスト210はアクセス要求A8を共通アプリケーション211に直接送信することができる。

したがって、マイクロサービス1111と共通アプリケーション211との接続が確立され、マイクロサービス1111は、共通アプリケーション211を呼び出す。例えば、アクセス要求A8は、具体的にはsocket接続要求であってもよく、マイクロサービス1111と共通アプリケーション211との間に確立された接続は、socket接続であってもよい。

上記の説明から分かるように、本出願のこの実施形態では、サイドカーはデータカードに配備されてもよく、その結果、サービスメッシュ内のサービス呼び出しは、処理および送信のためにデータカードにシンクすることができる。したがって、ホストのコンピューティングリソースがそれ以上占有されることはなく、サービス指向アーキテクチャ管理効率が改善され、ホストのコンピューティングリソースが節約される。加えて、クライアントアプリケーションは、再構築されることなく、本出願のこの実施形態で提供されるサービスメッシュシステムに適用することができる。したがって、サービスメッシュシステムは利用価値が高い。

前述の実施形態に関連して、本出願の一実施形態は、サービスメッシュシステムをさらに提供する。図4に示されるように、サービスシステムは、ノード100を含むことができる。ノード100は、ホスト110およびデータカード120を含む。データカード120は、ホスト110に挿入される。データカード120とホスト110との間にデータチャネル140が確立される。第1のポッドは、ホスト110上で動作する。第1のポッドには、第1のマイクロサービスが設けられる。データカード120は、ネットワーク300にアクセスする。

データカード120は、ネットワーク300を使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信し、サービス指向アーキテクチャ管理ポリシーに基づいて、ホスト110によってデータチャネル140を介してデータカード120に送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行することができる。第1のアクセス要求は、第2のマイクロサービスに対する第1のマイクロサービスのアクセス要求であり、第1のポッドからホスト110によって取得される。詳細については、図5Aおよび図5B、図6、および図7に示される実施形態の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービス指向アーキテクチャ管理ポリシーは、第2のマイクロサービスと、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含む。データカード120は、サービス指向アーキテクチャ管理ポリシーに基づいて、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスを決定し、第1のアクセス要求の宛先アドレスを第2のポッドのネットワークアドレスに設定し、第2のポットがホスト110に配置されていると決定し、データチャネル140を介して第2のポッドに修正された第1のアクセス要求を送信するように構成される。詳細については、実施形態1の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含む。ホスト110は、第1のポッドから、第3のマイクロサービスに対する第1のマイクロサービスの第2のアクセス要求を取得し、データチャネル140を介してデータカード120に第2のアクセス要求を送信するようにさらに構成される。データカード120は、サービス指向アーキテクチャ管理ポリシーに基づいて、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスを決定し、第2のアクセス要求の宛先アドレスを第3のポッドのネットワークアドレスに設定し、第3のポッドがホスト110に配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信するように構成される。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

これらの実施形態の一例では、ノード100は、ネットワークインターフェースカード130をさらに含む。ネットワークインターフェースカード130は、データカード120に接続されている。データカード120は、ネットワークインターフェースカード130を使用することによってネットワークにアクセスする。データカード120は、第2のアクセス要求をネットワークインターフェースカード130に送信するように構成される。ネットワークインターフェースカード130は、ネットワークを使用することによって第2のアクセス要求を送信するように構成される。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

この例の一例では、図4を参照されたい。サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210、データカード220、およびネットワークインターフェースカード230を含む。データカード220は、ホスト210に挿入される。データカード220とホスト210との間にデータチャネル240が確立される。第3のポッドは、ホスト210上で動作する。ネットワークインターフェースカード230は、データカード220に接続されている。ネットワークインターフェースカード230は、ネットワークにアクセスする。データカード120は、第3のポッドがホスト110に配置されていないと決定した場合、第2のアクセス要求に対してサービスメッシュ識別子を設定するようにさらに構成される。ネットワークインターフェースカード230は、ネットワークインターフェースカード130によって送信された第2のアクセス要求を受信し、第2のアクセス要求がサービスメッシュ識別子を搬送していると決定した場合、データカード220に第2のアクセス要求を送信するように構成される。データカード220は、第3のポッドがホスト210に配置されていると決定した場合、データチャネル240を介して第3のポッドに第2のアクセス要求を送信するように構成される。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210を含む。ホスト210およびホスト110は、ネットワークにアクセスする。第1のアプリケーションは、ホスト110上で動作する。第2のアプリケーションは、ホスト210上で動作する。ホスト110は、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションがホスト110上で動作していないと決定した場合、ネットワークを使用することによって第3のアクセス要求を送信するように構成される。ホスト210は、ホスト110によって送信された第3のアクセス要求を受信し、第3のアクセス要求を第2のアプリケーションに送信するように構成される。詳細については、実施形態3の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、第1のアプリケーションおよび第2のアプリケーションは、ホスト110上で動作する。ホスト110は、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションがホスト110上で動作していると決定した場合、第3のアクセス要求を第2のアプリケーションに送信するように構成される。詳細については、実施形態5の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210およびデータカード220を含む。データカード220は、ホスト210に挿入される。データカード220とホスト210との間にデータチャネル240が確立される。第4のポッドは、ホスト210上で動作する。第4のポッドには、第4のマイクロサービスが設けられる。データカード220およびホスト110は、ネットワークにアクセスする。第1のアプリケーションは、ホスト110上で動作する。ホスト110は、データカード220のネットワークアドレスに対する第1のアプリケーションの第4のアクセス要求を取得し、ネットワークを使用することによって第4のアクセス要求を送信するように構成される。データカード220は、ホスト110によって送信された第4のアクセス要求を受信し、第4のマイクロサービスのものである、第4のアクセス要求で搬送された識別子に基づいて、データチャネル240を介して第4のマイクロサービスに第4のアクセス要求を送信するように構成される。詳細については、実施形態7の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210を含む。第3のアプリケーションは、ホスト210上で動作する。ホスト210は、ネットワークにアクセスする。ホスト110は、第3のアプリケーションのネットワークアドレスに対する第1のマイクロサービスの第5のアクセス要求を取得し、データチャネル140を介してデータカード120に第5のアクセス要求を送信するように構成される。データカード120は、ネットワークを使用することによって第5のアクセス要求を送信するように構成される。ホスト210は、第5のアクセス要求を受信し、第5のアクセス要求を第3のアプリケーションに送信するように構成される。詳細については、実施形態8の前述の説明を参照されたい。ここでは詳細を繰り返さない。

図15を参照されたい。本出願の一実施形態は、データ処理方法を提供する。本方法は、図4に示されるサービスメッシュシステムに適用されてもよい。図15に示されたように、方法は以下のステップを含む。

ステップ1501：データカード120は、ネットワークを使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信する。

ステップ1502：データカード120は、サービス指向アーキテクチャ管理ポリシーに基づいて、ホスト110によってデータチャネル140を介してデータカード120に送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行する。第1のアクセス要求は、第2のマイクロサービスに対する第1のマイクロサービスのアクセス要求であり、第1のポッドからホスト110によって取得される。

詳細については、図5Aおよび図5B、図6、および図7に示される実施形態の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービス指向アーキテクチャ管理ポリシーは、第2のマイクロサービスと、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含む。ステップ1502は、データカード120が、サービス指向アーキテクチャ管理ポリシーに基づいて、第2のマイクロサービスを実行する第2のポッドのネットワークアドレスを決定し、第1のアクセス要求の宛先アドレスを第2のポッドのネットワークアドレスに設定することを含む。データカード120は、第2のポットがホスト110上に配置されていると決定し、データチャネル140を介して第2のポッドに修正された第1のアクセス要求を送信する。詳細については、実施形態1の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含む。本方法は、ホスト110が、第1のポッドから、第3のマイクロサービスに対する第1のマイクロサービスの第2のアクセス要求を取得し、データチャネル140を介してデータカード120に第2のアクセス要求を送信することをさらに含む。データカード120は、サービス指向アーキテクチャ管理ポリシーに基づいて、第3のマイクロサービスを実行する第3のポッドのネットワークアドレスを決定し、第2のアクセス要求の宛先アドレスを第3のポッドのネットワークアドレスに設定する。データカード120は、第3のポッドがホスト110上に配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信する。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

これらの実施形態の一例では、ノード100は、ネットワークインターフェースカード130をさらに含む。ネットワークインターフェースカード130は、データカード120に接続されている。データカード120は、ネットワークインターフェースカード130を使用することによってネットワークにアクセスする。データカード120が、第3のポッドがホスト110上に配置されていないと決定し、ネットワークを使用することによって第2のアクセス要求を送信することは、データカード120が、第3のポッドがホスト110上に配置されていないと決定し、第2のアクセス要求をネットワークインターフェースカード130に送信することを含む。ネットワークインターフェースカード130は、ネットワークを使用することによって第2のアクセス要求を送信する。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

この例の一例では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210、データカード220、およびネットワークインターフェースカード230を含む。データカード220は、ホスト210に挿入される。データカード220とホスト210との間にデータチャネル240が確立される。第3のポッドは、ホスト210上で動作する。ネットワークインターフェースカード230は、データカード220に接続されている。ネットワークインターフェースカード230は、ネットワークにアクセスする。本方法は、第3のポッドがホスト110上に配置されていないと決定した場合に、データカード120が、第2のアクセス要求のサービスメッシュ識別子を設定することをさらに含む。ネットワークインターフェースカード230は、ネットワークインターフェースカード130によって送信された第2のアクセス要求を受信し、第2のアクセス要求がサービスメッシュ識別子を搬送していると決定した場合、データカード220に第2のアクセス要求を送信する。データカード220は、第3のポッドがホスト210上に配置されていると決定した場合、データチャネル240を介して第3のポッドに第2のアクセス要求を送信する。詳細については、実施形態2の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210を含む。ホスト210およびホスト110は、ネットワークにアクセスする。第1のアプリケーションは、ホスト110上で動作する。第2のアプリケーションは、ホスト210上で動作する。本方法は以下をさらに含む。

ホスト110は、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションがホスト110上で動作していないと決定した場合、ネットワークを使用することによって第3のアクセス要求を送信する。ホスト210は、ホスト110によって送信された第3のアクセス要求を受信し、第3のアクセス要求を第2のアプリケーションに送信する。詳細については、実施形態3の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、第1のアプリケーションおよび第2のアプリケーションは、ホスト110上で動作する。本方法は、ホスト110が、第2のアプリケーションのネットワークアドレスに対する第1のアプリケーションの第3のアクセス要求を取得し、第2のアプリケーションがホスト110上で動作していると決定した場合、第3のアクセス要求を第2のアプリケーションに送信することをさらに含む。詳細については、実施形態5の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210およびデータカード220を含む。データカード220は、ホスト210に挿入される。データカード220とホスト210との間にデータチャネル240が確立される。第4のポッドは、ホスト210上で動作する。第4のポッドには、第4のマイクロサービスが設けられる。データカード220およびホスト110は、ネットワークにアクセスする。第1のアプリケーションは、ホスト110上で動作する。本方法は、ホスト110が、データカード220のネットワークアドレスに対する第1のアプリケーションの第4のアクセス要求を取得し、ネットワークを使用することによって第4のアクセス要求を送信することをさらに含む。データカード220は、ホスト110によって送信された第4のアクセス要求を受信し、第4のマイクロサービスのものである、第4のアクセス要求で搬送された識別子に基づいて、データチャネル240を介して第4のマイクロサービスに第4のアクセス要求を送信する。詳細については、実施形態7の前述の説明を参照されたい。ここでは詳細を繰り返さない。

いくつかの実施形態では、サービスメッシュシステムは、ノード200をさらに含む。ノード200は、ホスト210を含む。第3のアプリケーションは、ホスト210上で動作する。ホスト210は、ネットワークにアクセスする。本方法は、ホスト110が、第3のアプリケーションのネットワークアドレスに対する第1のマイクロサービスの第5のアクセス要求を取得し、データチャネル140を介してデータカード120に第5のアクセス要求を送信することをさらに含む。データカード120は、ネットワークを使用することによって第5のアクセス要求を送信する。ホスト210は、第5のアクセス要求を受信し、第5のアクセス要求を第3のアプリケーションに送信する。詳細については、実施形態8の前述の説明を参照されたい。ここでは詳細を繰り返さない。

図16を参照されたい。本出願の一実施形態は、ホスト1610およびデータカード1620を含むネットワークノード1600をさらに提供する。データカード1620は、ホスト1610に挿入される。例えば、図16に示されるように、データカード1620は、PCIeインターフェースを使用することによってホスト1610に挿入される。

ホスト1610は、プロセッサ1611およびメモリ1612を含んでもよい。メモリ1612はコンピュータ命令を記憶し、コンピュータ命令はプロセッサ1611によって実行されてもよい。データカード1620は、プロセッサ1621およびメモリ1622を含んでもよい。メモリ1622はコンピュータ命令を記憶し、コンピュータ命令はプロセッサ1621によって実行されてもよい。メモリ1612に記憶されたコンピュータ命令がプロセッサ1611によって実行され、メモリ1622に記憶されたコンピュータ命令がプロセッサ1621によって実行されると、ネットワークノード1600は、図5Aおよび図5Bから図15に示される実施形態においてノード100またはノード200によって実行される動作を実行することができる。

本出願の実施形態におけるプロセッサは、中央処理部（central processing unit，CPU）であってもよく、プロセッサはさらに別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor，DSP）、特定用途向け集積回路（application specific integrated circuit，ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array，FPGA）もしくは別のプログラマブルロジックデバイス、トランジスタ論理回路、ハードウェアコンポーネント、もしくはそれらの任意の組み合わせであってもよいことが理解されよう。汎用プロセッサは、マイクロプロセッサまたは任意の従来のプロセッサであり得る。本出願の実施形態における様々な番号は、説明を容易にするための区別のために単に使用されているにすぎず、本出願の実施形態の範囲を限定するために使用されているものではない、ということが理解されよう。

100 ノード
110 ホスト
111 ポッド
112 ポッド
113 共通アプリケーション
114 トラフィック遮断モジュール
120 データカード
121 通信プロキシ
122 ユーザモードプロトコルスタック
123 制御プレーンプロキシ
130 ネットワークインターフェースカード
140 データチャネル
200 ノード
210 ホスト
211 共通アプリケーション
212 共通アプリケーション
213 ポッド
214 ポッド
215 トラフィック遮断モジュール
220 データカード
221 通信プロキシ
222 ユーザモードプロトコルスタック
223 制御プレーンプロキシ
230 ネットワークインターフェースカード
240 データチャネル
300 ネットワーク
400 制御プレーン
500 ノード
1111 マイクロサービス
1112 ネットワークポート
1121 マイクロサービス
1122 ネットワークポート
1600 ネットワークノード
1610 ホスト
1611 プロセッサ
1612 メモリ
1620 データカード
1621 プロセッサ
1622 メモリ
2131 マイクロサービス
2132 ネットワークポート
2141 マイクロサービス
2142 ネットワークポート

Claims (18)

1. 第1のノードを備え、前記第1のノードは第1のホストおよび第1のデータカードを含み、前記第1のデータカードは前記第1のホストに挿入され、前記第1のデータカードと前記第1のホストとの間に第1のデータチャネルが確立され、第1のポッドは前記第1のホスト上で動作し、前記第1のポッドに第1のマイクロサービスが提供され、前記第1のデータカードはネットワークにアクセスし、前記ネットワークを使用することによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信し、前記サービス指向アーキテクチャ管理ポリシーに基づいて、前記第1のホストによって前記第1のデータチャネルを介して前記第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行し、前記第1のアクセス要求は、第2のマイクロサービスの前記第1のマイクロサービスのものであり、前記第1のポッドから前記第1のホストによって取得されたアクセス要求である、マイクロサービスベースのサービスメッシュシステム。
2. 前記サービス指向アーキテクチャ管理ポリシーは、前記第2のマイクロサービスと前記第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含み、
   前記第1のデータカードは、前記サービス指向アーキテクチャ管理ポリシーに基づいて、前記第2のマイクロサービスを実行する前記第2のポッドの前記ネットワークアドレスを決定し、前記第1のアクセス要求の宛先アドレスを前記第2のポッドの前記ネットワークアドレスに設定し、前記第2のポッドが前記第1のホストに配置されていると決定し、前記第1のデータチャネルを介して前記第2のポッドに修正された第1のアクセス要求を送信するように構成されている、請求項1に記載のサービスメッシュシステム。
3. 前記サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと前記第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含み、
   前記第1のホストは、前記第1のポッドから、前記第3のマイクロサービスに対する前記第1のマイクロサービスの第2のアクセス要求を取得し、前記第2のアクセス要求を、前記第1のデータチャネルを介して前記第1のデータカードに送信するようにさらに構成され、
   前記第1のデータカードは、前記サービス指向アーキテクチャ管理ポリシーに基づいて、前記第3のマイクロサービスを実行する前記第3のポッドの前記ネットワークアドレスを決定し、前記第2のアクセス要求の宛先アドレスを前記第3のポッドの前記ネットワークアドレスに設定し、前記第3のポッドが前記第1のホストに配置されていないと決定し、前記ネットワークを使用することによって前記第2のアクセス要求を送信するように構成されている、請求項1に記載のサービスメッシュシステム。
4. 前記第1のノードは第1のネットワークインターフェースカードをさらに備え、前記第1のネットワークインターフェースカードは前記第1のデータカードに接続され、前記第1のデータカードは前記第1のネットワークインターフェースカードを使用することによって前記ネットワークにアクセスし、
   前記第1のデータカードは、前記第2のアクセス要求を前記第1のネットワークインターフェースカードに送信するように構成され、
   前記第1のネットワークインターフェースカードは、前記ネットワークを使用することによって前記第2のアクセス要求を送信するように構成されている、請求項3に記載のサービスメッシュシステム。
5. 第2のノードをさらに備え、前記第2のノードは、第2のホストと、第2のデータカードと、第2のネットワークインターフェースカードとを備え、前記第2のデータカードは前記第2のホストに挿入され、前記第2のデータカードと前記第2のホストとの間に第2のデータチャネルが確立され、前記第3のポッドは前記第2のホスト上で動作し、前記第2のネットワークインターフェースカードは前記第2のデータカードに接続され、前記第2のネットワークインターフェースカードは前記ネットワークにアクセスし、
   前記第1のデータカードは、前記第3のポッドが前記第1のホストに配置されていないと決定した場合に、前記第2のアクセス要求にサービスメッシュ識別子を設定するようにさらに構成され、
   前記第2のネットワークインターフェースカードは、前記第1のネットワークインターフェースカードによって送信された前記第2のアクセス要求を受信し、前記第2のアクセス要求が前記サービスメッシュ識別子を搬送していると決定した場合に、前記第2のデータカードに前記第2のアクセス要求を送信するように構成され、
   前記第2のデータカードは、前記第3のポッドが前記第2のホスト上に配置されていると決定した場合に、前記第2のデータチャネルを介して前記第3のポッドに前記第2のアクセス要求を送信するように構成されている、請求項4に記載のサービスメッシュシステム。
6. 第3のノードをさらに備え、前記第3のノードは第3のホストを備え、前記第3のホストおよび前記第1のホストは前記ネットワークにアクセスし、第1のアプリケーションは前記第1のホスト上で動作し、第2のアプリケーションは前記第3のホスト上で動作し、
   前記第1のホストは、前記第2のアプリケーションのネットワークアドレスに対する前記第1のアプリケーションの第3のアクセス要求を取得し、前記第2のアプリケーションが前記第1のホスト上で動作していないと決定した場合に、前記ネットワークを使用することによって前記第3のアクセス要求を送信するように構成され、
   前記第3のホストは、前記第1のホストによって送信された前記第3のアクセス要求を受信し、前記第3のアクセス要求を前記第2のアプリケーションに送信するように構成されている、請求項1から5のいずれか一項に記載のサービスメッシュシステム。
7. 第1のアプリケーションおよび第2のアプリケーションは前記第1のホスト上で動作し、
   前記第1のホストは、前記第2のアプリケーションのネットワークアドレスに対する前記第1のアプリケーションの第3のアクセス要求を取得し、前記第2のアプリケーションが前記第1のホスト上で動作していると決定した場合に、前記第3のアクセス要求を前記第2のアプリケーションに送信するように構成されている、請求項1から5のいずれか1項に記載のサービスメッシュシステム。
8. 第3のノードをさらに備え、前記第3のノードは第3のホストおよび第3のデータカードを備え、前記第3のデータカードは前記第3のホストに挿入され、前記第3のデータカードと前記第3のホストとの間に第3のデータチャネルが確立され、前記第3のホスト上で第4のポッドが動作し、前記第4のポッドに第4のマイクロサービスが提供され、前記第3のデータカードおよび前記第1のホストは前記ネットワークにアクセスし、
   第1のアプリケーションは前記第1のホスト上で動作し、
   前記第1のホストは、前記第3のデータカードのネットワークアドレスに対する前記第1のアプリケーションの第4のアクセス要求を取得し、前記ネットワークを使用することによって前記第4のアクセス要求を送信するように構成され、
   前記第3のデータカードは、前記第1のホストによって送信された前記第4のアクセス要求を受信し、前記第4のマイクロサービスのものである、前記第4のアクセス要求で搬送された識別子に基づいて、前記第3のデータチャネルを介して前記第4のマイクロサービスに前記第4のアクセス要求を送信するように構成されている、請求項1から5のいずれか一項に記載のサービスメッシュシステム。
9. 第3のノードをさらに備え、前記第3のノードは第3のホストを備え、第3のアプリケーションは前記第3のホスト上で動作し、前記第3のホストは前記ネットワークにアクセスし、
   前記第1のホストは、前記第3のアプリケーションのネットワークアドレスに対する前記第1のマイクロサービスの第5のアクセス要求を取得し、前記第1のデータチャネルを介して前記第1のデータカードに前記第5のアクセス要求を送信するように構成され、
   前記第1のデータカードは、前記ネットワークを使用することによって前記第5のアクセス要求を送信するように構成され、
   前記第3のホストは、前記第5のアクセス要求を受信し、前記第5のアクセス要求を前記第3のアプリケーションに送信するように構成されている、請求項1から5のいずれか一項に記載のサービスメッシュシステム。
10. マイクロサービスベースのサービスメッシュシステムに適用される、マイクロサービスベースのサービス指向アーキテクチャ管理方法であって、前記サービスメッシュシステムは第1のノードを備え、前記第1のノードは第1のホストおよび第1のデータカードを備え、前記第1のデータカードは前記第1のホストに挿入され、前記第1のデータカードと前記第1のホストとの間に第1のデータチャネルが確立され、前記第1のポッドは前記第1のホスト上で動作し、前記第1のポッドに第1のマイクロサービスが提供され、前記第1のデータカードはネットワークにアクセスし、
    前記方法は、
    前記ネットワークを使用することによって前記第1のデータカードによって、管理および制御ノードによって送信されたサービス指向アーキテクチャ管理ポリシーを受信するステップと、
    前記サービス指向アーキテクチャ管理ポリシーに基づいて前記第1のデータカードによって、前記第1のデータチャネルを介して前記第1のホストによって前記第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行するステップであって、前記第1のアクセス要求は、第2のマイクロサービスの前記第1のマイクロサービスのものであり、前記第1のポッドから前記第1のホストによって取得されたアクセス要求である、ステップとを含む、方法。
11. 前記サービス指向アーキテクチャ管理ポリシーは、前記第2のマイクロサービスと前記第2のマイクロサービスを実行する第2のポッドのネットワークアドレスとの間の対応関係を含み、
    前記サービス指向アーキテクチャ管理ポリシーに基づいて前記第1のデータカードによって、前記第1のデータチャネルを介して前記第1のホストによって前記第1のデータカードに送信された第1のアクセス要求に対してサービス指向アーキテクチャ管理を実行する前記ステップは、
    前記サービス指向アーキテクチャ管理ポリシーに基づいて前記第1のデータカードによって、前記第2のマイクロサービスを実行する前記第2のポッドの前記ネットワークアドレスを決定し、前記第1のアクセス要求の宛先アドレスを前記第2のポッドの前記ネットワークアドレスに設定するステップと、
    前記第1のデータカードによって、前記第2のポッドが前記第1のホスト上に配置されていると決定し、前記第1のデータチャネルを介して前記第2のポッドに修正された第1のアクセス要求を送信するステップとを含む、請求項10に記載の方法。
12. 前記サービス指向アーキテクチャ管理ポリシーは、第3のマイクロサービスと前記第3のマイクロサービスを実行する第3のポッドのネットワークアドレスとの間の対応関係をさらに含み、
    前記方法は、
    前記第1のホストによって、前記第1のポッドから、前記第3のマイクロサービスに対する前記第1のマイクロサービスの第2のアクセス要求を取得し、前記第2のアクセス要求を、前記第1のデータチャネルを介して前記第1のデータカードに送信するステップと、
    前記サービス指向アーキテクチャ管理ポリシーに基づいて前記第1のデータカードによって、前記第3のマイクロサービスを実行する前記第3のポッドの前記ネットワークアドレスを決定し、前記第2のアクセス要求の宛先アドレスを前記第3のポッドの前記ネットワークアドレスに設定するステップと、
    前記第1のデータカードによって、前記第3のポッドが前記第1のホスト上に配置されていないと決定し、前記ネットワークを使用することによって前記第2のアクセス要求を送信するステップとをさらに含む、請求項10に記載の方法。
13. 前記第1のノードは第1のネットワークインターフェースカードをさらに備え、前記第1のネットワークインターフェースカードは前記第1のデータカードに接続され、前記第1のデータカードは前記第1のネットワークインターフェースカードを使用することによって前記ネットワークにアクセスし、
    前記第1のデータカードによって、前記第3のポッドが前記第1のホスト上に配置されていないと決定し、前記ネットワークを使用することによって前記第2のアクセス要求を送信する前記ステップは、
    前記第1のデータカードによって、前記第3のポッドが前記第1のホスト上に配置されていないと決定し、前記第2のアクセス要求を前記第1のネットワークインターフェースカードに送信するステップと、
    前記第1のネットワークインターフェースカードによって、前記ネットワークを使用することによって前記第2のアクセス要求を送信するステップとを含む、請求項12に記載の方法。
14. 前記サービスメッシュシステムは、第2のノードをさらに備え、前記第2のノードは、第2のホストと、第2のデータカードと、第2のネットワークインターフェースカードとを備え、前記第2のデータカードは前記第2のホストに挿入され、前記第2のデータカードと前記第2のホストとの間に第2のデータチャネルが確立され、前記第3のポッドは前記第2のホスト上で動作し、前記第2のネットワークインターフェースカードは前記第2のデータカードに接続され、前記第2のネットワークインターフェースカードは前記ネットワークにアクセスし、
    前記方法は、
    前記第3のポッドが前記第1のホスト上に配置されていないと決定した場合に、前記第1のデータカードによって、前記第2のアクセス要求のサービスメッシュ識別子を設定するステップと、
    前記第2のネットワークインターフェースカードによって、前記第1のネットワークインターフェースカードによって送信された前記第2のアクセス要求を受信し、前記第2のアクセス要求が前記サービスメッシュ識別子を搬送していると決定した場合に、前記第2のデータカードに前記第2のアクセス要求を送信するステップと、
    前記第3のポッドが前記第2のホスト上に配置されていると決定した場合に、前記第2のデータカードによって、前記第2のデータチャネルを介して前記第3のポッドに前記第2のアクセス要求を送信するステップとをさらに含む、請求項13に記載の方法。
15. 前記サービスメッシュシステムは第3のノードをさらに備え、前記第3のノードは第3のホストを備え、前記第3のホストおよび前記第1のホストは前記ネットワークにアクセスし、第1のアプリケーションは前記第1のホスト上で動作し、第2のアプリケーションは前記第3のホスト上で動作し、
    前記方法は、
    前記第1のホストによって、前記第2のアプリケーションのネットワークアドレスに対する前記第1のアプリケーションの第3のアクセス要求を取得し、前記第2のアプリケーションが前記第1のホスト上で動作していないと決定した場合に、前記ネットワークを使用することによって前記第3のアクセス要求を送信するステップと、
    前記第3のホストによって、前記第1のホストによって送信された前記第3のアクセス要求を受信し、前記第3のアクセス要求を前記第2のアプリケーションに送信するステップとをさらに含む、請求項10から14のいずれか一項に記載の方法。
16. 第1のアプリケーションおよび第2のアプリケーションは前記第1のホスト上で動作し、
    前記方法は、
    前記第1のホストによって、前記第2のアプリケーションのネットワークアドレスに対する前記第1のアプリケーションの第3のアクセス要求を取得し、前記第2のアプリケーションが前記第1のホスト上で動作していると決定した場合に、前記第3のアクセス要求を前記第2のアプリケーションに送信するステップをさらに含む、請求項10から14のいずれか一項に記載の方法。
17. 前記サービスメッシュシステムは第3のノードをさらに備え、前記第3のノードは第3のホストおよび第3のデータカードを備え、前記第3のデータカードは前記第3のホストに挿入され、前記第3のデータカードと前記第3のホストとの間に第3のデータチャネルが確立され、前記第3のホスト上で第4のポッドが動作し、前記第4のポッドに第4のマイクロサービスが提供され、前記第3のデータカードおよび前記第1のホストは前記ネットワークにアクセスし、第1のアプリケーションは前記第1のホスト上で動作し、
    前記方法は、
    前記第1のホストによって、前記第3のデータカードのネットワークアドレスに対する前記第1のアプリケーションの第4のアクセス要求を取得し、前記ネットワークを使用することによって前記第4のアクセス要求を送信するステップと、
    前記第3のデータカードによって、前記第1のホストによって送信された前記第4のアクセス要求を受信し、前記第4のマイクロサービスのものである、前記第4のアクセス要求で搬送された識別子に基づいて、前記第3のデータチャネルを介して前記第4のマイクロサービスに前記第4のアクセス要求を送信するステップとをさらに含む、請求項10から14のいずれか一項に記載の方法。
18. 前記サービスメッシュシステムは第3のノードをさらに備え、前記第3のノードは第3のホストを備え、第3のアプリケーションは前記第3のホスト上で動作し、前記第3のホストは前記ネットワークにアクセスし、
    前記方法は、
    前記第1のホストによって、前記第3のアプリケーションのネットワークアドレスに対する前記第1のマイクロサービスの第5のアクセス要求を取得し、前記第1のデータチャネルを介して前記第1のデータカードに前記第5のアクセス要求を送信するステップと、
    前記第1のデータカードによって、前記ネットワークを使用することによって前記第5のアクセス要求を送信するステップと、
    前記第3のホストによって、前記第5のアクセス要求を受信し、前記第5のアクセス要求を前記第3のアプリケーションに送信するステップとをさらに含む、請求項10から14のいずれか一項に記載の方法。