Die netzwerkübergreifende Hybrid-Cloud-Datenpraxis von Zhengcai Cloud basiert auf Dubbo

12,23 Yuan Chuanghui·Shanghai Station, sprechen wir über die LLM-Infrastruktur

*Autor: Wang Xiaobin, leitender Entwicklungsingenieur von Zhengcaiyun

Hintergrund des Projekts

Das Unternehmen von Zhengcaiyun ist eine Shopping-Website für die Regierung, ähnlich wie Taobao. Das öffentliche Beschaffungswesen wird Unternehmensbeschaffungs- und Regierungsbeschaffungsgeschäfte über die Zhengcai Cloud abwickeln.

Die „Cloud“ in Yundao bezieht sich auf unsere Cloud-Plattform. Die Cloud-Plattform ist eine Reihe von Einkaufswebsites, die von unserem Unternehmen bereitgestellt werden. Technisch gesehen entspricht sie einer Reihe von Microservice-Frameworks. Was die „Insel“ betrifft, verfügen beispielsweise Anhui oder Shanxi über eigene lokale Netzwerke. Wenn wir dort eine Reihe dieses Service-Frameworks bereitstellen, wird es als „Insel“ bezeichnet. Unsere Cloud-Plattform wird hauptsächlich von der Provinz Zhejiang und anderen verwandten Regionen genutzt.

Es gibt Probleme bei der Datenübertragung zwischen unserer Cloud und der Insel. Beispielsweise erhalte ich jetzt eine Ankündigung der Regierung, und diese Ankündigung kann landesweit erfolgen. Dann kann ich die Ankündigung auf der Cloud-Plattform-Verwaltungsplattform aufzeichnen und veröffentlichen. Zu diesem Zeitpunkt wird es eine gewisse Datensynchronisierung zwischen der Cloud und der Insel geben.

1. Cloud Island-Netzwerk

Für unsere Cloud-Plattform ist dieses LAN vollständig innerhalb unseres Unternehmens steuerbar. Wenn Sie beispielsweise einen Port öffnen möchten, kann dieser schnell geöffnet werden. Auf der Inselseite kann es sich um ein lokales Netzwerk oder ein privates Netzwerk handeln. Wir haben beispielsweise zuvor ein Projekt der Zheshang Bank durchgeführt, die eine völlig isolierte Insel ist. Ihre Sicherheitsrichtlinien und Portöffnungen werden alle von ihnen selbst definiert. Dies ist die Geschäftsstruktur unserer Cloud Island.

2. Hybrides Cloud-Island-Netzwerk

Das Bild oben ist ein grobes Datenverbindungsdiagramm. Unter der Cloud-Plattform gibt es Zweige und Zweige, die einer Reihe von Geschäftssystemen entsprechen. Die Regierungs-Cloud ist die entsprechende Block- und isolierte Regierungs-Cloud auf Provinzebene (Provinz Anhui) oder kommunaler Ebene (Stadt Wuxi), die ich gerade erwähnt habe. Private Deployment ist eine typische Hybrid-Cloud-Netzwerkarchitektur für Banken, staatliche Unternehmen, Militär, Regierung und Unternehmen usw.

3. Merkmale des Hybrid-Cloud-Inselnetzwerks

Zu den Merkmalen unserer Hybrid-Cloud-Netzwerkarchitektur gehören:

Plattformkonsistenz. Der Codesatz, den wir auf öffentlichen Clouds, Cloud-Plattformen, Regierungs-Clouds und privaten Clouds bereitstellen, ist derselbe. Wenn wir einen Codesatz an verschiedenen Orten bereitstellen, werden daraus mehrere Plattformen.
Netzwerkverbindung und Wiederverwendung von Funktionen. Wir werden uns auf einige Funktionen von Drittanbietern verlassen, z. B. Textnachrichten, aber die Netzwerkkontrolle in der privaten Cloud ist relativ streng, sodass der Prozess des Austauschs von Ports oder Netzwerken mit Drittanbietern umfangreicher sein wird kompliziert. Zu diesem Zeitpunkt hoffen wir, die Funktionen unserer Cloud-Plattform wiederzuverwenden. Zu diesem Zeitpunkt gibt es eine gewisse Dateninteraktion zwischen ihnen.
Domänenübergreifende Zugriffsmigration. Es gibt ein Szenario des domänenübergreifenden gegenseitigen Zugriffs.
Einheitliche Plattformverwaltung. Wenn wir wie in dem Beispiel, das ich gerade gegeben habe, eine Ankündigung veröffentlichen möchten, hoffen wir, dass diese auf einer Plattform verwaltet werden kann. Anstatt einen nach Zhejiang und einen nach Anhui zu schicken, sind die Wartungskosten relativ hoch.

