---

September 2018

Band 33, Nummer 9

Dieser Artikel wurde maschinell übersetzt.

Microservices - Architekt Blockchain-Anwendungen als Microservices

Durch Stefano Tempesta | September 2018

Microservices und Blockchain intelligente Verträge haben viel gemeinsam. Sie werden sowohl vorausgesetzt, dass isoliert (Chain) ausführen und die Kommunikation mit der Außenseite (off-Chain) über eine nachrichtenbasierte-Kanal. Sie sollten sowohl klein, führen Sie autonom und unabhängig voneinander entwickelt werden und bieten eine bessere Leistung, wenn sie in einem dezentralen Netzwerk bereitgestellt werden.

In diesem Artikel wird die Entwurfsprinzipien, Artefakte und Codebeispiele zum Erstellen von Blockchain-Anwendungen unter Verwendung eines Microservice-Architektur-Formats, und sie auf der Microsoft Azure Blockchain-Plattform bereitstellen.

Microservices stellen perfekt die Intention des der Unix-Philosophie: Führen Sie einen Schritt aus, und führen Sie es auch (tcrn.ch/2vnq5Pb). Ein Microservice ist eine unabhängig bereitstellbare Komponente des gebundenen Bereichs, der Interoperabilität durch nachrichtenbasierte Kommunikation unterstützt. Bei diesem lokalen ist Microservice-Architektur einen Stil des Engineering, die Hilfe stark automatisierte, optimierbare Softwaresysteme setzt sich aus Microservices für Single-Funktion erstellen.

Welche Blockchain haben Anwendungen enthält, die auch Microservices und welche Entwurfsprinzipien von Microservice-Architekturen in die dezentralisierte Umgebung angewendet werden können? Die Tabelle in Abbildung1vergleicht, Microservices und smart Contracts für bestimmten Designs Attribute.

Abbildung 1-Microservices und Blockchain-Entwurfsprinzipien

Entwurfsprinzip	Microservice	Smart Contract
Einzigen Verantwortung	In der Regel enthält eine CRUD-Schnittstelle für eine einzelne Entität ein.	Definiert die Rollen, Status und die entsprechende Logik für einen Workflow für die Überprüfung auf ein einzelnes Objekt, mit dem KREBS-Ansatz (später in diesem Artikel).
Begrenzte Kontext	Keine Abhängigkeit von anderen Diensten, besitzt das Datenmodell für die dauerhafte Speicherung.	Hat keine Abhängigkeit für andere intelligente Verträge und nutzt das on-Chain-Daten-Modell (d. h. der blockchain-Komponente selbst) als bevorzugte Datenmodell.
Messaging aktiviert	Kann ein API-Gateway für die Kommunikation zwischen Diensten und einer Servicebus für die dienstinterne Kommunikation nutzen.	"FTP" oder "Cryptlets" profitieren für off-Chain-Daten zugreifen oder Tools wie Azure Blockchain Workbench, die eine REST-API verfügbar machen.
Autonom entwickelt.	Mehrere Programmiersprachen und Frameworks.	Mehrere Blockchain-Plattformen verfügbar, obwohl keine plattformübergreifenden Kommunikation derzeit vorhanden ist.
Unabhängig bereitstellbare	Mit dem richtigen Design (Event-sourcing "," CQRS) verringern oder Abhängigkeiten vollständig entfernen können.	Es gelten ähnlichen Entwurfsmustern (in diesem Artikel beschrieben).
Verteilt und dezentralisiert	Verteilten Architektur im Gegensatz zu einer zentralen "monolithischen Anwendung."	Integrierte verteilt und dezentralisiert digitales Hauptbuch beabsichtigt.

 

Entwerfen von blockchainanwendungen als Microservices kann die folgenden Vorteile, die Projektmappe erhöhen:

• Können Sie viele Software-Engineering-Initiativen zur parallelen Ausführung.
• Verringern Sie die Abhängigkeiten zwischen den Teams zur Entwicklung und Test-Software.
• Unterstützt mehrere Technologien, Sprachen und Frameworks.
• Einfache Innovation durch verwerfbare Code höher gestuft werden.

Microservices werden in der Regel an die Außenwelt über eine Anwendungsprogrammierschnittstelle (API), die eine gemeinsame Sprache, z. B. JSON oder SOAP, mit dem Client gemeinsam sprechen – eine Verkehrssprache des messaging-fähige Systeme über verschiedene Technologien (.NET, Java, bereitstellen Node.js usw.) und Plattformen (Windows, Linux). Dies gilt auch für die Blockchain-API von Azure Blockchain Workbench verfügbar gemacht werden, wie Sie weiter unten in diesem Artikel sehen werden.

Aus Microservices dezentralisierte Anwendungen

Wenn Sie mit der DevOps-Standpunkt der zum Behandeln von Ihren Servern wie rinderherde und keine Haustiere vertraut sind (bit.ly/2vrdM4p), Sie können den gleichen Ansatz auf den Quellcode anwenden. Einfach verwerfbare Code reduziert technischen Schulden, höher stufen Modernisierung engineering-Prozesse und Betriebskosten zu verringern, indem Sie die Optimierung der Infrastruktur (z. B. in Containern oder serverlos Konfigurationen).

