PHP マイクロサービス クラスターの構築 - Hyperf

マイクロサービス アーキテクチャ

マイクロサービスの概念は、2014 年 3 月に Martin Fowler によって提案されました。

マイクロサービス アーキテクチャは、単一のアプリケーションが次のように分割されることを提唱するアーキテクチャ パターンです。小さなサービスの集合体であり、サービスが相互に調整・連携してユーザーに最終的な価値を提供します。各サービスは独自の独立したプロセスで実行され、サービスは軽量の通信メカニズムを使用して相互に通信します。各サービスは特定のビジネスを中心に構築されており、実稼働環境や実稼働に類似した環境などに個別にデプロイできます。また、統一的かつ集中的なサービス管理メカニズムは可能な限り避けるべきであり、特定のサービスについては、ビジネスのコンテキストに基づいて適切な言語とツールを選択して構築する必要があります。

次の図は、電子商取引システムのマイクロサービス アーキテクチャ図です。

マイクロサービス アーキテクチャには、単一のアプリケーションと比較して次の利点があります。

1. 各サービスは比較的シンプルで、1 つのビジネス機能のみに焦点を当てています;

2. マイクロサービス アーキテクチャは疎結合であり、各サービスは独立してテスト、デプロイ、アップグレード、リリースできます;

3. 各マイクロサービスは異なるチームによって独立して開発でき、それぞれが最適かつ最適なプログラミング言語とツールを選択できます;

4. 各サービスはニーズに応じてレベル分けできますシステムの同時実行機能を向上させます。

特効薬はありません。マイクロサービス アーキテクチャには多くの利点がありますが、次のような欠点もあります:

1. マイクロサービス アーキテクチャにより、システムの複雑さが増し、運用とメンテナンスが増加します。諸経費とコスト。たとえば、単一のアプリケーションは小規模なアプリケーション サービス クラスターにデプロイするだけで済む場合がありますが、マイクロサービス アーキテクチャでは数十の独立したサービスの構築/テスト/デプロイ/実行が必要な場合があり、複数の言語と環境をサポートする必要がある場合があります。

##2. 分散システムとして、マイクロサービス アーキテクチャでは、メッセージのシリアル化、ネットワーク遅延、非同期メカニズム、フォールト トレランス処理、サービス アバランシェなど、他のいくつかの問題が発生します。

3. サービス管理の複雑さ（サービスの登録、検出、ダウングレード、サーキット ブレーカー、その他の問題など）;

4. サービス間には相互呼び出しがあり、システム障害のトラブルシューティングに大きな課題をもたらします。

まさに従来のアプリケーションアーキテクチャの仕組みが肥大化し、維持・拡張が難しいという課題を抱えていたと言えますが、同時にコンテナ化技術（Docker）の開発も盛んになりました。そして、DevOps のアイデアが成熟するにつれて、新しいアーキテクチャ設計スタイル、つまりマイクロサービス アーキテクチャの出現が生まれました。

RPC フレームワーク

マイクロサービス アーキテクチャ内のさまざまなサービスは通常、同じマシン上になく、同じネットワーク環境にさえ存在しません。そのため、マイクロサービスはどのように相互作用するのでしょうか。通話は解決する必要がある緊急の問題です。私たちは通常、RPC プロトコルを使用してそれを解決します:

RPC (Remote Procedure Call)、つまりリモート プロシージャ コールは、コンピュータ通信プロトコルです。このプロトコルを使用すると、プログラマが対話を追加でプログラムすることなく、あるコンピュータ上で実行されているプログラムが別のコンピュータ上のサブルーチンを呼び出すことができます。 ——Wikipedia

は、RPC プロトコルのフレームワークを実装しています。これにより、サーバーと呼び出し元がさまざまな基礎となる詳細をシールドできるようになり、呼び出し元はローカル関数を呼び出すのと同じようにリモート関数 (サービス) を呼び出すことができます。 RPC フレームワークは通常、シリアル化、逆シリアル化、接続プール管理、ロード バランシング、フェイルオーバー、キュー管理、タイムアウト管理、非同期管理、およびサーバーとクライアントのその他の機能を提供します。 RPC フレームワークの動作原理を示す図をインターネットで見つけました。