4. Schwachstellen in Regierungs- und Unternehmensnetzwerken

Viele Unternehmen arbeiten mit der Regierung zusammen. Regierungs-Unternehmensnetzwerke weisen die folgenden Merkmale auf:

Das Netzwerk ist komplex. Beispielsweise sind die Sicherheit und die internen Angelegenheiten von Banknetzwerken sehr komplex und es sind viele Prozesse erforderlich, um sie zu öffnen. Sie müssen sie häufig ausführen. Wenn Sie mit der Ausführung fertig sind, werden Sie auf neue Probleme stoßen und müssen sie erneut ausführen .

Die Sicherheitsanforderungen sind hoch. Wenn wir beispielsweise einen Port öffnen, müssen wir Daten übertragen. Wenn die darin enthaltenen serialisierten Protokolle nicht ihren Spezifikationen entsprechen, werden sie entfernt. Das uns zu diesem Zeitpunkt gegebene Geschäft ist eigentlich eine Auszeit oder eine allgemeine Ausnahme. Und wir wissen nicht, was passiert ist, was unbekannte Risiken mit sich bringt.

Geschäftsorientierter Betrieb und Wartung. Wir werden Dinge nur dann bereitstellen und ausführen, wenn wir Geschäfte haben. Wir werden mehrere und wiederholte Investitionen tätigen, was zu höheren Personal- und Zeitkosten sowie mehr privaten Einsätzen führen wird.

5. Bestehende Lösungen

Basierend auf den oben genannten Schwachstellen haben wir zwei Pläne gemacht.

Die erste Lösung ist eine Einweglösung basierend auf Dubbo Filter. Diese Lösung hat eine längere Geschichte und weist zwei Merkmale auf.

Das erste Merkmal ist die Einwegübertragung. Es gibt nur eine Richtung von „Insel“ zu „Cloud“. Der Grund dafür, dass es auf Dubbo Filter basiert, ist, dass die Microservices in unserem Unternehmen alle über Dubbo aufgerufen werden, sodass wir stark von Dubbo abhängig sind. Daher wird die Lösung für datenübergreifende Netzwerke definitiv auf den Eigenschaften von Dubbo basieren.

Das zweite Merkmal besteht darin, dass die lokale Bereitstellung von Unternehmensanbieterfiltern einen Betriebs- und Wartungsaufwand darstellt. Wenn die Insel Daten mit der Cloud synchronisieren muss, werden diese vom Business-Web der Insel an den Business-Provider der Cloud übertragen. Zu diesem Zeitpunkt muss ich auch eine Reihe von Geschäftsanbietern auf der Insel einsetzen. Der Grund für die Bereitstellung besteht darin, dass die Anforderung abgefangen und dann an das auf der Cloud-Plattform bereitgestellte Dubbo-Gateway weitergeleitet wird.

Aber dieses Mal wird es eine Belastung für uns sein. Es wäre in Ordnung, wenn die Insel Daten in der Datenbank speichern würde, da der Anbieter bereits existiert. Allerdings werden einige Unternehmen nur netzwerkübergreifend genutzt und haben keine lokale Datenbank darin gespeichert. Dann wäre der vom Unternehmen eingesetzte Anbieter überflüssig diesmal.

Die zweite Lösung ist eine Mesh-Punkt-zu-Punkt-Lösung. Da Netzwerkinteroperabilität zwischen Inseln erforderlich ist, wird der Port zwischen diesem Punkt und dem Punkt, den Sie übertragen müssen, separat geöffnet. Nachdem es aktiviert ist, können wir es aufrufen. Die aufrufende Methode kann Dubbo oder eine andere sein.

Diese Lösung weist einen offensichtlichen Fehler auf: Es gibt zu viele Linien, sodass auch die Komplexität der Öffnung zwischen Punkten sehr hoch ist, was sich ebenfalls nachteilig auf die spätere Erweiterung auswirken kann.

