Aufbau eines PHP-Microservice-Clusters – Hyperf

Microservice-Architektur

Das Konzept der Microservices wurde im März 2014 von Martin Fowler vorgeschlagen:

Microservice-Architektur ist ein Architekturmuster, das eine einzelne Anwendung unterteilt eine Reihe kleiner Dienste, und die Dienste koordinieren und kooperieren miteinander, um den Benutzern den ultimativen Mehrwert zu bieten. Jeder Dienst läuft in seinem eigenen unabhängigen Prozess und Dienste nutzen einfache Kommunikationsmechanismen, um miteinander zu kommunizieren. Jeder Dienst basiert auf einem bestimmten Unternehmen und kann unabhängig in Produktionsumgebungen, produktionsähnlichen Umgebungen usw. bereitgestellt werden. Darüber hinaus sollte ein einheitlicher und zentralisierter Service-Management-Mechanismus so weit wie möglich vermieden werden. Für einen bestimmten Service sollten geeignete Sprachen und Tools ausgewählt werden, um ihn basierend auf dem Geschäftskontext aufzubauen.

Die folgende Abbildung ist ein Microservice-Architekturdiagramm eines E-Commerce-Systems:

Microservice-Architektur bietet im Vergleich zu Einzelanwendungen folgende Vorteile:

1. Jeder Dienst ist relativ einfach und konzentriert sich nur auf eine Geschäftsfunktion.

2. Die Microservice-Architektur ist lose gekoppelt und jeder Dienst kann unabhängig getestet, bereitgestellt, aktualisiert und veröffentlicht werden >

3. Jeder Microservice kann unabhängig von verschiedenen Teams entwickelt werden und jedes kann die besten und am besten geeigneten Programmiersprachen und Tools auswählen.

4 Jeder Service kann je nach Bedarf angepasst werden Verbessern Sie die Parallelitätsfähigkeiten des Systems.

Es gibt kein Allheilmittel, obwohl die Microservice-Architektur viele Vorteile mit sich bringt:

1 kosten. Beispielsweise muss eine einzelne Anwendung möglicherweise nur in einem kleinen Anwendungsdienstcluster bereitgestellt werden, während eine Microservice-Architektur möglicherweise das Erstellen/Testen/Bereitstellen/Ausführen Dutzender unabhängiger Dienste erfordert und möglicherweise mehrere Sprachen und Umgebungen unterstützen muss 🎜>

2. Als verteiltes System bringt die Microservice-Architektur mehrere andere Probleme mit sich, wie z. B. Nachrichtenserialisierung, Netzwerkverzögerung, asynchrone Mechanismen, Fehlertoleranzverarbeitung, Service-Lawine usw.

3 Komplexität, wie Dienstregistrierung, Erkennung, Downgrade, Leistungsschalter usw.;

4. Es gibt gegenseitige Anrufe zwischen Diensten, die große Herausforderungen bei der Fehlerbehebung mit sich bringen.

Man kann sagen, dass gerade die Systeme mit traditioneller Anwendungsarchitektur zunehmend aufgebläht sind und Probleme haben, die schwer zu warten und zu erweitern sind. Gleichzeitig boomt die Entwicklung der Containerisierungstechnologie (Docker). und die zunehmende Reife von DevOps-Ideen haben zu einem neuen architektonischen Designstil geführt – der Entstehung der Microservices-Architektur.

RPC Framework

Jeder Dienst in einer Microservice-Architektur befindet sich normalerweise nicht auf demselben Computer oder sogar in derselben Netzwerkumgebung. Wie interagieren Microservices also miteinander? ?Aufrufe sind ein dringendes Problem, das gelöst werden muss:

RPC (Remote Procedure Call), also Remote Procedure Call, ist ein Computerkommunikationsprotokoll. Dieses Protokoll ermöglicht es einem Programm, das auf einem Computer läuft, ein Unterprogramm auf einem anderen Computer aufzurufen, ohne dass der Programmierer die Interaktion zusätzlich programmieren muss. ——Wikipedia