Entwerfen von microservices-Architekturprinzipien Blockchain-Anwendungen kann auch geschäftliche Vorteile erzielt werden. Verbesserte Effizienz bei der das Softwaresystem reduziert die Kosten für Infrastruktur und das Risiko von kapazitätsbezogenen Dienstausfälle. Diese Aspekte sind besonders wichtigen private Blockchains, in dem aus Kostengründen und Service Continuity hauptanforderungen für Unternehmen.

Microservice-Architektur Prinzipale unterstützen mit austauschbaren Komponenten, verringern technischen Schulden, der von Alterung und unzuverlässigen Umgebungen führen können. Solidity, die Programmiersprache für intelligente Verträge in Ethereum verfügt über einen Mechanismus zum Festlegen der genauen Laufzeitversion für die einzelnen Vertrag ausgeführt wird. Im Laufe der Zeit kann einen smart Contract-Versionsnummer zur Identifizierung von Code für den veralteten Blockchain gespeichert, die möglicherweise ein Kandidat für die Ersetzung verwendet werden. Bedenken Sie, dass in einer Blockchain, Smartcards, die Verträge bereits verarbeitet wurden (d. h. sind Teil eines Blocks "abgeleitet") kann nicht gelöscht werden, muss eine neue Version eines Vertrags für zukünftige Transaktionen veröffentlicht werden.

Ein weiterer Vorteil ist eine bessere Skalierbarkeit Common Language Runtime, dadurch kann ein Softwaresystem zum vergrößert oder verkleinert werden mit den Bedarf an. Intelligente Verträge implementiert wie Microservices berechtigungsbasierte Blockchains in einer privaten Business oder Consortium zur Verteilung von Workloads für die Transaktion und Mining-Knoten in eine flexiblere Art und Weise zu ermöglichen.

Ist auf der grundlegendsten Ebene Microservice-Architektur zum Aufteilen einer Anwendung oder das System in kleinere Teile und profitieren Sie von der verteilten Umgebung erhalten. In gleicher Weise die verteilte Struktur von der Peer-zu-Peer-Netzwerk profitieren intelligente Verträge, die in einer Blockchain ausgeführt. Intelligente Verträge können mit einem Microservice-orientierten Architektur Design bereitstellen, verbesserte Effizienz, Skalierbarkeit und verwaltbarkeit – alle Attribute, die für die korrekte Implementierung von Blockchain-Lösungen im Unternehmen unverzichtbar sind.

 

Dezentralisierte Domain-Driven Design

Eine Anwendung für eine dezentralisierte digitale blockchainledger schreiben, und Sie arbeiten mit Infrastruktur und Software-Anforderungen, die typisch für ein verteiltes System, z. B. Isolation der Speicherung, asynchrones messaging und verteilten Transaktionen. Blockchain-Anwendungen erfordern auch die Authentifizierung von Benutzern und Geräten und zum Ausführen bestimmter Aktionen innerhalb eines smart Contract autorisiert. Erweitern auf den Ansatz mit beliebten Domain-Driven Design (DDD), verweisen ich die Methode der Berücksichtigung von Entitäten, Prozesse und Eigenschaften eines Blockchain-Systems als "Dezentralisiert Domain-Driven Design" oder DDDD.

Als erstes definieren die Domäne oder den Kontext, der die Ausführung der intelligente Verträge in ein digitales Hauptbuch. Intelligente Verträge stellen die Geschäftslogik der blockchainanwendung als Workflows, wobei jede Stufe eines Workflows, die durch den Absender einer Nachricht (Benutzer oder Gerät, das eine Funktion des Vertrags ausgeführt wird) und der Status (die Parameter des Vertrags dargestellt identifiziert dar. als eine Nachricht an eine Funktion und den internen Status). Andere Parteien (in diesem Fall Benutzern oder Geräten) kann durch die Ausführung einer Funktion eines smart Contracts beeinflusst werden.

In diesem Kontext beziehen wir uns für alle Beteiligten als Anwendungsrollen. Erste Anwendungsrolle, die den Vertrag erstellt, wird den Initiator bezeichnet. Bei Änderung des internen Zustands eines Vertrags kann ein Ereignis ausgelöst werden, um diese Änderung auf andere Teile des intelligenten Vertrags oder externen Anwendungen zu signalisieren. Dies ist ein typisches Muster, z. B. für das Auffüllen der off-Chain-Daten, durch die Verwendung eines Servicebus zum Verarbeiten von Ereignissen, die durch einen smart Contract und Veröffentlichen von Nachrichten an die entsprechenden Listener ausgelöst. Abbildung 2 in einem Workflow innerhalb eines smart Contract beteiligten Entitäten identifiziert.

Abbildung 2 Workflowentitäten in einen Smart Contract

Ethereum verwendet Solidity als Programmiersprache für das Schreiben von selbstverstärkende Geschäftslogik für intelligente Verträge. Intelligente Verträge in Solidity ähneln Klassen in objektorientierten Sprachen. Jeder Vertrag enthält Rollen, Status und Funktionen zum Implementieren von Actors, Stufen und Aktionen eines Geschäftsprozesses.