Zu den Problemen mit den oben genannten Lösungen gehören die einseitige Übertragung, hohe Kosten für die Aktivierung der Whitelist, hohe Kosten für die Plattformwartung und das Fehlen öffentlicher Funktionen.

Basierend auf den oben genannten Problemen haben wir einen neuen Plan namens Schnellstraße erstellt.

Warum heißt es Autobahn?

Warum heißt es Autobahn? Denn der Effekt, den wir erreichen wollen, ist:

Nur einmal erstellen und wiederverwendbar

Solange beispielsweise die Schnellstraße von Peking nach Shanghai breit genug ist, reicht eine aus. Wenn Sie von Shanghai nach Peking oder von Hangzhou nach Peking fahren, kann es wiederverwendet werden und es ist nicht erforderlich, ein separates Gebäude zu bauen.
Tunnelmechanismus

Da die Orte, an denen Autobahnen gebaut werden, nicht unbedingt in Ebenen liegen, können sie in der Nähe von Flüssen, Meeren, Bergen usw. liegen. Wenn wir einen Tunnel unter der Autobahn bauen, ist dieser für den Fahrer zu diesem Zeitpunkt unempfindlich. Unser Ziel ist dasselbe. Wenn Sie der Meinung sind, dass Regierungs- und Unternehmensnetzwerke kompliziert sind, helfen wir Ihnen, diese zu blockieren, damit Sie nicht länger verwirrt sind.
Berücksichtigen Sie die Übertragungsleistung

Wenn jede Geschäftsabteilung ihre eigenen Übertragungsverbindungen aufbaut, reicht die Übertragungsleistung aus, solange sie ihr eigenes Geschäft betreiben kann, da sie nicht unbedingt von anderen verwendet werden muss, oder wenn sie von anderen verwendet wird, ist dies der Fall wird nur in geringem Umfang genutzt. Wenn Sie jedoch eine wiederverwendbare Verbindung aufbauen, müssen Sie die Übertragungsleistung berücksichtigen.

Straßenbaupraxis

Als nächstes stellen wir einige der Probleme vor, auf die wir beim Bau von Autobahnen gestoßen sind, und die spezifischen Methoden. Beim Clientzugriff sind folgende Probleme aufgetreten:

Das erste Problem ist die starke Abhängigkeit von Dubbo.

Das zweite Problem, die transparente Übertragung, ändert nichts an der Art und Weise, wie Dubbo verwendet wird. Das heißt, ich muss nicht selbst einige Anmerkungen schreiben, um Dubbo zu ersetzen, oder einige APIs schreiben, um Dubbo aufzurufen. Denn nach dem Schreiben sind einige Neulinge möglicherweise nicht in der Lage, es zu verstehen oder sich daran zu gewöhnen, und sie wissen möglicherweise nicht, welche Fallstricke es gibt. Wenn wir also das Original-Dubbo verwenden, ist dies für Benutzer möglicherweise unbequemer.

Das dritte Problem ist der flexible Zugriff und die Unterstützung mehrerer Formulare. Obwohl wir stark auf Dubbo angewiesen sind und Dubbo unterstützen müssen, müssen wir auch andere Formen wie HTTP unterstützen. Vor dem Zugriff müssen wir jedoch die Frage der Zugriffsflexibilität berücksichtigen.

Lassen Sie uns zunächst die Dubbo-Methode vorstellen. Es gibt drei Hauptmethoden für den objektiven Zugriff auf Dubbo:

Die erste Methode ist die Annotation. Verwenden Sie den von @DubboReference bereitgestellten Parameter „Allgemeine Parameter“, um das Routing-Ziel festzulegen und so ein Routing mit Methodengranularität zu erreichen. Die Routing-Informationen werden in die mittleren Parameter geschrieben. Parameter sind die Übertragung allgemeiner Parameter, die Dubbo uns zur Verfügung stellt.

Wenn es normal ist und ich diese Informationen schreibe, wird Dubbo keine Verarbeitung durchführen, da diese Sache keine Bedeutung hat. Da Sie jedoch das Highway SDK eingeführt haben, werden wir nach dem Schreiben dieses Dings die Dubbo-Anfrage analysieren, abfangen, die Parameter in Parametern erfassen und einige Routing-Verarbeitungen durchführen. Dieses Formular ändert eigentlich nichts an der Verwendung von Dubbo.