#現在、データのシリアル化に使用されるさまざまなテクノロジに応じて、2 つに分類できます。タイプ: JSON-RPC および gRPC:

1. JSON-RPC は、JSON 形式に基づく軽量の RPC プロトコル標準であり、HTTP プロトコルに基づいて、または TCP プロトコルに直接基づいて送信できます。 JSON-RPC の利点は、使いやすく、読みやすいことです。

2. gRPC は、高性能の汎用オープンソース RPC フレームワークです。主にモバイル アプリケーション開発のために Google によって設計され、HTTP/2 プロトコル標準に基づいています。ProtoBuf に基づいて開発されています。 (プロトコル バッファ) シリアル化プロトコル、および多くの開発言語をサポートします。 gRPC には、低遅延、高効率、高スケーラビリティ、および分散のサポートという利点があります。

Consul

RPC フレームワークを使用すると、基礎となる送信の詳細を考慮せずに、サービス間のビジネス呼び出しのみを考慮できるようになります。この時点で、サービス A がサービス B を呼び出したい場合は、サービス A でサービス B の IP アドレスとポートを構成し、残りの送信の詳細を RPC フレームワークに任せることができます。マイクロサービスの規模が小さい場合にはこれは問題ありませんが、サービスの規模が大きくなり、各サービスのインスタンスが複数デプロイされる場合には、大きな課題に直面することになります。たとえば、サービス B には 3 つのインスタンスがデプロイされています。このとき、サービス A はサービス B を呼び出したいと考えています。どのインスタンス IP を要求する必要がありますか?サービス B によってデプロイされた 3 つのインスタンスのうち 2 つがダウンした場合でも、サービス A はハングアップしたインスタンスを要求する可能性があり、サービスは使用できなくなります。 IP アドレスとポートを構成ファイルに書き込むのは非常に柔軟性が低いため、マイクロサービス アーキテクチャでは多くの場合、高可用性と動的なスケーリングを確保する必要があります。

したがって、サービス情報を動的に変更し、利用可能なサービスの IP アドレスとポートを見つけることができるサービス登録およびサービス検出ツールが必要です。現在、市場には、Consul、ZooKeeper、Etcd、Doozerd など、多くのサービス検出ツールが存在します。この記事では、主に Consul ソフトウェアを例として取り上げます。

Consul は、マルチデータセンター、分散型高可用性サービス検出および構成共有をサポートするサービス ソフトウェアであり、HashiCorp によって Go 言語で開発され、Mozilla Public License 2.0 契約に基づいたオープン ソースです。 Consul はヘルス チェックをサポートし、HTTP、gRPC、および DNS プロトコルが API を呼び出してキーと値のペアを保存できるようにします。

以下は、サービス登録およびサービス検出ツールの導入後のアーキテクチャ図です。

このアーキテクチャでは:

最初に、 S-Bのインスタンス 起動後、Consulに自身のサービス情報(主にサービスのIPアドレスとポート番号)を登録します。

Consul は、登録されているすべてのサービスに対してヘルス チェックを実行し、どのサービス インスタンスが利用可能でどのサービス インスタンスが利用できないかを判断します。

S-A の開始後、Consul にアクセスすることで、すべての正常な S-B インスタンスの IP とポートを取得し、この情報を独自のメモリに保存できます。S-A は、この情報を使用して S-B を呼び出すことができます。

S-A は、Consul の話を聞くことで、メモリに保存されている S-B のサービス情報を更新できます。たとえば、S-B-1 が電話を切ると、ヘルス チェック メカニズムによって利用不可としてマークされ、そのような情報の変化は S-A によって監視され、S-A は自身のメモリ内の S-B-1 のサービス情報を更新します。

Consul ソフトウェアは、サービス登録とサービス検出の機能に加えて、ヘルス チェックとステータス変更通知機能も提供していることがわかります。

Hyperf

Java 開発者にとって、非常に成熟した Dubbo および Spring Cloud マイクロサービス フレームワークから選択できます。 PHPer として、Google を使って「PHP マイクロサービス」を調べたところ、有用な関連コンテンツがほとんどなく、実質的な参考値がないことがわかり、限りなく失望しました。 。 。幸いなことに、一部の専門家は、Swoole 拡張機能に基づいた高性能で柔軟性の高い PHP コルーチン フレームワーク Hyperf を実装し、マイクロサービス アーキテクチャの関連コンポーネントを提供しています。

