AMBROSIA
1.0.0
Windows Build (NetCore3.1):
Windows Build (NetFramework 461):
Linux Build (NetCore3.1):
Knoten JS (NetCore3.1):
Knoten JS (NetFramework 461):
Ambrosia ist ein unabhängiger Ansatz der Programmiersprache zum Autorieren und Bereitstellen von hoch robusten verteilten Anwendungen. Ambrosia senkt dramatisch die Entwicklung und den Einsatzkosten und die Marktzeit, indem sie automatisch Erholung und hohe Verfügbarkeit bereitstellen.
Die heutigen, von den Rechenzentrum orientierten Anwendungen, zu denen heute die beliebtesten Dienste in der Cloud gehören, bestehen aus hochkomplexen, verteilten Software -Stapeln. Zum Beispiel umfassen sie in der Regel Event Hub oder Kafka, um die Eingabe und Interaktionen für die Wiederherstellung der Journal für die Wiederherstellung von Journern robust zu machen, wichtige Informationen in Geschäften wie Azure-Blobs für die Debuggabilität zu protokollieren, und verwenden extrem teure Mechanismen wie verteilte Transaktionen und staatenlose Funktionen mit verteilten persistenten Rück- um genau zu gewährleisten, sobald die Ausführung des Servicecode ausgeführt wird.
Im Gegensatz dazu verleiht Ambrosia Programmierern automatisch Wiederherstellbarkeit, hohe Verfügbarkeit, Debugierbarkeit, Upgraduabilität und genau nach der Ausführung, ohne dass Entwickler solche komplexen Systeme zusammenstellen oder übermäßig teure Mechanismen verwenden müssen.
Um mehr über die Implementierung und Leistung von Ambrosia zu erfahren, können Sie unser VLDB -Papier lesen.
Wir laden Entwickler ein, die auf Ambrosia aufbauen oder bei beitragen möchten, um unserer Gitter -Community beizutreten.
Ambrosia -Konzepte
Wie es funktioniert
Merkmale
Schneller Start für Anwendungsentwickler
Schneller Start für Ambrosia -Mitwirkende
Referenz
Abhängigkeiten
Sprachunterstützung
Verwendung
Sichere Kommunikation zwischen Diensten
Vergleich zu
Die virtuelle Resilienz ist ein Mechanismus in einer (möglicherweise verteilten) Programmier- und Ausführungsumgebung, in der typischerweise ein Protokoll verwendet wird, das die wiederholbar deterministische Art und Serialisierbarkeit einer Anwendung zur automatischen Maskenausfall ausnutzt.
Wir verwenden den Begriff Virtual Resiliency, um den Mechanismus in Ambrosien zu beschreiben, mit dem Programmierer ihre Anwendungen auf fehlgeschlagene, unverwöhnliche Weise schreiben können und die Notwendigkeit von Anwendungsautoren entfernen, Logik für Wiederherstellung oder Zustandsschutz zu schreiben. Datenverarbeitungssysteme, die ihre Abfragen in SQL -Varianten in der Regel ausdrücken, haben ihre Abfrageautoren seit Jahrzehnten virtuelle Resilienz. MAP-Reduce-Systeme, die SQL nicht unbedingt verwenden, bieten diese Funktionen ebenfalls. Beachten Sie, dass diese Funktion in all diesen Fällen die Fähigkeit nutzt, wie Ambrosia deterministisch wiederzugeben.
Um die virtuelle Resilienz durch Ambrosia zu erreichen .
Die grundlegenden Bausteine von Ambrosien sind unsterbliche , zuverlässige verteilte Objekte, die über RPCs kommunizieren. Ein Unsterblicher definiert einen Satz anhaltender Zustand und eine Reihe von RPC -Handlern, die in diesem Zustand arbeiten. Eine Instanz eines Unsterblichen ist eine benannte Einheit, die den Zustand beibehält und RPC -Handler gemäß der Definition des Immortals ausführt. Eine Ambrosia -Anwendung hat häufig mehrere Instanzen desselben Unsterblichen; Eine Anwendung kann beispielsweise einen einzelnen "Job" für die Ausführung eines Datenverarbeitungsjobs definieren und mehrere Instanzen dieses Jobs ausführen, der in verschiedenen Datensätzen arbeitet.
Die folgende Abbildung beschreibt die grundlegende Architektur einer Ambrosia -Anwendung und zeigt zwei kommunizierende Ambrosia -Dienste, die als Immortalen bezeichnet werden. Die inneren Boxen in der Abbildung stellen Code dar, die entweder in zwei separaten Prozessen oder im Fall von C#in einem integrierten Prozess ausgeführt werden können. Jede Instanz eines Unsterblichen existiert als Softwareobjekt und Kontrollfaden, die innerhalb des Anwendungsprozesses ausgeführt werden. Eine unsterbliche Instanz kommuniziert mit anderen unsterblichen Instanzen über den unsterblichen Koordinator , der die RPCs der Instanz dauerhaft protokolliert und die für das Sendern von RPCs erforderlichen Nießer auf niedriger Ebene verkapelt. Die Position der Anfragen im Protokoll bestimmt die Reihenfolge, in der sie dem Antragsverfahren zur Ausführung eingereicht und dann bei der Wiederherstellung erneut ausgesetzt werden.
Darüber hinaus liefert die sprachspezifische Ambrosia -Bindung einen Zustandserializer. Um die Wiederholung von Beginn des Dienstes während der Genesung zu vermeiden, prüft der unsterbliche Koordinator gelegentlich den Zustand des Unsterblichen, der den Anwendungszustand enthält. Die Art und Weise, wie diese Serialisierung bereitgestellt wird, kann von Sprache zu Sprache oder sogar unter Bindungen für dieselbe Sprache variieren.
Hier finden Sie eine Liste von Funktionen, die Ambrosia an Anwendungsentwickler und -Artümer bietet:
Definieren Sie einen neuen Service für Ambrosia
Dienste auf Ambrosia einsetzen
Debugg -Service -Instanz
Aktiv aktiv
Live -Upgrades, Test -Upgrades
RPC
Asynchroner RPC (Alpha)
Beginnen Sie mit einem unserer Proben, um einen Service in Ambrosia zu leisten.
Erstellen Sie den Ambrosia Immortal Coordinator und C# Client -Codegenerator mit diesem Bash -Skript:
./build_dotnetcore_bindist.sh
Bei einem .NET Core SDK funktioniert dies unter Windows, Mac OS oder Linux. Danach haben Sie eine Ambrosia -Binärverteilung im Verzeichnis ./bin in Ihrer Arbeitskopie.
Schauen Sie sich auch unseren Beitragsführer an.
Ambrosia benötigt derzeit ein Azure -Abonnement, um seine Protokolle in den replizierten Speicher zu schreiben. In Zukunft erwarten wir, dass diese Komponente abstrahiert werden, um andere Speicheroptionen für Protokolle zu verwenden.
Ambrosia unterstützt derzeit C# für .NET Core- und .NET -Framework. Ab 2.0.0.0 unterstützt Ambrosia auch Node.js mithilfe von TypeScript. Wir hoffen, in Zukunft Unterstützung für andere Sprachen hinzuzufügen.
Usage: dotnet Ambrosia.dll RegisterInstance [OPTIONS] Options: -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -cs, --createService=VALUE [A - AutoRecovery | N - NoRecovery | Y - AlwaysRecover]. -ps, --pauseAtStart Is pause at start enabled. -npl, --noPersistLogs Is persistent logging disabled. -lts, --logTriggerSize=VALUE Log trigger size (in MBs). -aa, --activeActive Is active-active enabled. -cv, --currentVersion=VALUE The current version #. -uv, --upgradeVersion=VALUE The upgrade version #. -h, --help show this message and exit Usage: dotnet Ambrosia.dll AddReplica [OPTIONS] Options: -r, --replicaNum=VALUE The replica # [REQUIRED]. -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -cs, --createService=VALUE [A - AutoRecovery | N - NoRecovery | Y - AlwaysRecover]. -ps, --pauseAtStart Is pause at start enabled. -npl, --noPersistLogs Is persistent logging disabled. -lts, --logTriggerSize=VALUE Log trigger size (in MBs). -aa, --activeActive Is active-active enabled. -cv, --currentVersion=VALUE The current version #. -uv, --upgradeVersion=VALUE The upgrade version #. -h, --help show this message and exit Usage: dotnet Ambrosia.dll DebugInstance [OPTIONS] Options: -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -c, --checkpoint=VALUE The checkpoint # to load. -cv, --currentVersion=VALUE The version # to debug. -tu, --testingUpgrade Is testing upgrade. -h, --help show this message and exit
Lesen Sie, wie Sie die Kommunikation zwischen verteilten Komponenten sichern, die hier auf Ambrosien eingesetzt werden.