Der zweite Typ wird vom Konfigurationscenter angegeben. Beispielsweise verwenden wir das Konfigurationscenter von Apollo, das die Zugriffsmethode vollständig ersetzen kann. Parameterinformationen können auch im Konfigurationscenter konfiguriert werden, sofern das SDK dies unterstützen kann. Tatsächlich ist der Code dieser Methode völlig unaufdringlich, das heißt, es gibt keinen Unterschied zwischen vor und nach dem Durchqueren des Netzwerks. Am Ende stellten wir jedoch fest, dass unserem Unternehmen diese Methode nicht gefiel. Erstens mochten die Leute Apollo nicht und zweitens war es schwer zu verstehen. Wenn sich ein Neuling diesen Code ansieht, wird er denken, dass er die lokale Schnittstelle anpasst.

Der dritte Typ ist die Thread-Spezifikation. Wenn Sie die Routing-Informationen im Thread angeben und ihn dann erneut aufrufen, verwendet dieser Aufruf Ihre Route. Bei einem erneuten Aufruf wird es wieder an die lokale Adresse weitergeleitet. Da es auf Threads basiert, werden in der Dubbo-Erweiterung die Thread-Informationen nach Abschluss des Aufrufs bereinigt. Bitte beachten Sie also, dass Sie es mehrmals schreiben müssen, wenn Sie es mehrmals aufrufen möchten. Wenn Sie nicht mehrmals schreiben möchten, können Sie die obige Methode verwenden. Solange Sie es in die aktuelle Bean injizieren, wird es nach Shanghai weitergeleitet.

Als nächstes stellen wir die Architektur der Schnellstraße vor. Ich habe gerade die Punkt-zu-Punkt-Methode eingeführt. Ihr Nachteil besteht darin, dass das Öffnen einer Whitelist komplizierter ist. Jetzt ist unsere Schnellstraßenarchitektur eine neue Architektur, sodass die Komplexität beim Öffnen einer Whitelist geringer ist.

Wie im Bild oben gezeigt, ist der Knoten ganz links Shanghai und der oberste Knoten Anhui. Ich möchte von Anhui nach Shanghai gehen. Zu diesem Zeitpunkt muss das zentrale Gateway eine Whitelist öffnen. Nach dem Öffnen kann dieser Link direkt weitergegeben werden. Sie sehen, dass es insgesamt nur sechs Zeilen gibt, sodass die Komplexität geringer ist.

Das Bild oben ist das Kernarchitekturdiagramm der Autobahn.

Wenn beispielsweise APP1 im Shanxi-Cluster APP2 anpasst, möchte ich Shanghai APP2 anpassen. Wenn Sie nichts tun, wird standardmäßig APP2 im Shanxi-Cluster angepasst. Wenn Sie beim Aufruf der APP einige Routing-Informationen hinzufügen, unterbricht das im Shanxi-Cluster APP1 platzierte SDK seinen Datenverkehr zum Dubbo-Gateway des Shanxi-Clusters.

Danach wechselt das Dubbo-Gateway über das HTTP-Protokoll zum Unified Gateway und dann über das HTTP-Protokoll zum Dubbo-Gateway im Shanghai-Cluster. Hier erhalten Sie die Routing-Informationen, einschließlich des aufgerufenen Dienstes, der Methode, der Versionsnummer, der Parameter usw. Passen Sie dann APP1 des Shanghai-Clusters durch Generalisierung an und kehren Sie schließlich zurück, um diesen netzwerkübergreifenden Aufruf abzuschließen.

Warum gibt es also die Rolle des Dubbo-Proxys? Warum nicht direkt von APP1 zum Unified Gateway wechseln? Wäre es nicht besser, einen Schritt zu überspringen? Dafür gibt es drei Gründe:

Obwohl in diesem Bild nur ein APP1 gezeichnet ist, gibt es im Shanxi-Cluster tatsächlich viele Anrufe. Wenn Hunderte von Anwendungen direkt mit dem Unified Gateway verbunden sind, muss das Gateway viele lange Verbindungen herstellen und die Ressourcen des Unified Gateway sind begrenzt.

Aus Sicherheitsgründen müssen Sie möglicherweise bei jedem Anruf die Whitelist durchgehen, um die Sicherheit zu gewährleisten. Wenn Sie zu diesem Zeitpunkt einen Dubbo-Proxy hinzufügen, können Sie IP konvergieren. Es besteht keine Notwendigkeit, mit Dubbo Proxy auf der Insel zu interagieren, da sie sich in derselben Umgebung befinden und keine Sicherheitsaspekte berücksichtigt werden müssen. Wenn Dubbo Proxy das Gateway anfordert, wird die IP konvergiert, da zwischen dem Gateway und dem einheitlichen Gateway nur eine Verbindung besteht.