implementiert das RPC-Protokoll-Framework, das es dem Server und dem Anrufer ermöglicht, verschiedene zugrunde liegende Details abzuschirmen, sodass der Anrufer Remote-Funktionen (Dienste) genauso aufrufen kann wie lokale Funktionen. Das RPC-Framework bietet im Allgemeinen Serialisierung, Deserialisierung, Verbindungspoolverwaltung, Lastausgleich, Failover, Warteschlangenverwaltung, Timeout-Verwaltung, asynchrone Verwaltung und andere Funktionen für Server und Client. Ich habe im Internet ein Diagramm gefunden, das das Funktionsprinzip des RPC-Frameworks veranschaulicht:

Derzeit kann es je nach den verschiedenen Technologien, die zur Serialisierung von Daten verwendet werden, in zwei Typen unterteilt werden : JSON-RPC und gRPC:

1. JSON-RPC ist ein leichter RPC-Protokollstandard basierend auf dem JSON-Format, der basierend auf dem HTTP-Protokoll oder direkt basierend auf dem TCP-Protokoll übertragen werden kann. Der Vorteil von JSON-RPC besteht darin, dass es einfach zu verwenden und zu lesen ist.

2. gRPC ist ein leistungsstarkes, universelles Open-Source-RPC-Framework, das hauptsächlich für mobile Anwendungen entwickelt wurde und auf dem HTTP/2-Protokollstandard basiert (Protocol Buffers) Serialisierungsprotokoll und unterstützt viele Entwicklungssprachen. gRPC bietet die Vorteile geringer Latenz, hoher Effizienz, hoher Skalierbarkeit und Unterstützung für die Verteilung.

Consul

Jetzt können wir mit dem RPC-Framework nur die Geschäftsanrufe zwischen Diensten berücksichtigen, ohne die zugrunde liegenden Übertragungsdetails zu berücksichtigen. Wenn Dienst A zu diesem Zeitpunkt Dienst B anrufen möchte, können wir die IP-Adresse und den Port von Dienst B in Dienst A konfigurieren und dann die restlichen Übertragungsdetails dem RPC-Framework überlassen. Dies ist kein Problem, wenn der Umfang der Microservices klein ist, aber es wird vor großen Herausforderungen stehen, wenn der Umfang der Dienste groß ist und mehr als eine Instanz jedes Dienstes bereitgestellt wird. Für Dienst B sind beispielsweise drei Instanzen bereitgestellt. Wenn Dienst A Dienst B aufrufen möchte, welche Instanz-IP sollte er anfordern? Wenn zwei der drei von Dienst B bereitgestellten Instanzen ausgefallen sind, fordert Dienst A möglicherweise weiterhin die aufgehängten Instanzen an und der Dienst ist nicht verfügbar. Es ist sehr unflexibel, IP-Adressen und Ports in Konfigurationsdateien zu schreiben. Oft muss eine Microservice-Architektur eine hohe Verfügbarkeit und dynamische Skalierung gewährleisten.

Daher benötigen wir ein Dienstregistrierungs- und Diensterkennungstool, das Dienstinformationen dynamisch ändern und die IP-Adressen und Ports verfügbarer Dienste finden kann. Derzeit gibt es viele Service-Discovery-Tools auf dem Markt, wie Consul, ZooKeeper, Etcd, Doozerd usw. In diesem Artikel wird hauptsächlich die Consul-Software als Beispiel verwendet.

Consul ist eine Servicesoftware, die die verteilte Hochverfügbarkeitsdiensterkennung und Konfigurationsfreigabe in mehreren Rechenzentren unterstützt. Sie wurde von HashiCorp in der Go-Sprache entwickelt und ist Open Source und basiert auf der Mozilla Public License 2.0-Vereinbarung. Consul unterstützt Gesundheitsprüfungen und ermöglicht HTTP-, gRPC- und DNS-Protokollen den Aufruf von APIs zum Speichern von Schlüssel-Wert-Paaren.

Das Folgende ist das Architekturdiagramm nach der Einführung von Dienstregistrierungs- und Diensterkennungstools:

In dieser Architektur:

Erste Instanz von S-B Registrieren Sie nach dem Start die eigenen Dienstinformationen (hauptsächlich die IP-Adresse und die Portnummer des Dienstes) in Consul.

Consul führt Gesundheitsprüfungen für alle registrierten Dienste durch, um festzustellen, welche Dienstinstanzen verfügbar sind und welche nicht.

