Am 18. Oktober stellte Tencent das RPC-Entwicklungsframework tRPC als Open-Source-Version zur Verfügung, das die Eigenschaften „Mehrsprachigkeit und hohe Leistung“ aufweisen soll. Die erste Open-Source-Charge unterstützt Go/Cpp-Programmiersprachen. Wie wir alle wissen, gibt es bereits viele Open-Source-RPC-Frameworks wie gRPC, Thrift, Dubbo und bRPC. Könnte es sein, dass keines davon die Anforderungen von Tencent erfüllen kann? Erfindet Tencent das Rad neu? Brauchen wir wirklich so viele RPC-Frameworks?
Zu diesem Zweck führte Open Source China ein Interview mit dem tRPC-Team von Tencent, um einige der Zweifel der Internetnutzer zu beantworten.
1. Einige Internetnutzer glauben, dass es bereits viele Open-Source-RPC-Frameworks gibt und Tencent mit der Einführung von tRPC das Rad neu erfindet. Was halten Sie von dieser Ansicht?
Es gibt tatsächlich genügend vorhandene Frameworks, aber für Tencent kann ein weiterer Satz von Frameworks nicht einfach ein weiterer Satz sein. Der Kern besteht darin, die vorhandenen Frameworks zu vereinheitlichen.
In der Vergangenheit wurde das RPC-Framework bei Tencent vom Unternehmen selbst ausgewählt, was dazu führte, dass eine Vielzahl von Frameworks im Einsatz waren, darunter Open Source und selbst entwickelte, und Dutzende erreichten. Sie verwenden unterschiedliche Kommunikationsprotokolle und unterschiedliche Namensdienste, was zu einer nicht reibungslosen Interoperabilität zwischen Diensten führt und die Geschäftsentwicklung behindert. Gleichzeitig sind die Wartungs- und Nutzungskosten vieler RPC-Frameworks sehr hoch und es besteht ein dringender Bedarf, die bestehenden Frameworks zusammenzuführen. Unabhängig davon, ob wir ein vorhandenes Framework auswählen oder ein neues Framework für die Konvergenz entwickeln möchten, haben wir vor der Entwicklung von tRPC auch gründlich über dieses Problem nachgedacht, ausführliche interne Diskussionen geführt und uns schließlich für die Verwendung des selbst entwickelten tRPC entschieden. Da die Geschäftsformen von Tencent vielfältig sind und relativ hohe Anforderungen an Leistung, Unterstützung der Entwicklungssprache und Offenheit der Architektur stellen, können Open-Source- oder interne RPC-Frameworks die Geschäftsanforderungen von Tencent nicht vollständig erfüllen.
2. Tencent hat das RPC-Framework Tars im Jahr 2017 als Open Source bereitgestellt. Gibt es einen Zusammenhang zwischen dem heutigen tRPC und Tars? Warum etwas Neues beginnen und ein Neues entwickeln?
tRPC und Tars sind zwei völlig unabhängige Frameworks. Allerdings hat tRPC zu Beginn seines Entwurfs auch einen Teil des Designs von Tars übernommen. Einige der Kernentwickler und Designer von tRPC waren auch die Kernentwickler und Designer von Tars. Der Grund für die Gründung eines neuen Unternehmens liegt hauptsächlich darin, dass Tars das Ziel der Vereinheitlichung des internen Rahmenbestands des Unternehmens nicht erreichen kann. Der Hauptgrund ist, dass die eigene Struktur relativ geschlossen ist. tRPC verfügt über ein Plug-In-Design und eine sehr offene Architektur. Es kann problemlos in bestehende Service-Management-Plattformen integriert werden, was der Bestandskonvergenz förderlicher ist.
3. Wann begann das tRPC-Projekt? Gibt es eine Geschichte dahinter, die es wert ist, erzählt zu werden?
Das tRPC-Projekt startete im Jahr 2019 und ist mittlerweile schon über 4 Jahre her. Zu dieser Zeit, als das Unternehmen über die größte Anzahl bestehender Frameworks verfügte, gab es Dutzende davon, was die Effizienz von Forschung und Entwicklung erheblich beeinträchtigte und die weitere Geschäftsentwicklung behinderte. Es gibt in der Tat viele Geschichten, die sich in tRPC von seiner Gründung bis zu seiner Entwicklung ereignet haben. Zu Beginn der Gründung gab es beispielsweise unterschiedliche Meinungen innerhalb des Unternehmens darüber, ob wir ein neues Unternehmen gründen und tRPC aufbauen sollten, um das bestehende Framework zusammenzuführen. In unserem internen Forum gab es einen Beitrag zu diesem Thema, und im gesamten Unternehmen gab es eine hitzige Diskussion mit Hunderten von Kommentaren und Zehntausenden von PVs. Keine Erklärung.
Nach einer so umfangreichen internen Diskussion wurde schließlich beschlossen, tRPC selbst zu entwickeln. Die Entwicklung von tRPC wurde vom internen technischen Personal des Unternehmens umfassend unterstützt. Um tRPC zu einem umfassenden RPC-Framework zu machen und die wichtige Aufgabe der Vereinheitlichung des Bestands übernehmen zu können, haben wir ein internes Community-Modell für Forschung und Entwicklung eingeführt. Viele technische Kollegen im Unternehmen, die sich mit der Framework-Entwicklung auskennen, haben sich aktiv beteiligt . Hunderte von Menschen haben Code zu tRPC beigetragen. viele. Im Design- und Entwicklungsprozess kam es auch zu einer Kollision verschiedener Ideen. Beispielsweise wurde die architektonische Gesamtform des tRPC-Plug-ins in mehreren nichtöffentlichen Treffen mit Dutzenden von Personen und in heftigen Auseinandersetzungen festgelegt.
4. Warum Open-Source-tRPC? Was erhoffen Sie sich von Open Source für das Projekt?
Es gibt zwei Gründe für Open-Source-tRPC: 1. Es wird benötigt, wenn das interne Geschäft des Unternehmens nach außen expandiert. Wenn beispielsweise ein Spiel ins Ausland geht, muss das Unternehmen privatisiert und von einem externen Unternehmen bereitgestellt werden. Da tRPC zu diesem Zeitpunkt für die Geschäftsentwicklung verwendet wird, muss der Code bereitgestellt werden. 2. Ich hoffe, dass ich über Open Source mehr Technologie teilen und mit der Außenwelt austauschen kann und die Kraft der Community nutzen kann, um tRPC noch besser zu machen.
5. Der Beamte erwähnte, dass tRPC mehrere Kommunikationsprotokolle unterstützt. Können Sie uns konkret sagen, welche Kommunikationsprotokolle unterstützt werden? Können Protokollvielseitigkeit und hohe Leistung gleichzeitig erreicht werden?
Das tRPC-Framework unterstützt standardmäßig das tRPC-Protokoll und unterstützt außerdem die branchenüblichen HTTP(s)/gRPC/bRPC/Tars/Thrift-Protokolle sowie verschiedene interne Kommunikationsprotokolle innerhalb des Unternehmens. Derzeit nur HTTP(s)/gRPC Das Protokoll ist Open Source, und andere Protokolle werden in Zukunft nach und nach Open Source sein. .
Ob das Protokoll sowohl vielseitig als auch leistungsstark ist, hängt eher vom Geschäftsszenario und den Anforderungen ab. Wenn Sie Vielseitigkeit wünschen, können Sie das HTTP- oder gRPC-Protokoll wählen. Wenn Sie hohe Leistung wünschen, können Sie das tRPC-Protokoll wählen. Weil Das Design und die Implementierung des Protokolls selbst haben einen relativ großen Einfluss auf die Leistung.
6. Im Vergleich zu anderen Open-Source-Frameworks erschien tRPC relativ spät. Gibt es aus Sicht der Entwicklungsgeschichte des RPC-Frameworks einen wesentlichen Unterschied zwischen tRPC und anderen Open-Source-RPC-Frameworks?
Die Entwicklung des RPC-Frameworks ist in der Tat sehr ausgereift. Es ist schwer zu sagen, dass es wesentliche Unterschiede zwischen den Open-Source-RPC-Frameworks in der Branche gibt. Sie entsprechen eher den Anforderungen ihrer jeweiligen Geschäftsentwicklung. Der Hauptzweck der Entstehung von tRPC besteht darin, die bestehenden Frameworks des Unternehmens zu konvergieren. Es hat bestimmte Vorteile für Nachzügler. Es kann die Vorteile bestehender bestehender Frameworks absorbieren und Mängel vermeiden. Es baut eine offene Architektur auf, die auf Plug-In-Ideen basiert Grundlage hoher Leistung. Dies macht es besser auf die vielfältigen und komplexen Geschäftsszenarien von Tencent anwendbar.
7. Bei der offiziellen Erwähnung der Projektplanung gibt es zwei Hauptpunkte: Der eine besteht darin, mehr Programmiersprachen als Open Source bereitzustellen: Java, Python und Node. Der andere besteht darin, die Ökologie zu bereichern und weitere Plug-Ins und Komponenten im Zusammenhang mit Cloud Native zu öffnen. Ich möchte fragen, aus welchen Gründen wir dies als eine wichtige Entwicklungsrichtung für die Zukunft betrachten?
Wir hoffen vor allem, dass das Framework breiter und effizienter genutzt werden kann und dass mehr Entwicklungssprachenunterstützung mehr Szenarien abdecken kann. Beispielsweise verwenden viele Unternehmen jetzt die Java-Sprache, und tRPC kann nur dann ein Kandidat werden, wenn es Java unterstützt. Ein weiteres Beispiel ist, dass die meisten KI-Szenarien mittlerweile Python verwenden, sodass tRPC nur verwendet werden kann, wenn es Python unterstützt.
Enriching the Ecosystem hofft außerdem, dass tRPC Benutzern dabei helfen kann, ihre eigenen Microservice-Systeme schneller aufzubauen. Derzeit verwendet jeder gerne Cloud-native verwandte Komponenten, um sein eigenes Microservice-System aufzubauen. Wenn tRPC das Cloud-native Plug-in-Ökosystem bereichern kann, werden Benutzer, die tRPC verwenden, um eine Verbindung mit diesen Cloud-nativen Komponenten herzustellen, effizienter und schneller sein .
8. Tencent hat tRPC, Baidu hat bRPC, Alibaba hat Dubbo und Byte hat Volo. Warum muss jeder große Hersteller sein eigenes RPC-Framework entwickeln?
Warum entwickeln große Hersteller ihr eigenes RPC-Framework? Persönlich denke ich, dass es vor allem von der Geschäftsform bestimmt wird. Obwohl die RPC-Frameworks ähnlich aussehen, gibt es bei ihrer tatsächlichen Anwendung auf Unternehmen viele Unterschiede je nach Unternehmensform. Wenn Sie ein Open-Source-Framework verwenden, ist es sehr wahrscheinlich, dass die Lösung dieser Unterschiede viel kostet und länger dauert oder gar nicht gelöst werden kann. Als wir beispielsweise tRPC in Spieleszenarien verwendeten, stellten wir fest, dass das allgemeine RPC-Design die Anforderungen zustandsbehafteter Geschäftsszenarien wie Spiele nicht erfüllen konnte. Wir basierten auch auf der tRPC-Plug-in-Architektur und arbeiteten mit dem Spieleteam zusammen, um diese zu ersetzen zugrunde liegende Kommunikationskomponenten. Nur um den Bedürfnissen der Spielszene gerecht zu werden. Wenn ein Open-Source-Framework übernommen wird, kann dieses Problem schwierig zu lösen sein.
Alibaba Cloud erlitt einen schwerwiegenden Ausfall und alle Produkte waren betroffen (wiederhergestellt). Tumblr hat das russische Betriebssystem Aurora OS 5.0 abgekühlt . Neue Benutzeroberfläche vorgestellt : Delphi 12 & C++ Builder 12, RAD Studio 12. Viele Internetunternehmen stellen dringend Hongmeng-Programmierer ein. UNIX-Zeit steht kurz vor dem Eintritt in die 1,7-Milliarden-Ära (bereits eingetreten). Meituan rekrutiert Truppen und plant die Entwicklung der Hongmeng-System-App. Amazon entwickelt ein Linux-basiertes Betriebssystem, um die Abhängigkeit von Android von .NET 8 unter Linux zu beseitigen. Die unabhängige Größe ist um 50 % reduziert. FFmpeg 6.1 „Heaviside“ ist erschienen