マイクロサービス システムにおけるサービス間の通信方法

1. 同期通信

同期通信には、あるサービスが別のサービスにリクエストを送信し、応答を受信するまでその動作を一時停止するというリアルタイムの対話が含まれます。 REST API と gRPC は、この種の通信を促進するために使用される一般的なプロトコルです。

1.1 RESTful API

RESTful API (Representational State Transfer) は、マイクロサービス システムでサービスが相互に通信するための最も一般的な方法の 1 つです。 REST は、データ交換に HTTP/HTTPS および JSON または XML 形式を利用します。

通常、サービスは別のサービスの API を直接呼び出すことによって相互に通信します。

リクエストとレスポンスの例:

GET /users/12345 HTTP/1.1
Host: api.userservice.com
Accept: application/json
Authorization: Bearer your-access-token

{
  "userId": "12345",
  "name": "Michel J",
  "email": "MJ@example.com",
  "address": "Mountain View, Santa Clara, California"
}

ソースコードの例

import org.springframework.web.client.RestTemplate;
import org.springframework.http.ResponseEntity;

public class OrderService {

    private final RestTemplate restTemplate = new RestTemplate();
    private final String userServiceUrl = "https://api.userservice.com/users/";

    public User getUserById(String userId) {
        String url = userServiceUrl + userId;
        ResponseEntity<User> response = restTemplate.getForEntity(url, User.class);
        return response.getBody();
    }
}

利点:

導入やさまざまな言語やツールとの統合が簡単です。

テストおよび監視ツールを簡単に使用できます。

欠点:

同期的な性質のため、高速要件には効率的ではない可能性があります。

ネットワークエラーや切断の処理が困難になる場合があります。

1.2 gRPC

gRPC は、Google Remote Procedure Call の略で、高性能のオープンソースのユニバーサル RPC フレームワークです。効率的なデータ転送のために HTTP/2 を利用し、通常はプロトコル バッファー (言語に依存せず、プラットフォームに依存せず、構造化データをシリアル化するための拡張可能なメカニズム) に依存して、送受信されるデータの構造を定義します。

例、プロトコルバッファの定義

syntax = "proto3";

package userservice;

// Define message User
message User {
    string userId = 1;
    string name = 2;
    string email = 3;
    string address = 4;
}

// Define service UserService
service UserService {
    rpc GetUserById (UserIdRequest) returns (User);
}

// Define message UserIdRequest
message UserIdRequest {
    string userId = 1;
}

ユーザー管理サービスの場合は、.proto ファイルで提供されるサービス定義に準拠する gRPC サーバーを実装する必要があります。これには、受信した gRPC リクエストを処理し、適切な応答を生成するために必要なサーバー側ロジックの作成が含まれます。

import io.grpc.stub.StreamObserver;
import userservice.User;
import userservice.UserIdRequest;
import userservice.UserServiceGrpc;

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {

    @Override
    public void getUserById(UserIdRequest request, StreamObserver<User> responseObserver) {
        // Assuming you have a database to retrieve user information.
        User user = User.newBuilder()
                .setUserId(request.getUserId())
                .setName("Michel J")
                .setEmail("MJ@example.com")
                .setAddress("Mountain View, Santa Clara, California")
                .build();

        responseObserver.onNext(user);
        responseObserver.onCompleted();
    }
}

import io.grpc.Server;
import io.grpc.ServerBuilder;

public class UserServer {
    public static void main(String[] args) throws Exception {
        Server server = ServerBuilder.forPort(9090)
                .addService(new UserServiceImpl())
                .build()
                .start();

        System.out.println("Server started on port 9090");
        server.awaitTermination();
    }
}

利点:

HTTP/2 およびプロトコル バッファーの使用による高いパフォーマンスと帯域幅効率。

複数のプログラミング言語をサポートし、優れた拡張性を備えています。

欠点:

サービスが gRPC をサポートしていない場合は、変換レイヤーが必要です。

導入と管理がより複雑になる可能性があります。

2. 非同期通信

非同期通信とは、サービスが応答を待つために自身の操作をブロックせずに、別のサービスにリクエストを送信するプロセスを指します。これは通常、メッセージ キューまたはパブリッシュ/サブスクライブ システムを通じて実現されます。

1. メッセージキュー

RabbitMQ や Apache ActiveMQ などのメッセージ キュー システムは、サービス間の非同期通信を容易にします。

利点:

スケーラビリティと耐障害性の向上: システムは増加したワークロードをより適切に処理できるようになり、障害の影響を受けにくくなります。

サービスの負荷の軽減: リクエストの送信と受信を分離することで、メインのサービスは絶え間ないリクエストに圧倒されることなくタスクの処理に集中できます。

欠点:

管理と保守に追加の労力が必要になる場合があります: キューベースのシステムはより複雑になる可能性があり、動作するためにより多くのリソースが必要になります。

順序付けの処理とメッセージ配信の確保の難しさ: リクエストが正しい順序で処理され、メッセージが失われないようにすることは、技術的な課題となる可能性があります。

2.2.パブリッシュ/サブシステム

Apache Kafka や Google Pub/Sub などの Pub/Sub (パブリッシュ/サブスクライブ) システムを使用すると、サービスがメッセージをパブリッシュし、トピックをサブスクライブできます。

利点:

大規模で高スループットのデータ ストリームをサポートします。

サービス間の依存関係を軽減します。

欠点:

トピックとメッセージを管理および監視するには、より複雑なレイヤーが必要です。

メッセージの順序と信頼性の問題を処理するのは難しい場合があります。」

ご興味がございましたら、Pub/Sub トピックに関する私の以前の記事をご覧ください。

メッセージ ブローカーのデッド レター キュー パート 1

メッセージ ブローカーのデッド レター キュー パート 2

メッセージ ブローカー システム内の一貫性と信頼性に関する懸念

3. イベント駆動型コミュニケーション

イベント駆動型の通信とは、サービスがイベントを発行し、他のサービスがそれらのイベントに基づいて応答またはアクションを実行することです。

3.1.同期イベント

同期イベントは、サービスがイベントを発行し、他のサービスからの応答を待機するときに発生します。

利点:

イベント処理プロセスの制御と監視が簡単です。

短所:

サービスの応答が遅い場合やエラーが発生した場合、ボトルネックが発生する可能性があります

3.2.非同期イベント

非同期イベントは、サービスがイベントを発行し、即時の応答を待つ必要がない場合に発生します。

利点:

待ち時間を短縮し、スケーラビリティを向上させます。

サービスがより独立して動作し、相互依存関係を軽減できるようにします。

短所:

イベントが正確かつタイムリーに処理されるようにするには、追加のメカニズムが必要です。

順序を確保し、重複したイベントを処理することが困難。

4. 結論

マイクロサービス システム内のサービス間の通信方法の選択は、パフォーマンス要件、信頼性、システムの複雑さなどの要因によって異なります。各方法には独自の長所と短所があり、これらの方法を理解することで、より効率的で柔軟なマイクロサービス システムを構築することができます。システムの要件を慎重に検討して、最適な通信方法を選択してください。

以上がマイクロサービス システムにおけるサービス間の通信方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。