Hyperf は、Swoole 4.3 をベースとした高性能かつ柔軟性の高い PHP コルーチン フレームワークです。組み込みのコルーチン サーバーと、一般的に使用されるコンポーネントが多数含まれています。従来のフレームワークと比較して、パフォーマンスが質的に向上しています。 PHP-FPM に基づいており、超高性能を維持しながら、非常に柔軟なスケーラビリティも維持します。標準コンポーネントは PSR 標準に基づいて実装され、強力な依存関係注入設計に基づいており、ほとんどのコンポーネントまたはクラスが交換可能で再利用可能。

そこで、マイクロサービス アーキテクチャに関する基本的な知識を学んだ後、Hyperf フレームワークを使用して PHP ベースのマイクロサービス クラスターを構築しました。プロジェクトのソース コードのアドレスは次のとおりです: https://github.com/Jochen- Z P…。プロジェクトは Dokcer を使用して構築されます。docker-compose.yml コードは次のとおりです:

version: "3"
services:
  consul-server-leader:
    image: consul:latest
    container_name: consul-server-leader
    command: "agent -server -bootstrap -ui -node=consul-server-leader -client=0.0.0.0"
    environment:
      - CONSUL_BIND_INTERFACE=eth0
    ports:
      - "8500:8500"
    networks:
      - microservice
  microservice-1:
    build:
      context: .
    container_name: "microservice-1"
    command: "php bin/hyperf.php start"
    depends_on:
      - "consul-server-leader"
    volumes:
      - ./www/microservice-1:/var/www
    networks:
      - microservice
    tty: true
  microservice-2:
    build:
      context: .
    container_name: "microservice-2"
    command: "php bin/hyperf.php start"
    depends_on:
      - "consul-server-leader"
    volumes:
      - ./www/microservice-2:/var/www
    networks:
      - microservice
    tty: true
  app:
    build:
      context: .
    container_name: "app"
    command: "php bin/hyperf.php start"
    depends_on:
      - "microservice-1"
    volumes:
      - ./www/web:/var/www
    ports:
      - "9501:9501"
    networks:
      - microservice
    tty: true
networks:
  microservice:
    driver: bridge
volumes:
  microservice:
    driver: local

ここでは、Consul コンテナ consul-server-leader がサービス登録とサービス検出のコンポーネントとして開始されます。 1 と microservice-2 はそれぞれ加算演算と除算演算を提供します。サービス呼び出し元として、コンテナー アプリは consul-server-leader コンテナーの URL を構成し、consul-server-leader にアクセスして microservice-1 サービスと microservice-2 サービスの IP アドレスとポートを取得し、アプリは追加を呼び出します。コンピューティング サービスは結果を取得してユーザーに返します。

アプリ コンテナーは、Hyperf プロジェクトをデプロイし、外部に HTTP サービスを提供する Web アプリケーションです。たとえば、App\Controller\IndexController コントローラーには add メソッドがあります:

public function add(AdditionService $addition)
{
  $a = (int)$this->request->input('a', 1); # 接受前端用户参数
  $b = (int)$this->request->input('b', 2);
  return [
    'a' => $a,
    'b' => $b,
    'add' => $addition->add($a, $b) # RPC调用
  ];
}

App\JsonRpc\AdditionService での add の実装:

class AdditionService extends AbstractServiceClient
{
    /**
     * 定义对应服务提供者的服务名称
     * @var string
     */
    protected $serviceName = 'AdditionService';
    /**
     * 定义对应服务提供者的服务协议
     * @var string
     */
    protected $protocol = 'jsonrpc-http';
    public function add(int $a, int $b): int
    {
        return $this->__request(__FUNCTION__, compact('a', 'b'));
    }
}

Inherits AbstractServiceClient を継承してマイクロサービス クライアントを作成します。 request クラス, Hyperf は、Consul および最下位レベルのサービス プロバイダーとの対話の詳細を実装するのに役立ちます。microservice-1 および microservice-2 によって提供されるサービスをリモートで呼び出すために必要なのは、AdditionService クラスの add メソッドだけです。

これで、PHP マイクロサービス クラスターの構築が完了しました。

以上がPHP マイクロサービス クラスターの構築 - Hyperfの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。