Der Codeausschnitt in Abbildung 3 zeigt die verschiedenen Typen von Variablendeklaration in Solidity für Rollen, Status und Eigenschaften, die in einem intelligenten Vertrag für eine Voraussetzungen-Anwendung verwendet werden können. Rollen (die Gambler und die Bookmaker) werden als Adresse definiert, die der eindeutige Bezeichner eines Benutzers oder der Vertrag in Ethereum ist. Zustand ist eine Enumeration von Bezeichnungen, die den aktuellen Zustand des ein Suchergebnis platziert, über den intelligenten Vertrag identifiziert. Funktionen, wie Sie später sehen werden definieren eine Änderung des Status an. Die Menge Suchergebnis wird als eine Zahl ohne Vorzeichen angegeben (Solidity unterstützt derzeit keine Dezimalwerte).

Abbildung 3-Deklaration von Rollen, Status und Eigenschaften im Voraussetzungen Smart Contract

pragma solidity ^0.4.20;
contract Betting
{
  // Roles
  address public Gambler;
  address public Bookmaker;
  // State
  enum BetType { Placed, Won, Lost }
  BetType public State;
  // Properties
  uint public BetAmount;

Beachten Sie die Angabe der Version von Solidity, die ich für diese smart Contract als Ziel wähle aus. Es ist empfehlenswert, die an diese Pragma-Anweisung, um Inkompatibilitäten mit zukünftigen Versionen der Programmiersprache Solidity und des Compilers zu vermeiden. Dadurch wird auch die alten Code in einen smart Contract, welche möglicherweise durch eine neue Version zur Unterstützung der aktualisierten Code ersetzt werden müssen. Entfernen Sie einen vorhandenen intelligenten Vertrag aus einer Blockchain heißt "Selbstzerstörung."

Ein smart Contract sollten eine einzige Verantwortung und enthalten nur Geschäftslogik wie möglich – optimal nur die Validierungslogik erforderlich, um einen Vertrag gültig halten oder nicht. In meiner Anwendung Voraussetzungen möglicherweise ein smart Contract-Funktionen für ein Risiko platzieren, durch die Gambler, und bestätigen von Gewinn oder Verlust von der Bookmaker verfügbar machen. Währung möglicherweise zwischen den beiden Rollen, als Teil des Workflows Suchergebnis ausgetauscht werden. Das übliche Muster für finanzielle Transaktionen, die Validierung erforderlich, indem ein Vertrag ist sieht die Menge Übertragung geschieht in zwei Phasen, wie angegeben in Abbildung 4. Die Gambler (Initiator des Vertrags) wird ein Suchergebnis für einen bestimmten Zeitraum, die dann im smart Contract gespeichert ist. Wenn das Suchergebnis gewonnen haben, ist, wird die gewonnene Menge, angegeben durch die Bookmaker, auf die Gambler übertragen. Die Bookmaker Cache hingegen die Bet-Menge.

Abbildung 4 überzeugt Workflow

Siehe Abbildung 5, die Implementierung dieses intelligenten Vertrags in Solidity erfordert, dass mehrere Funktionen für jede Aktion des Workflows, die wie folgt definiert werden:

• Der Konstruktor speichert den Absender der Nachricht als die Gambler; Dies ist die Rolle, die am intelligenten Vertrag initiiert.
• Die Bet-Funktion eine Menge als Eingabe akzeptiert, führt eine Prüfung (diese Funktion kann nur durch die Gambler aufgerufen werden, und die Menge muss größer als NULL sein), und klicken Sie dann die Bet-Menge mit dem Vertrag überträgt. Um auf '-Chain-Währung Übertragungen ermöglichen, ist es erforderlich, um eine Funktion als payable zu kennzeichnen.
• Die Abschlüsse im Vergleich-Funktion, nachdem Sie bestätigt haben, dass die aufrufende Instanz die Gambler nicht, die gekauft Menge auf die Gambler überträgt, und schließt die Möglichkeit, wie "Gewonnen."
• Die verloren gehen-Funktion, die von der Bookmaker erneut nur aufgerufen werden kann, überträgt die Menge anfänglich wetten, durch die Gambler verloren, um die Bookmaker und schließt das Suchergebnis als "Lost".
• Schließen Sie die Entscheidung, die Gambler entfernt ist (die Adresse ist festgelegt auf 0 x 0) und die Menge, die auf 0 (null) festgelegt, für eine andere Lösung verwendet werden können.

Abbildung 5-Funktionen im Voraussetzungen Smart Contract

constructor() public {
  Gambler = msg.sender;
}
function Bet(uint amount) public payable {
  require(msg.sender == Gambler, "Only a gambler can place a bet.");
  require(amount > 0, "Amount should be greater than zero.");
  BetAmount = amount;
  address(this).transfer(amount);
  State = BetType.Placed;
}
function Won(uint amount) public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  require(amount > 0, "Amount should be greater than zero.");
  Gambler.transfer(amount);
  Close(BetType.Won);
}
function Lost() public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  Bookmaker = msg.sender;
  Bookmaker.transfer(BetAmount);
  Close(BetType.Lost);
}
function Close(BetType state) internal {
  Gambler = 0x0;
  BetAmount = 0;
  State = state;
}