Nachdem S-A gestartet ist, kann es durch Zugriff auf Consul die IPs und Ports aller fehlerfreien S-B-Instanzen abrufen und diese Informationen in seinem eigenen Speicher ablegen. S-A kann diese Informationen verwenden, um S-B aufzurufen.

S-A kann die im Speicher gespeicherten Serviceinformationen von S-B aktualisieren, indem es auf Consul hört. Wenn S-B-1 beispielsweise auflegt, markiert der Gesundheitsprüfungsmechanismus ihn als nicht verfügbar. Solche Informationsänderungen werden von S-A überwacht und S-A aktualisiert die Dienstinformationen von S-B-1 in seinem eigenen Speicher.

Es ist ersichtlich, dass die Consul-Software zusätzlich zu den Funktionen der Dienstregistrierung und Diensterkennung auch Funktionen zur Gesundheitsprüfung und Benachrichtigung über Statusänderungen bietet.

Hyperf

Für Java-Entwickler stehen recht ausgereifte Dubbo- und Spring Cloud-Microservice-Frameworks zur Auswahl. Als PHPer habe ich Google verwendet, um „PHP + Microservices“ zu überprüfen, und festgestellt, dass es sehr wenig nützlichen verwandten Inhalt und keinen wesentlichen Referenzwert gab, und ich war unendlich enttäuscht. . . Glücklicherweise haben einige Experten das leistungsstarke und hochflexible PHP-Coroutine-Framework Hyperf basierend auf der Swoole-Erweiterung implementiert und zugehörige Komponenten der Microservice-Architektur bereitgestellt.

Hyperf ist ein leistungsstarkes, hochflexibles PHP-Coroutine-Framework, das auf Swoole 4.3+ basiert. Es verfügt über einen integrierten Coroutine-Server und eine große Anzahl häufig verwendeter Komponenten. Seine Leistung ist im Vergleich zum herkömmlichen Framework qualitativ verbessert Das auf PHP-FPM basierende Framework bietet gleichzeitig eine äußerst flexible Skalierbarkeit. Basierend auf einem leistungsstarken Dependency-Injection-Design stellt es sicher, dass die meisten Komponenten oder Klassen austauschbar und wiederverwendbar sind .

Nachdem ich mir die Grundkenntnisse der Microservice-Architektur angeeignet hatte, nutzte ich das Hyperf-Framework, um einen PHP-basierten Microservice-Cluster zu erstellen. Dies ist die Quellcode-Adresse des Projekts: https://github.com/Jochen- z/p…. Das Projekt wird mit Dokcer erstellt. Der docker-compose.yml-Code lautet wie folgt:

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

Ein Consul-Container „Consul-Server-Leader“ wird hier als Komponente der Dienstregistrierung und Diensterkennung gestartet. 1 und Microservice-2 stellen jeweils Additions- und Divisionsoperationen bereit. Als Dienstaufrufer konfiguriert die Container-App die URL des Containers „Consul-Server-Leader“, ruft die IP-Adressen und Ports der Dienste „Microservice-1“ und „Microservice-2“ ab, indem sie auf „Consul-Server-Leader“ zugreift, und ruft dann die App „Addition“ auf und Division über das RPC-Protokoll. Der Computerdienst erhält die Ergebnisse und gibt sie an den Benutzer zurück.

Der App-Container ist eine Webanwendung, die ein Hyperf-Projekt bereitstellt und HTTP-Dienste für die Außenwelt bereitstellt. Beispielsweise gibt es im AppControllerIndexController-Controller eine Add-Methode:

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调用
  ];
}

Die Implementierung von Add in AppJsonRpcAdditionService:

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'));
    }
}

Erbt AbstractServiceClient, um eine Microservice-Client-Anforderungsklasse zu erstellen, und Hyperf hilft unten Wir haben die Details der Interaktion mit Consul und Dienstanbietern implementiert. Wir benötigen nur die Add-Methode in der AdditionService-Klasse, um die von Microservice-1 und Microservice-2 bereitgestellten Dienste remote aufzurufen.

An diesem Punkt ist der Aufbau des PHP-Microservice-Clusters abgeschlossen!

Das obige ist der detaillierte Inhalt vonAufbau eines PHP-Microservice-Clusters – Hyperf. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!