Ein weiterer Grund ist die Konvergenz von Funktionen. Wenn später ein Upgrade erforderlich ist und das SDK aktualisiert wird, muss jede Anwendung aktualisiert werden. Dies erfordert die Förderung von Geschäftsupgrades, was schwieriger ist. Daher hoffen wir, alle Upgrade-Funktionen in einer Anwendung zusammenzufassen und keinen Einfluss auf die Geschäftsfunktionen zu haben. Wir müssen nicht einmal das SDK aktualisieren. Da das SDK eine Aufgabe erfüllt, nämlich die Route zu wechseln, ist eine Aktualisierung grundsätzlich nicht erforderlich.

Für das Unternehmen ist es also auch befreiend. Ich verstehe es als funktionalen Vorteil. Dieses Modell heißt Distributed Runtime und erfreut sich mittlerweile großer Beliebtheit. Wir können es als Dapr verstehen, das einige gängige und mühsame Vorgänge in öffentliche unabhängige Prozesse einfügt und das SDK für das Geschäft sehr rein macht.

Warum sollte außerdem das HTTP-Protokoll verwendet werden? Es ist auch kein sehr effizientes Protokoll. Dubbo2 im Dubbo-Protokoll ist eigentlich relativ rationalisiert, mit Ausnahme einiger Co-Formate, bei denen es sich allesamt um Daten handelt. In diesem Fall können wir tatsächlich darüber nachdenken, HTTP später zu aktualisieren, um die Leistung zu steigern.

Der Grund, warum das HTTP-Protokoll jetzt verwendet wird, ist, dass es ein Standardprotokoll ist. Viele Geräte können durchgehen, obwohl wir hier nur eines zeichnen. Das HTTP-Protokoll weist keine Hindernisse auf. Wenn Sie das Dubbo-Protokoll verwenden, müssen Sie diese immer noch einzeln überwinden.

Um diese Architektur zu implementieren, kann Dubbo selbst nicht direkt verwendet werden. Da Dubbo keine netzwerkübergreifenden Funktionen bietet, müssen wir die Probleme, auf die wir stoßen, auf der Dubbo-Ebene lösen.

Was dynamisches IP-Switching angeht, unterstützt Dubbo es tatsächlich, aber da diese Funktion relativ neu ist, wird es einige Probleme geben. Sein Unterstützungsgrad ist teilweise, zum Beispiel hat Dubbo2 es am Anfang nicht unterstützt, aber Dubbo3 hat es unterstützt. Darüber hinaus wird es einige Fehler geben.

In Bezug auf die 404-Erweiterung gilt für HTTP: Wenn Sie eine Schnittstelle anpassen müssen, diese Schnittstelle jedoch nicht vorhanden ist, wird ein 404-Fehler an das Frontend zurückgegeben. Wenn wir beispielsweise den Datenverkehr von APP1 auf Dubbo Proxy umstellen, ist Dubbo Proxy tatsächlich eine Anwendung von Dubbo. Es führt ein Dubbo-JAR-Paket ein, bei dem es sich um eine leere Anwendung von Dubbo handelt. Nachdem dieser Datenverkehr das Gateway von Dubbo erreicht hat, kann es ihn nicht mehr erkennen. Seine Funktion besteht darin, ihn weiterzuleiten. Zu diesem Zeitpunkt müssen wir diese Erweiterung hinzufügen.

Im Folgenden wird der Tunnelmechanismus vorgestellt. Die Funktion des Tunnelmechanismus besteht darin, die Komplexität des Netzwerks abzuschirmen, die Zwischenprotokollkonvertierung abzuschirmen und Benutzern eine einheitliche und transparente Aufrufmethode bereitzustellen.

Der Körper im Zwischen-HTTP-Protokoll bringt einen Originalkörper mit sich. Packen Sie es nach dem Verpacken aus und passen Sie es dann durch Verallgemeinerung an. Zu diesem Zeitpunkt kann der Tunnel diese Unterschiede abschirmen.