Obwohl einfach in der Implementierung, identifiziert dieses Szenario ein typisches Muster für die Verwaltung von monetären Ausgaben in einer blockchainanwendung. Andere Szenarien möglicherweise aufweisen, belegbare Dateien, z. B. Dokumente, Kalkulationstabellen, Zertifikate und Bilder zu integrieren. Hauptsächlich zur Einschränkung der Speicher aus mehreren Gründen ist es nicht zum Einfügen von Dateien in einer Blockchain geeignet. Eine gängige Methode ist, führen Sie einen kryptografischen Hash (z. B. SHA-256) für eine Datei, und diesen Hash für einen verteilten Ledger freizugeben. Das externe System wird stattdessen die Datei in einem Speichermechanismus, z.B. Azure Storage oder IPFS beibehalten (ipfs.io).

Den Hash erneut mit denselben Hash-Algorithmus zu einem späteren Zeitpunkt ausführen gibt dasselbe Ergebnis zurück, es sei denn, die persistente Datei geändert wurde, auch wenn nur ein Pixel in einem Bild geändert wird. Dieser Prozess gewährt, für die Machbarkeitsstudie vorhanden ist, die ein Objekt wie eine e-Mail-Adresse, Datei, Dokumente, Telefonanruf oder Video zu einem bestimmten Zeitpunkt vorhanden waren. Es gewährt außerdem Authentizität für die Machbarkeitsstudie – Sie wissen ein digitales Objekts wurde nicht geändert werden, da digitale Hauptbuch unveränderlich und unabhängig, speichert überprüfbare Datensätzen aller Transaktionen. Weitere Informationen zu den Wert der Blockchain Enterprise Content Management, lesen Sie den Beitrag, die ich an veröffentlicht bit.ly/2OC2Ycp.

Event-Sourcing und CQRS

Wie im vorherigen Abschnitt erwähnt, empfehle ich, erstellen intelligente Verträge für nur eine Funktion zuständig. Funktion-orientiertes Design ein wichtiges Verfahren für die Isolierung von intelligenten Verträgen ist, zwar reicht es nicht aus, um sicherzustellen, dass unabhängige kurze. Intelligente Verträge können auf eine common Data Service in der Domäne des Systems, trotz räumlicher Ausführung ausgeführt werden. Z. B. in einer Anwendung möglicherweise ein smart Contract für die Verwaltung von Suchergebnisse und einer für die Verwaltung von sportveranstaltungen auf dem verfügt. Die smart Contracts für die zu diesem Zweck kann ein Sportereignis, erstellen eine Abhängigkeit zwischen den zwei intelligente Verträge (überzeugt kann nicht auftreten, wenn ein Ereignis nicht vorhanden ist) verweisen. Gibt es eine Möglichkeit zum Modellieren von Daten, die Daten, die gemeinsame Nutzung zwischen intelligente Verträge zu vermeiden helfen können?

Beliebige Format und den Speicher (SQL, NoSQL-JSON), die wir nutzen, Modellieren wir in der Regel Datenbanken entsprechend Objekte und Create, Read, Update, Delete (CRUD) Vorgänge. Strukturen zu speichern, statt kann das Modell den Status der Domäne an. wir Ereignisse speichern, die zu den aktuellen Status der in unserem führen. Dieser modellierungsansatz wird aufgerufen, Event-sourcing (bit.ly/2O68nrt).

Event-sourcing geht das Speichern von Fakten. Ein Fakt ist eine wertdarstellung des ein Ereignis auslösen. Wie Leben, wir können nicht zeitlich zurückzugehen und Ändern der Vergangenheit kann – ist nur möglich, etwas in der aktuellen früheren Aktionen ausgleichen. Daten ist unveränderlich. Wir geben also immer einen neuen Befehl oder ein Ereignis zu kompensieren, anstatt Sie zu aktualisieren, den Zustand einer Entität. Dieser Ansatz arbeitet unter der Abkürzung des KREBS – erstellen, abrufen, Anfügen und Burn (bit.ly/2MbpUOb), dies ist genau das, was eine Blockchain ausführen kann: keine Daten aktualisieren oder zu löschen, es nur fügt an der Kette. Löschen eine aus einer Blockchain können verursacht einen Konflikt mit der Unveränderlichkeit, aber Sie assettransfer (vermögensübertragung) beenden, indem Sie "brennen" die Adresse des Empfängers.

Ein unmittelbar Aspekt dieses Ansatzes ist die Leistung. Wenn jeder Wert eine Funktion von Ereignissen ist, können Sie davon ausgehen, dass jeder Zugriff auf den Wert eine neuberechnung des aktuellen Status der Quelle Ereignisse erforderlich wäre. Natürlich wäre, die extrem langsam. In der Event-sourcing, können Sie teure Vorgänge vermeiden, indem Sie eine so genannte parallele Momentaufnahme: eine Projektion des Entitätszustands zu einem bestimmten Zeitpunkt in der Zeit. Beispielsweise im Voraus berechnen Banken Ihr Kontostand am letzten Tag jedes Monats, damit Sie nicht alle soll die Summe müssen und Gutschriften Vorgänge seit der Tag Sie geöffnet haben Ihr Bankkonto, um Ihre derzeitige Kontostand zu erhalten.

