Dies ist ein Gastbeitrag des Orleans-Teams. Orleans ist ein plattformübergreifendes Framework zum Erstellen verteilter Anwendungen mit .NET. Weitere Informationen finden Sie unter https://github.com/dotnet/orleans .Wir freuen uns, die Veröffentlichung von Orleans 3.0 bekannt zu geben. Seit Orleans 2.0 wurden zahlreiche Verbesserungen und Korrekturen sowie einige neue Funktionen vorgenommen. Diese Änderungen waren auf die Erfahrung vieler Menschen zurückzuführen, die Orleans-basierte Anwendungen in der Produktion in einer Vielzahl von Szenarien und Umgebungen ausführen, sowie auf den Einfallsreichtum und die Leidenschaft der globalen Orleans-Community, die stets bestrebt ist, die Codebasis besser, schneller und besser zu machen flexibel. Ein großes Dankeschön an alle, die auf verschiedene Weise zu dieser Veröffentlichung beigetragen haben!
Wichtige Änderungen seit Orleans 2.0
Orleans 2.0 wurde vor etwas mehr als 18 Monaten veröffentlicht und seitdem hat Orleans bedeutende Fortschritte gemacht. Einige der Überschriftenänderungen seit 2.0 sind:
- Verteilte ACID-Transaktionen - Mehrere Körner können einer Transaktion beitreten, unabhängig davon, wo ihr Status gespeichert ist
- Ein neuer Scheduler, der allein in einigen Fällen die Leistung um über 30% steigerte
- Ein neuer Codegenerator basierend auf der Roslyn-Code-Analyse
- Umgeschriebene Cluster-Mitgliedschaft für verbesserte Wiederherstellungsgeschwindigkeit
- Co-Hosting-Unterstützung
Sowie viele, viele andere Verbesserungen und Korrekturen.
Seit den Tagen der Arbeit an Orleans 2.0 hat das Team in enger Zusammenarbeit mit dem .NET-Team einen positiven Zyklus für die Implementierung oder Integration bestimmter Funktionen wie z. B. generischer Host mit benannten Optionen eingerichtet, bevor diese Funktionen bereit sind, Teil von .NET zu werden Kernversionen, die Feedback und Verbesserungen "vorgelagert" einbringen und in späteren Versionen zu ihren endgültigen Implementierungen wechseln, die mit .NET-Versionen geliefert werden. Während der Entwicklung von Orleans 3.0 wurde dieser Zyklus fortgesetzt, wobei der von Orleans 3.0.0-beta1 verwendete Bedrock-Code verwendet wurde, bevor er schließlich als Teil von .NET 3.0 ausgeliefert wurde. In ähnlicher Weise wurde die Unterstützung von TLS für TCP-Socket-Verbindungen als Teil von Orleans 3.0 implementiert und soll Teil einer zukünftigen Version von .NET Core werden. Wir betrachten diese fortlaufende Zusammenarbeit als unseren Beitrag zum größeren .NET-Ökosystem im Sinne von Open Source.
Austausch der Netzwerkschicht durch ASP.NET Bedrock
Die Unterstützung für die Sicherung der Kommunikation mit
TLS ist seit einiger Zeit eine wichtige Frage, sowohl von
der Community als auch von internen Partnern. Mit der Version 3.0 führen wir die TLS-Unterstützung ein, die über das
Microsoft.Orleans.Connections.Security- Paket verfügbar ist. Weitere Informationen finden Sie im
Beispiel TransportLayerSecurity .
Die Implementierung der TLS-Unterstützung war aufgrund der Implementierung der Netzwerkschicht in früheren Versionen von Orleans ein großes Unterfangen: Sie konnte nicht einfach an die Verwendung von
SslStream angepasst werden, der am häufigsten verwendeten Methode zur Implementierung von TLS. Mit TLS als treibender Kraft haben wir uns auf den Weg gemacht, um die Netzwerkschicht von Orleans neu zu schreiben.
Orleans 3.0 ersetzt seine gesamte Netzwerkschicht durch eine, die auf
Project Bedrock basiert , einer Initiative des ASP.NET-Teams. Das Ziel von Bedrock ist es, Entwicklern beim Aufbau schneller und robuster Netzwerkclients und -server zu helfen.
Das ASP.NET-Team und das Orleans-Team haben gemeinsam Abstraktionen entworfen, die sowohl Netzwerkclients als auch Server unterstützen, transportunabhängig sind und mithilfe von Middleware angepasst werden können. Diese Abstraktionen ermöglichen es uns, den Netzwerktransport über die Konfiguration zu ändern, ohne den internen, Orleans-spezifischen Netzwerkcode zu ändern. Die TLS-Unterstützung von Orleans ist als Bedrock-Middleware implementiert. Wir beabsichtigen, diese generisch zu gestalten, damit sie mit anderen im .NET-Ökosystem geteilt werden kann.
Obwohl der Anstoß für dieses Unternehmen darin bestand, die TLS-Unterstützung zu ermöglichen, sehen wir in unseren nächtlichen Belastungstests eine durchschnittliche Verbesserung des Durchsatzes um ca. 30%.
Beim Umschreiben der Netzwerkschicht wurde auch unser benutzerdefiniertes Pufferpooling durch das Vertrauen in
MemoryPool<byte> Bei dieser Änderung nutzt die Serialisierung jetzt
Span<T> besser aus. Einige Codepfade, die zuvor auf das Blockieren über dedizierte Threads angewiesen waren, die
BlockingCollection<T> aufrufen, verwenden jetzt
Channel<T> , um Nachrichten asynchron weiterzuleiten. Dies führt zu weniger dedizierten Threads, wodurch die Arbeit stattdessen in den .NET-Thread-Pool verschoben wird.
Das Kerndrahtprotokoll für Orleans ist seit seiner ersten Veröffentlichung festgelegt geblieben. Mit Orleans 3.0 haben wir Unterstützung für die schrittweise Aktualisierung des Netzwerkprotokolls über Protokollverhandlungen hinzugefügt. Die in Orleans 3.0 hinzugefügte Protokollverhandlungsunterstützung ermöglicht zukünftige Verbesserungen, z. B. das Anpassen des Kernserialisierers, während die Abwärtskompatibilität erhalten bleibt. Ein Vorteil des neuen Netzwerkprotokolls ist die Unterstützung von Vollduplex-Silo-zu-Silo-Verbindungen anstelle der zuvor zwischen Silos hergestellten Simplex-Verbindungspaare. Die Protokollversion kann über
ConnectionOptions.ProtocolVersion konfiguriert werden.
Co-Hosting über den generischen Host
Das Co-Hosting von Orleans mit anderen Frameworks wie ASP.NET Core im selben Prozess ist dank des
generischen .NET-Hosts jetzt einfacher als zuvor.
Hier ist ein Beispiel für das Hinzufügen von Orleans neben ASP.NET Core zu einem Host mithilfe von
UseOrleans :
var host = new HostBuilder() .ConfigureWebHostDefaults(webBuilder => {
Mit dem generischen Host Builder teilt Orleans einen Dienstanbieter mit anderen gehosteten Diensten. Dies gewährt diesen Diensten Zugang zu Orleans. Ein Entwickler kann beispielsweise
IClusterClient oder
IGrainFactory in einen ASP.NET Core MVC-Controller injizieren und Körner direkt aus seiner MVC-Anwendung aufrufen.
Diese Funktionalität kann verwendet werden, um Ihre Bereitstellungstopologie zu vereinfachen oder einer vorhandenen Anwendung zusätzliche Funktionen hinzuzufügen. Einige Teams verwenden intern Co-Hosting, um ihren Orleans-Silos mithilfe der
ASP.NET Core Health Checks Kubernetes Liveness- und Readiness-Tests hinzuzufügen.
Zuverlässigkeitsverbesserungen
Cluster erholen sich jetzt dank längerem Klatschen schneller von Fehlern. In früheren Versionen von Orleans haben Silos Klatschnachrichten zur Mitgliedschaft an andere Silos gesendet und diese angewiesen, die Mitgliedschaftsinformationen zu aktualisieren. Klatschnachrichten enthalten jetzt versionierte, unveränderliche Snapshots der Clustermitgliedschaft. Dies verbessert die Konvergenzzeit, nachdem ein Silo dem Cluster beigetreten ist oder diesen verlassen hat (z. B. während des Upgrades, der Skalierung oder nach einem Fehler), und verringert Konflikte im gemeinsam genutzten Mitgliedschaftsspeicher, wodurch schnellere Clusterübergänge ermöglicht werden. Die Fehlererkennung wurde ebenfalls verbessert, mit mehr Diagnosemeldungen und Verbesserungen, um eine schnellere und genauere Erkennung zu gewährleisten. Bei der Fehlererkennung werden Silos in einem Cluster gemeinsam überwacht, wobei jedes Silo periodische Gesundheitssonden an eine Teilmenge anderer Silos sendet. Silos und Clients trennen sich jetzt auch proaktiv von Silos, die für nicht mehr funktionsfähig erklärt wurden, und verweigern Verbindungen zu solchen Silos.
Messaging-Fehler werden jetzt konsistenter behandelt, was dazu führt, dass Eingabeaufforderungsfehler an den Anrufer zurückgesendet werden. Dies hilft Entwicklern, Fehler schneller zu erkennen. Wenn eine Nachricht beispielsweise nicht vollständig serialisiert oder deserialisiert werden kann, wird eine detaillierte Ausnahme an den ursprünglichen Anrufer zurückgesendet.
Verbesserte Erweiterbarkeit
Streams können jetzt benutzerdefinierte Datenadapter haben, mit denen sie Daten in jedem Format aufnehmen können. Dies gibt Entwicklern eine bessere Kontrolle darüber, wie Stream-Elemente im Speicher dargestellt werden. Außerdem kann der Stream-Anbieter steuern, wie Daten geschrieben werden, sodass Dämpfe in Legacy-Systeme und / oder Nicht-Orleans-Dienste integriert werden können.
Mit Getreideerweiterungen kann einem Getreide zur Laufzeit zusätzliches Verhalten hinzugefügt werden, indem eine neue Komponente mit einer eigenen Kommunikationsschnittstelle hinzugefügt wird. Beispielsweise verwenden Orleans-Transaktionen Kornerweiterungen, um Transaktionslebenszyklusmethoden wie
Vorbereiten ,
Festschreiben und
Abbrechen einem Korn transparent für den Benutzer hinzuzufügen. Getreideerweiterungen sind jetzt auch für Getreideservices und Systemziele verfügbar.
Der benutzerdefinierte Transaktionsstatus kann jetzt deklarieren, welche Rollen er in einer Transaktion erfüllen kann. Beispielsweise kann eine Transaktionsstatusimplementierung, die Transaktionslebenszyklusereignisse in eine Service Bus-Warteschlange schreibt, die Aufgaben des Transaktionsmanagers nicht erfüllen, da sie schreibgeschützt ist.
Die vordefinierten Platzierungsstrategien sind jetzt öffentlich zugänglich, sodass jeder Platzierungsdirektor während der Konfigurationszeit ersetzt werden kann.
Mach mit
Jetzt, da Orleans 3.0 vor der Tür steht, richten wir unsere Aufmerksamkeit auf zukünftige Releases - und wir haben einige aufregende Pläne! Kommen Sie zu unserer herzlichen, einladenden Community auf
GitHub und
Gitter und helfen Sie uns, diese Pläne Wirklichkeit werden zu lassen.
Orleans Team