*Autor: Chen Youwei, Momo R&D Engineer, Apache Dubbo PMC
Microservices für die RPC-Protokollentwicklung
Wenn wir normalerweise Microservices entwickeln, stehen herkömmliche RPC-Services möglicherweise ganz unten. Die obere Schicht kann Browser, mobile Endgeräte, externe Server, eigene Tests, Curl usw. sein. Wir können einen externen Server wie Tomcat verwenden, um unsere RPC-Schicht, die BFF, zusammenzustellen. Oder wir haben keine BFF und unser RPC soll Dienste für die Außenwelt bereitstellen. Da der Browser jedoch Zugriff benötigt, benötigen wir ein Gateway wie APISIX oder ShenYu und andere HTTP-Gateways.
Das Bild oben zeigt unseren Prozess, es gibt jedoch einige Probleme.
Wenn unser Dienst sehr einfach ist und wir nur eine Weiterleitungsschicht benötigen, wird es schwierig sein, ein Gateway zu konfigurieren oder einen Webserver für die Weiterleitung einzurichten.
Darüber hinaus basieren die meisten RPC-Dienste auf Binärdateien, und Binärdateien können nicht lokal getestet werden. Daher entwickelt unser Unternehmen möglicherweise ein Backend oder einen Zwischen-Proxy, den wir testen können. Voraussetzung hierfür ist jedoch, dass Sie es zumindest in der Testumgebung bereitstellen müssen, sodass Sie es noch nicht lokal testen können.
Im Allgemeinen führen diese beiden Probleme zu einer relativ geringen Benutzerfreundlichkeit und relativ hohen Entwicklungskosten, da einige sich wiederholende Arbeiten erledigt werden müssen, die nichts mit dem Geschäft zu tun haben.
Neu aktualisiertes Triple-Protokoll
Basierend auf den beiden oben genannten Fragen stellen wir das Triple-Protokoll vor.
Lassen Sie uns zunächst über das Protokoll der vorherigen Generation und die Gründe für seine Produktion sprechen. Wir sollten alle wissen, dass Dubbo ursprünglich das Dubbo-Protokoll ist, das auf TCP basiert und nur ein Paket hat. Aufgrund des Designs seines Pakets kann das Gateway einige spezielle Regelbeurteilungen, Filterungen und andere Vorgänge nicht durchführen. Aber es ist nicht absolut. Wenn Sie bereit sind, Leistung zu opfern, um das Paket vollständig auszupacken, es wieder zusammenzubauen und es dann weiterzureichen, können Sie es immer noch tun, aber im Allgemeinen ist es nicht für jeden akzeptabel.
Wir fragten uns also, ob wir die Originaldaten vom echten Paket trennen könnten. Jetzt verfügen wir über fertiges HTTP und gRPC, einen Mainstream-Industriestandard, daher ist es unser Ziel, mit gRPC kompatibel zu sein. Da gRPC derzeit IDL verwendet, gibt es bei IDL ein Problem, insbesondere auf der Java-Seite. Da jeder einige Schnittstellen schreibt und einige Pakete definiert, um sie zu implementieren, wird dies sehr problematisch sein. Auf der Go-Seite ist es in Ordnung, da jeder bereits an dieses Entwicklungsmodell gewöhnt ist.
Deshalb haben wir das Triple-Protokoll entwickelt. Erstens ist es mit gRPC kompatibel, sodass wir eine vollständige Interoperabilität mit gRPC erreichen können. Zweitens sind wir mit den Methoden zur Definition von Schnittstellen selbst kompatibel. Obwohl ein Teil der Leistung verloren geht, wird die Benutzerfreundlichkeit etwas verbessert. Darüber hinaus stellt RPC im Allgemeinen nicht den Engpass des Geschäfts dar. Die meisten Engpässe liegen immer noch in der DB.
Aber es gibt immer noch ein Problem: Obwohl wir mit gRPC kompatibel sind, basiert gRPC auf TPC. Wenn das Frontend oder ein anderes System eines Drittanbieters also nur HTTP hat, kann es unser System immer noch nicht akzeptieren.
Auf dieser Grundlage wollen wir ein neues Triple-Protokoll einführen. Um alle oben genannten Probleme zu lösen, beziehen wir uns auf gRPC, gRPC Web, allgemeines HTTP und andere Protokolle, um Browserzugriff zu erreichen, Streaming zu unterstützen und die gleichzeitige Ausführung der Protokolle HTTP/1 und HTTP/2 zu unterstützen. Da HTTP/3 noch nicht in großem Umfang gefördert wurde, wird HTTP/3 in Zukunft unterstützt.
Die endgültige Designimplementierung basiert vollständig auf HTTP und ist benutzerfreundlich, entwicklungs- und debuggingfreundlich. Wir können über einen einfachen Browser oder Curl darauf zugreifen, insbesondere für unäres RPC. Darüber hinaus sind wir vollständig mit gRPC kompatibel. Unternehmen, die HTTP verwenden, müssen sich keine Gedanken über Kompatibilitätsprobleme oder die Unterzeichnung von Vereinbarungen machen. Aus Stabilitätsgründen werden wir nur in der Branche beliebte Netzwerkbibliotheken verwenden, z. B. das native Net-Paket von Java und das grundlegende Net-Paket von Go.
Obwohl sowohl das Triple-Protokoll als auch das gRPC-Protokoll auf HTTP basieren, basiert gRPC auf HTTP/2, während Triple auf HTTP/1 und HTTP/2 basiert.
Obwohl wir mit gRPC kompatibel sind, haben wir für eine einfachere Nutzung auch einige Funktionen erweitert. In der Anfrage unterstützen wir beispielsweise das Application/Json-Anfrageformat und den Curl-Zugriff;
Darüber hinaus hatten wir in der vorherigen Version des Protokolls einen sekundären Serialisierungsprozess, um die traditionelle Art der Schnittstellendefinition zu unterstützen. Wir möchten einen speziellen Inhaltstyp verwenden, um die Struktur unseres Körpers zu bestimmen und das Problem der sekundären Serialisierung zu lösen. Gleichzeitig ist dieses Ding erweiterbar. Theoretisch können alle Funktionen von HTTP auf dem Triple-Protokoll implementiert und auch erweitert werden.
Nach der Verwendung des Triple-Protokolls hat sich auch unser Entwicklungsprozess geändert. Wenn Sie keinen externen Proxy benötigen oder keinen externen Proxy haben, kann Ihr Zugriffsprozess über einen externen Anforderungsbrowser, den Server der anderen Partei, Curl, Ihre eigenen Tests usw. direkt auf den Server erfolgen.
Bei der Kommunikation mit anderen gRPCs gibt es kein Problem, und der Vorgang ist gleichbedeutend mit dem Fehlen einer Ebene. Wenn Sie dieses Szenario nicht benötigen, bietet es für die meisten Benutzer tatsächlich große Vorteile.
Da das Triple-Protokoll ursprünglich mit gRPC kompatibel war, basierte es zu diesem Zeitpunkt nur auf HTTP/2. HTTP/2 verfügt über Streaming-Funktionen und unterstützt daher selbstverständlich Streaming. Das Besondere hierbei ist jedoch, dass unsere neue Version des Protokolls auch Stream in HTTP/1 unterstützt, aufgrund der Einschränkungen von HTTP/1 jedoch nur Server-Streaming unterstützen kann. Verlässt sich auf die Server Push-Implementierung von HTTP/1.
Zu Client Stream und Bi Stream gibt es nicht viel zu sagen. Eine Besonderheit ist jedoch, dass es auf der Java-Seite keinen Bi Stream gibt. Es existiert nicht in Bezug auf die Codierung, wohl aber in Bezug auf die Implementierung.
Microservices für die Entwicklung von Dreifachprotokollen
Derzeit unterstützt das Triple-Protokoll flexibel zwei Definitionsmethoden, nämlich IDL-Definition und direkte Definition. Die direkte Definition unterstützt synchrones, asynchrones und handschriftliches Schreiben. Es gibt auch extremere Methoden, wie zum Beispiel die Verwendung von IDL zum Generieren von Protobuf-Klassen bei der Definition der Schnittstelle. Wir definieren ihren Dienst nicht. Es ist kein Problem, nur die generierten Anforderungs- und Antwortklassen zu verwenden. Das Triple-Protokoll identifiziert automatisch die Schnittstellennutzung .protobuf oder Protobuf nicht für die Übertragung verwenden.
Der Server soll seine Aufgaben umsetzen. Das Bild oben ist ein Beispiel. Ich habe direkt die API-Assembly-Methode verwendet. Im echten Geschäft kann es sich um Anmerkungen oder XML handeln.
Da wir das Standardprotokoll HTTP unterstützen, werden unsere Tests theoretisch sehr einfach.
Da wir gRPC unterstützen, können wir unseren Dienst mit gRPC-Curl aufrufen. Voraussetzung ist jedoch, dass Sie über den Reflection-Dienst verfügen und ihn dann manuell aktivieren müssen. Er ist nicht standardmäßig aktiviert. Anschließend kann es die Quelldaten der Schnittstelle durch Reflektion abrufen, über Json in das Protobuf-Format konvertieren und senden. Oder wir können es direkt mit Application/Json übertragen. Das Besondere hierbei ist, dass wir Sreaming auch unter HTTP/1 nutzen können.
Da wir außerdem HTTP unterstützen, können theoretisch alle HTTP-Clients von Drittanbietern aufgerufen werden. Dann können Sie Dubbo's Admin auch zum Testen nutzen, sofern Sie es registrieren.
Unabhängig davon, ob die anrufende Seite POJO oder IDL ist, gibt es keinen wesentlichen Unterschied zwischen ihnen.
Jetzt haben wir das Triple-Protokoll, aber dieses Protokoll wird ohne Träger nicht funktionieren. Daher müssen wir über ein Framework und eine gewisse Service-Governance verfügen, die unsere Microservices sind. Daher ist Service Governance auch ein integraler Bestandteil von Microservices.
Dubbo erweitert das Triple-Protokoll um Governance-Funktionen
Triple ist nur eines der Protokolle in Dubbo. Natürlich können Sie aus Kompatibilitätsgründen auch das ursprüngliche Dubbo-Protokoll oder andere Protokolle verwenden. Und wir unterstützen das Öffnen mehrerer Protokolle am selben Port, die je nach Bedarf ausgewählt werden können.
Gleichzeitig bietet Dubbo eine mehrsprachige Implementierung für Triple. Derzeit wird die offizielle Implementierung in Rust, Go, Java, JS, Node und Python implementiert. Auf diese Weise müssen Benutzer es nicht gemäß den Spezifikationen des Versuchsprotokolls implementieren. Wenn Sie Anpassungsanforderungen haben, z. B. einige interne Frameworks, können Sie diese gemäß der Spezifikation implementieren.
Dubbo ist gut in das Service-Framework integriert. Theoretisch müssen sich Kunden im Entwicklungsprozess, insbesondere auf der Java-Seite, nicht um Servicedefinition, Service-Governance, Service-Registrierungserkennung usw. kümmern und können diese auch außerhalb verwenden die Kiste .
Dubbo bietet ein reichhaltiges Ökosystem. Das Ökosystem von Drittanbietern umfasst Nacos, Zookeeper usw. Wir müssen nicht innovieren, wir können die entsprechenden Pakete direkt einführen.
Dies ist ein Beispiel für unsere Verwendung der Triple Protocol-Dienstregistrierung. Oben können Sie Nacos, Zookeeper und K8s auswählen. Auf der linken Seite befinden sich ein Client und ein Server, die so heißen.
Werfen wir einen Blick auf die Implementierung im Admin. Erwähnen möchte ich an dieser Stelle, dass auch unser Admin in der neuen Version überarbeitet und in Go implementiert ist. Ihr könnt euch darauf freuen.
Wir stoßen häufig auf die Notwendigkeit, Graustufen zu veröffentlichen oder den Datenverkehr einzufärben. Wir können eine Tag-Governance-Regel vom Administrator senden und dann einige Instanzen markieren, und dann wird der Datenverkehr, der das Tag trägt, nacheinander vom Eingang weitergeleitet, wodurch eine vollständige Einfärbung des Verbindungsdatenverkehrs erreicht wird.
Qt 6.6 ist offiziell veröffentlicht. Das Popup-Fenster auf der Lotterieseite der Gome App beleidigt seinen Gründer . Ubuntu 23.10 ist offiziell veröffentlicht. Sie können den Freitag genauso gut für ein Upgrade nutzen! RISC-V: wird nicht von einem einzelnen Unternehmen oder Land kontrolliert. Folge der Veröffentlichung von Ubuntu 23.10: ISO-Image wurde dringend „zurückgerufen“, da es Hassreden enthielt. Russische Unternehmen produzieren Computer und Server auf Basis von Loongson-Prozessoren. ChromeOS ist eine Linux-Distribution, die Google Desktop verwendet Umwelt 23-jähriger Doktorand behebt 22-jährigen „Geisterfehler“ in Firefox TiDB 7.4 veröffentlicht: offiziell kompatibel mit MySQL 8.0 Microsoft bringt Windows Terminal Canary-Version auf den Markt