Abbildung 6 zeigt die strukturellen Datenmodell für die Anwendung Voraussetzungen. Dies wird manchmal des Snowflake-Modells, bezeichnet, da jede Entität (eine Datenbanktabelle) von einer anderen unterscheidet.

Abbildung 6 strukturelle Datenmodell.

Die strukturellen Datenmodell speichert nur den aktuellen Status des Systems, während der Event-sourcing-Ansatzes einzelne Fakten speichert. In der Event-sourcing, Bundesstaat ist eine Funktion der alle relevanten Fakten, die aufgetreten sind. Nicht nur auf diese erhalten sowie vollständige Überwachung, sondern wir Zustand Projektionen auf einem beliebigen Zeitpunkt in der Vergangenheit erstellen können.

Um dies weiter in Bezug auf Isolierung von Aufgaben mithilfe von Push übertragen, ergänzt Befehl Query Responsibility Segregation (CQRS), Event-sourcing als ein Entwurfsmuster für die datenspeicherung. CQRS fördert die effektive der einzigen Verantwortung und kurze von Microservices und durch Erweiterung, intelligente Verträge. Wird darauf hingewiesen, dass Sie können – und sollten – Aktualisieren von Daten aus Data-Abfragefunktionen in separate Modelle zu trennen.

Verwendung von CQRS kann Zugriff auf Daten in mehreren Kontexten müssen entfernt werden. Ein smart Contract kann besitzen und alle Aktualisierungen der Modellzustand kapseln und Auslösen von Ereignissen bei Änderung dieses Zustands. Durch Abonnieren von Benachrichtigungen zu diesen Ereignissen, kann ein separater smart Contract ein Modell vollständig unabhängig und eine optimierte Abfrage erstellen, die nicht für alle anderen Vertrag oder eines externen Diensts freigegeben werden muss. Weitere Informationen über CQRS von Martin Beitrag unter bit.ly/2Awoz33.

Abbildung 7 beschreibt das Datenmodell, die ich für die Voraussetzungen Anwendung mithilfe des ereignissourcingmusters entwickelt. Dieses einfache Modell setzt eine ähnliche Struktur unabhängig von das Ereignis als behandelt. Es ist nicht notwendig, den aktuellen Zustand des das Suchergebnis, lesen die Abfolge von Ereignissen wissen. Der Ereignisdatenstruktur hängt von dem Ereignis selbst ab. Obwohl eine Sequenz von Status vorhanden ist, wie in den Workflow definiert, ist es irrelevant, aus der Sicht eines Datenmodells. Denken Sie größere: In einem Supply-Chain-Szenario vorhanden sind mehrere Workflows und Ereignisse, mit anderen Entitäten und Attribute. Strukturelle Datenmodells kann komplex und wachsen, während das Ereignis-basierte Modell, Balken ein paar verschiedene Attribute für jedes Ereignis konstant bleibt.

Abbildung 7-Event-Sourcing-Datenmodell

Verteilte Transaktionen

Ein Modell für die freigegebenen Daten ist nicht der einzige Anwendungsfall, der eine enge Kopplung zwischen intelligente Verträge einführen kann. Eine weitere wichtige Bedrohung ist Workflows. Viele der realen Prozesse kann nicht mit einem einzigen atomaren Vorgang dargestellt werden. Mit solchen Workflows ist das Ergebnis nur sinnvoll, wenn alle Schritte ausgeführt werden können. Wenn ein Schritt in der Sequenz fehlschlägt, wird der resultierende Status der relevanten System ungültig. In der Welt RDBMS heißen solche Prozesse "Transaktionen". Datenbanktransaktionen in der Regel lokal innerhalb der Grenzen einer einzelnen Datenbank enthalten sind und basieren auf Sperren für Tabellen vor Updates. Wenn ein Schritt fehlgeschlagen ist, können Sie die Schritte, die bereits vor dem letzten Commit versucht zurücksetzen.

Für verteilte Workflows und zustandslosen Microservices eine herkömmliche transaktionsimplementierung mit Datensperren und Atomarität, Konsistenz, Isolation, Dauerhaftigkeit (ACID) Compliance (en.wikipedia.org/wiki/ACID) ist unpraktisch. Sagas (bit.ly/2AzdKNR) sind langlebige verteilte Transaktionen, die es ermöglichen, Workflows in einer lose verknüpften Umgebung ausgeführt, ohne vermutungen die Zuverlässigkeit der einzelnen Komponenten von komplexen System.