Darüber hinaus unterstützt der Tunnelmechanismus das Dubbo-Protokoll besser. Wenn beispielsweise APP1 und die lokale APP 3 schließlich an APP2 übertragen werden, sehen sie, dass die Binärströme identisch sind. Da ich nichts getan habe, habe ich es einfach eingepackt und schließlich wieder ausgepackt. Bis auf ein paar Routing-Informationen in der Mitte ist alles andere genau gleich.

Der Vorteil dieses Mechanismus besteht darin, dass grundsätzlich alle Funktionen von Dubbo unterstützt werden können. Es gibt aber auch Einzelfälle, etwa token- und netzwerkbezogene Mechanismen.

Zukunftsplan

In Anlehnung an die Netzwerk-Schichtenarchitektur haben wir einige Pläne für die Autobahn gemacht:

Die erste Schicht ist die physische Netzwerkschicht. Es hat eigentlich wenig mit uns zu tun, denn was ich verstehe, ist das Öffnen von Ports. Nachdem Sie so viele Dinge geöffnet haben, können Sie einige Erfahrungen oder Methoden zusammenfassen, um diese Angelegenheit zu beschleunigen.

Die zweite Schicht ist die Beschleunigung der Kommunikationsprotokollschicht. Wir können die Zwischenweiterleitung des HTTP-Protokolls beschleunigen. Beispielsweise identifiziert das Tripple-Protokoll auch Netzwerkgeräte auf Basis von HTTP2 und löst dann das Problem. Daher können wir auch eine Untersuchung und Optimierung auf der Ebene des Kommunikationsprotokolls in Betracht ziehen.

Die dritte Schicht ist die Beschleunigung der Kompilierung der Sprachschicht. Wir haben GraalVM auch schon einmal untersucht und es tatsächlich ausprobiert. Obwohl es nicht implementiert wurde, ist eine Kompilierungsbeschleunigung möglich. Insbesondere die Gateway-Schicht zeichnet sich durch großen Datenverkehr aus, aber jeder Datenverkehr ist extrem klein und stellt relativ hohe Leistungsanforderungen an die Sprache selbst. Wenn es in Go implementiert wird, wird es tatsächlich eine bessere Beschleunigung geben.

Die vierte Schicht ist die Funktionsaktualisierung der Framework-Schicht. Wir machen auch viele Dinge auf der Middleware-Ebene.

Die fünfte Ebene ist die allgemeine Aufgabenplanung und Orchestrierung. Der Anruf wird tatsächlich über viele Knoten geleitet, z. B. von a nach b nach c nach d nach e. Wenn das Geschäft komplexer wird, haben wir möglicherweise mehr Routen. Beispielsweise sind in Zukunft auch a bis c, c und d kombiniert zu d geplant.

Stufe 6: Individuelle Aufgabenplanung und Orchestrierung.

Schicht 7: Überwachung, Alarm und Beobachtbarkeit.

Schicht 8: Standards & Prozess & Sicherheit.

Erstellen Sie abschließend eine Zusammenfassung.

Warum möchten Sie dieses Projekt machen? Bisher gab es viele Lösungen und die Kosten waren relativ hoch. Deshalb brauchen wir einen einheitlichen Plan, der mehr öffentliche Dinge berücksichtigt und diesen Plan dann fördert. Derzeit haben wir viele Anwendungen miteinander verbunden und es ist eine einheitliche Lösung für die Regierungsdaten des Unternehmens im gesamten Netzwerk entstanden.

Die Effekte, die wir erreichen wollen, die Projektstruktur und die Zukunftspläne wurden gerade erst vorgestellt, daher werden wir sie nicht noch einmal wiederholen.

Konzentrieren wir uns auf unsere Open Source- und Community-Zusammenarbeit. Die Lösung wird derzeit tatsächlich intern von unserem Unternehmen verwendet, und Dubbo wurde ebenfalls stark angepasst. Im Allgemeinen wählen wir eine private Version für die Entwicklung, aber da wir Open Source sein wollen, haben wir gleich zu Beginn mit der Dubbo-Community kommuniziert, um zu sehen, ob sie auf der Open-Source-Ebene implementiert werden kann. Einerseits kann uns die Community dabei helfen, diese Funktionen zu überprüfen und einige Sicherheitskontrollen durchzuführen. Andererseits können wir auch einige der Dinge, die wir tun, insbesondere öffentliche Dinge, herausnehmen und sie der Gemeinschaft zurückgeben.