In Sagas jeder Schritt im Workflow der Teil der Arbeit ausführt, registriert einen Rückruf an einer kompensierenden Transaktion in einer Nachricht, die Namen "Verteiler" und übergibt die aktualisierte Nachricht der Vererbungskette Aktivität. Wenn ein Schritt downstream fehlschlägt, diesen Schritt den Verteiler untersucht, und Sie werden im letzten Schritt kompensierende Transaktion durch Zurücksenden der Verteiler aufgerufen. Im vorherige Schritt ist das gleiche, der Aufruf von seinem Vorgänger in der kompensierenden Transaktion und so weiter, bis alle bereits ausgeführte Transaktionen kompensiert werden. Dieses Muster führt zu letztlicher Konsistenz der Daten in einer verteilten Transaktion (bit.ly/2v8T360). Aufgrund seiner Natur hoch fehlertolerantes, verteiltes sind Sagas sehr gut für eine Microservice-Architektur sowie hinsichtlich der Blockchain intelligente Verträge.

Sie können eine Sortierung der Verteiler über die fallback-Funktionen in Solidity implementieren. Eine fallback-Funktion ist eine unbenannte Funktion definiert keine Eingabeargumenten und keinen Wert zurückgibt. Es wird bei einem Aufruf mit dem Vertrag ausgeführt, wenn keiner der anderen Funktionen den Bezeichner für die angegebene Funktion entspricht, oder wenn der Vertrag dieses (im Fall von Ethereum) empfängt. Darüber hinaus muss um dieses zu erhalten, die fallback-Funktion zu zahlenden markiert werden. Wenn keine solche Funktion vorhanden ist, kann nicht der Vertrag dieses über reguläre (Adresse, Adresse) Transaktionen erhalten.

Es ist erwähnenswert, dass ein Vertrag ohne eine zu zahlende fallback-Funktion dieses als Empfänger der Coinbase Transaktion ein, z. B. eine Miner Block Reward empfangen kann. Ein Vertrag kann nicht auf solche Ether-Übertragungen zu reagieren und daher auch nicht möglich abgelehnt werden. Dies ist eine entwurfsentscheidung von Ethereum und Solidity funktioniert nicht, um es herum. Ein Vertrag kann genau eine unbenannte Funktion aufweisen, wie hier gezeigt:

// Fallback function
function() public payable {
  emit AmountTransfered(msg.sender);
}
event AmountTransfered(address sender);

In Ethereum sind fallback-Funktionen für einen smart Contract zu direkten Übertragungen Konto erforderlich. Dies ist, da das Konto übertragene Übertragungen für beide extern gehören Konten (EOAs) und an anderen smart Contracts stellen möglicherweise. Wie EOAs nur direkte Übertragungen akzeptieren kann, ist die einzige Möglichkeit für ein Konto, um den Wert auf ein anderes Konto übertragen, für den ausgeführten Vertrag um einen fallback-Funktion zu implementieren. Dies bedeutet, dass ein Vertrag, der möchte, dass solche Übertragungen für direkten Übertragungen vorbereitet werden müssen, indem Sie einen fallback-Funktion akzeptiert. Ohne diese Funktion die Übertragung fehlschlug, und es ist nicht möglich, für den Vertrag, dieses aus dem anderen Vertrag zu akzeptieren.

Eine bewährte Methode ist keine Logik in der fallback-Funktion. Es ist möglich, Code im Text dieser Funktion einfügen, aber es wird empfohlen, die alles danach sehr kurze, einfache Protokollierung zu vermeiden. Der Grund ist wichtig und eindeutig für intelligente Verträge: Sie möchten nicht diese Funktion fehlschlägt, da er aus Gas ausgeführt wird. Als Faustregel gilt müssen Sie die gerade ausreicht, Gas ein Ereignis auslösen, aber nicht genug zum Schreiben von Daten in den Speicher.

Asynchrones Messaging

Asynchrones messaging, spielt eine wichtige Rolle beim Schutz von Dinge, die in einer microservicearchitektur lose gekoppelt. Wir können z. B. einen nachrichtenbroker verwenden, zum Übermitteln von ereignisbenachrichtigungen asynchron, verhindern von Punkt zu Punkt-Verbindungen, die eine Abhängigkeit auf jeder Endpunktformat für Verfügbarkeit und die Nachricht zu erstellen. Intelligente Verträge mithilfe desselben Tokens, profitieren von der messaging-fähige Integration für eingehende Nachrichten (von außen in der blockchain-Komponente) und (aus der blockchain-Komponente auf externe Anwendungen) ausgehende Kommunikation.

Azure Blockchain Workbench bietet neben einer REST-API, eine nachrichtenbasierte Integration basierend auf ledgerorientierte Ereignisse. Ereignisse werden in ein Azure Event Grid veröffentlicht, und Consumer können Erfassen von Daten oder Aktionen basierend auf diesen Ereignissen. Für Clients, die eine zuverlässige Nachrichtenübermittlung erfordern, liefert Azure Blockchain Workbench Nachrichten an einen Azure Service Bus-Endpunkt auch. Sie können Ereignisse, z. B. auslösen, um Benutzer und Systeme von Transaktionen oder Zustandsänderungen in einen smart Contract zu benachrichtigen. Ereignisbenachrichtigungen können direkt im Code genutzt oder mit Tools wie Logic Apps verwendet werden (bit.ly/2n4EgoP) zum Auslösen des Flows Daten an downstreamsysteme.

Intelligente Verträge stellen häufig einen Business-Workflows, die mit externen Systemen und Geräten integriert dar. Daher müssen Transaktionen in der Lage, für einen verteilten Ledger zu initiieren, die Daten aus einem externen System oder Gerät enthält. Sie sollten auch externen Systemen reagieren auf Ereignisse, die aus smart Contracts für einen verteilten Ledger stammen. Die REST-API- und Messagingintegration bieten die Möglichkeit zum Senden von Transaktionen aus externen Systemen an smart Contracts, die in einer Azure Blockchain Workbench-Anwendung enthalten, und senden ereignisbenachrichtigungen an externe Systeme, die basierend auf Änderungen, die ausgeführt werden in einer Anwendung. Sehen wir uns jetzt das Muster für die einzelnen Typen von Integrationen in Ihre End-to-End-Lösungen:

• Unidirektionale Ereignisübermittlung aus einem smart Contract an einen Ereignisconsumer.
• Unidirektionale Ereignisübermittlung einer Nachricht aus einem externen System an einen smart Contract.

Smart Contract an einen Ereignisconsumer

Im ersten Szenario tritt auf, ein Ereignis innerhalb eines smart Contract; z. B. eine statusänderung oder der Ausführung einer bestimmten Art von Transaktion. Dieses Ereignis wird über ein Event Grid an nachgeschaltete Consumer, und diese Consumer übertragen, und klicken Sie dann entsprechende Maßnahmen ergreifen. Ein Beispiel für dieses Szenario ist, dass beim Auftreten einer Transaktion ein Consumer benachrichtigt wird und Maßnahmen, ergreifen kann wie z. B. die Aufzeichnung der Informationen in einer Datenbank. Dies ist das gleiche Muster, das Azure Blockchain Workbench folgt, um die off-Chain-SQL-Datenbank zu füllen. Ein anderes Beispiel wäre, wenn ein smart Contract in einen bestimmten Zustand wechselt; z. B. wenn ein Vertrag in einen "Out of Compliance" wechselt. Wenn diese Zustandsänderung eintritt, kann er eine Warnung an einen Administrator gesendet werden auslösen. In diesem Fall über den Prozess, der in den Abbildung 8, wobei:

1. Smart Contract geht in einen neuen Zustand und wird ein Ereignis an den Ledger gesendet.
2. Der Ledger empfängt und das Ereignis in Azure Blockchain Workbench bietet.
3. Azure Blockchain Workbench hat Ereignisse vom Ledger abonniert und empfängt das Ereignis.
4. Azure Blockchain Workbench veröffentlicht das Ereignis an Abonnenten im Event Grid.
5. Externe Systemen haben Event Grid abonniert, verarbeiten die Nachricht und ergreifen Sie geeignete Maßnahmen.

Abbildung 8-Weitergabe eines Ereignisses in einen Smart Contract an ein externes System ausgelöst wurden

Externes System an einen Smart Contract

Es gibt auch ein Szenario, das von der entgegengesetzten Richtung verläuft. In diesem Fall wird ein Ereignis generiert, von einem Sensor oder einem externen System und die Daten aus diesem Ereignis an einen smart Contract gesendet werden soll. Ein gängiges Beispiel ist die Übermittlung von Daten aus den Finanzmärkten, z. B. die Preise von rohstoffpreisen, Aktien oder Anleihen, an einen smart Contract. In diesem Fall über den Prozess, der in den Abbildung 9, wobei:

1. Es wird ein Ereignis in einem externen System, das die Erstellung einer Nachricht für Azure Blockchain Workbench auslöst.
2. Das externe System verfügt über Code, um diese Nachricht in einem bekannten Format zu erstellen, und sendet diese direkt an den Service Bus.
3. Azure Blockchain Workbench hat Ereignisse vom Service Bus abonniert und ruft die Nachricht ab.
4. Azure Blockchain Workbench initiiert einen Aufruf des ledgers und Senden von Daten aus dem externen System an einen bestimmten Vertrag.
5. Beim Empfang der Nachricht geht über der Vertrag zu den möglichen Zustand "Neu".

Abbildung 9-Weitergabe der ein Ereignis bereit, mit einem externen System an einen Smart Contract

Die Implementierung einer End-to-End-Lösung für die beiden Integrationsszenario sprengt den Rahmen dieses Artikels aus. Gute Beispiele für die Integration in beide Richtungen finden Sie unter bit.ly/2M8yflL.

Zusammengefasst können ähnliche integrationsmuster in Microservice-Architekturen und Blockchain intelligente Verträge gefunden werden. Die verteilte Struktur von beide Architekturen unterstützt asynchrones messaging und die Verwendung eines nachrichtenbrokers, in Form eines ereignisbusses Raster- oder Dienst zum vermitteln Informationen zwischen Diensten und smart Contracts. Entwurfsmuster wie Event sourcing übereinstimmen, der Unveränderlichkeit ein digitales Hauptbuch und die ereignisgesteuerten Ansatz auf off Kommunikationskette.

Untersuchen die Azure Blockchain Workbench-API

Azure Blockchain Workbench (aka.ms/abcworkbench) ist ein Dienst, der in wenigen Minuten eine digitale blockchainledger (derzeit Ethereum) erstellt. Darüber hinaus werden Ressourcen in Azure gehostet wird, für die schnelle Entwicklung von intelligenten Vertrag, bei gleichzeitiger Minimierung der Bedenken in Bezug auf die zugrunde liegende Infrastruktur, die zum Ausführen von Ethereum oder ähnliche Blockchain-Plattform erforderlich sind.

Wenn Sie mit Azure Blockchain Workbench vertraut sind, sehen Sie sich meine Einführung in die sie in der Juni-Ausgabe des MSDN Magazine (msdn.com/magazine/mt846726). Azure Blockchain Workbench bietet Entwicklern eine REST-API als Gateway für Desktop-, Web- und mobilen Anwendungen mit Blockchain-Anwendungen zu integrieren. Z. B. kann Entwickler die API verwenden, um IoT-Geräten zum Senden von Daten an einen smart Contract zu ermöglichen. Oder die API kann von Power BI zum Erstellen der Visualisierung von Blockchain-Daten verwendet werden. Die-API stellt ein breites Spektrum an Funktionen der Azure Blockchain Workbench in Vorgangsgruppen organisiert werden, gemäß Abbildung A, und kann verwendet werden, um Folgendes zu automatisieren:

• Erstellung und Verwaltung von Workflows in einem Konsortium Blockchain.
• Zuordnung von Benutzern und Organisationen mit einem Konsortium, Blockchain-Anwendung, oder -Anwendungsworkflow.
• Die Ausführung von Transaktionen in einer Blockchain.
• Abrufen von Transaktions- und Vertragsdaten aus einer Blockchain.

 

Gruppe von Vorgängen	Beschreibung
Anwendungen	Verwaltung von blockchainanwendungen von Blockchain Workbench.
Capabilities	Liste der Funktionen, die ein Benutzer in Blockchain Workbench ausführen kann.
Überprüfungen	Entwicklertools verwendet, um Workbench Konfigurations- und Blockchain intelligente Verträge zu überprüfen.
Verbindungen	Verbindung mit der Blockchain-Netzwerke.
Verträge	Smart Contract-Instanzen, einschließlich der Möglichkeit, die Sie Maßnahmen für smart Contracts zu ergreifen.
Graph-Proxy	Stellt eine Proxymethode für die Azure Active Directory Graph-API für Benutzer dar.
Integrität	Der Integritätsstatus der Blockchain Workbench-API.
Ledger	Unterstützt Blockchain-Netzwerke.
Benutzer	Verwaltung von Benutzern in Blockchain Workbench.

Eine Abbildung der Azure Blockchain Workbench REST-API-Vorgang-Gruppen

HTTP-Anforderungen an die REST-API mit Azure Active Directory (Azure AD) geschützt sind. Um eine authentifizierte Anforderung an eine REST-API vornehmen zu können, müssen Clients mit gültigen Anmeldeinformationen authentifiziert werden, bevor Sie die API aufrufen können. Authentifizierung ist Koordinierung zwischen den verschiedenen Akteuren von Azure AD und den Client ein Zugriffstoken als Nachweis der Authentifizierung bietet. Das Token wird dann in den HTTP-Authorization-Header der einzelnen REST-API-Anforderungen gesendet werden. Finden Sie in diesen Beispielen auf GitHub zum Authentifizieren einer Client-Anwendung zu REST-API von Azure Blockchain Workbench auf bit.ly/2vxzlAC.

Dieses GitHub-Repository enthält weitere Beispiele, wie Sie die verschiedenen Dienste für das Auflisten von Anwendungen, Workflows und Verträge in einer Blockchain aufrufen. Obwohl die aktuelle Implementierung von Azure Blockchain Workbench nur Ethereum unterstützt, werden zukünftige Versionen Support, um andere digitale Ledger erweitert. Letztlich bietet die API einen gemeinsamen Zugriff auf jeder beliebigen unterstützten Blockchain-Plattform, die mit einer einzelnen Anwendung Programmierschnittstelle, unabhängig von der Technologie und der Programmiersprache verwendet.

---

Stefano Tempestaist ein Microsoft Regional Director und doppelte MVP für künstliche Intelligenz und Geschäftsanwendungen sowie Kapitel führender Anbieter für die Microsoft Dynamics 365-Community in der Schweiz. Tempesta ist ein Dozent zu Dynamics 365, Blockchain und Machine Learning-Kursen und regelmäßiger Referent bei Konferenzen für internationale IT, einschließlich Microsoft Ignite und Tech Summit. Er gründete Blogchain-Speicherplatz (blogchain.space), ein Blog zur blockchaintechnologien schreibt für MSDN-Magazin und MS Dynamics-Welt und Machine Learning-Experimente in Azure AI-Katalog veröffentlicht (Gallery.Azure.AI).

Unser Dank gilt dem folgenden technischen Experten: Jonathan Waldman

---

Diesen Artikel im MSDN Magazine-Forum diskutieren