Get best of the week

"Woher wachsen die Beine" oder was geht der Programmierung voraus?

Hallo alle zusammen! Neulich wird im Rahmen der OTUS-Bildungsplattform ein neuer Kurs gestartet: „Architektur- und Designmuster“ . Im Zusammenhang mit dem Start haben wir eine traditionelle offene Lektion abgehalten . Es wurden die Merkmale einer monolithischen Anwendung, mehrstufiger und serverloser Architekturen untersucht. Wir haben das ereignisgesteuerte System, das serviceorientierte System und die Microservice-Architektur eingehend untersucht.



Der Lehrer ist Matvey Kalinin , ein Spezialist mit mehr als 20 Jahren Programmiererfahrung und Autor des Kurses „Architecture and Design Patterns“.

Ein kleiner Hintergrund


Anfangs lösten die Programme die gestellte Aufgabe wirklich für sich und waren ziemlich isoliert. Aber im Laufe der Zeit wuchsen die Programme und die Leute begannen zu verstehen, dass die aufkommende Komplexität der Funktionen die Geschwindigkeit der Verbesserungen, die Zuverlässigkeit und den Widerstand gegen verschiedene Arten von Komplikationen beeinflusst.

Wenn wir ein oder zwei Programme haben, die gleich sind und sich nicht ändern, ist es nicht schwierig, diese Programme zu schreiben und sicherzustellen, dass sie miteinander interagieren. Aber wenn es immer mehr davon gibt, können Probleme nicht vermieden werden, und es spielt keine Rolle, um welche Art von Softwarepaket es sich handelt.

Heute werden Anwendungen größtenteils verteilt. Sie bestehen aus mehreren Modulen und sind durch Systemmeldungen miteinander verbunden. Das heißt, es wird ein ziemlich großes Konglomerat von Programmen erhalten, die miteinander interagieren. Und damit sie erfolgreich interagieren können, müssen wir Folgendes berücksichtigen:

  • schnelle Antwort;
  • Bandbreite
  • Leistung in Bezug auf eine Ressourceneinheit;
  • Skalierbarkeit;
  • Integrationsfähigkeiten;
  • Merkmale der verwendeten Plattformen;
  • Merkmale bestehender Geschäftsprozesse;
  • und vieles mehr…

Gleichzeitig kann man sich an das folgende Zitat erinnern:

„Der richtige Programmcode erfordert keine hohen Arbeitskosten für die Erstellung und Wartung. Änderungen werden schnell und einfach vorgenommen. Es gibt nur wenige Fehler. Die Arbeitskosten sind minimal, während Funktionalität und Flexibilität maximal sind . “

Robert Cecil Martin

Das heißt, wenn Sie das Programm idealerweise einmal schreiben (wenn es gut geschrieben ist), sind die Verbesserungen minimal. Wie kann man dies erreichen und das eine und das andere verbinden? Um diese Frage zu beantworten, wenden wir uns der Geschichte zu.


?


Wir haben also erkannt, dass wir das Softwareprodukt richtig strukturieren müssen. Aber was ist der Zweck der Softwarearchitektur? Und warum haben wir im Titel dieses Artikels den Ausdruck „Beine wachsen“ verwendet?

Die Sache ist, dass Sie zu Beginn der Programmierung bereits wissen, was Sie erstellen möchten. Zunächst beginnt alles mit einem Geschäftsprozess. Es gibt eine Bestellung und einen Kunden, der (zumindest in Worten) beschreibt, wie sein System funktionieren soll. Und dieses System existiert zunächst nur in der von ihm beschriebenen Form. Dann wird dieser Prozess formalisiert und umrissen, aber dies ist immer noch die halbe Miete, da die weitere Entwicklung beginnt. Und der Entwickler muss diesen Prozess in ein Softwareprodukt umwandeln, das ...

Dann ist es Zeit, sich an ein anderes Zitat zu erinnern:

"Das Ziel der Softwarearchitektur besteht darin, den Arbeitsaufwand für die Erstellung und Wartung eines Systems zu reduzieren."

Robert Cecil Martin


Es sollte nicht überraschen, dass das Ziel durch solche allgemeinen Sätze gebildet wird. Tatsache ist, dass Architektur in abstrakten Ideen lebt. Warum? Weil die Person, die sich mit Softwarearchitektur beschäftigt , die Vision eines Geschäftskunden in eine Vision eines Entwicklers verwandelt . Und wenn wir über den Architekten des Entwicklungsteams und den Enterprise-Architekten sprechen, dann hat jeder ein anderes Ziel, aber beide streben eines an - die Reduzierung der menschlichen Arbeitskosten.

In diesem Zusammenhang ist es interessant, die Werte von Software zu betrachten:

  • Der Code erfüllt die Anforderungen des Geschäftsprozesses.
  • Es besteht die Möglichkeit einer schnellen Verhaltensänderung.

Und hier stellt sich die Frage: Was ist wichtiger, die Funktionsweise des Systems oder die Einfachheit der Änderung ? Um dies zu beantworten, betrachten wir das Programm aus Sicht des Dienstprogramms:

Wenn es ein korrekt funktionierendes Programm gibt, das keine Änderungen zulässt, wird ein solches Programm möglicherweise irrelevant - wenn sich die Anforderungen ändern.

Wenn das Programm nicht richtig funktioniert, aber Änderungen daran vorgenommen werden können, kann es im Rahmen sich ändernder Anforderungen korrekt funktionieren. Dieses Programm bleibt immer nützlich.

Paradigmen (Modelle) der Programmierung


Was ist Ihrer Meinung nach das bekannteste (allererste) Programmiermodell? Natürlich ein Monolith . Es ist hier noch einmal angebracht, für einen Moment auf das Jahr 1968 zurückzukommen und sich an Edsger Dijkstra zu erinnern, der gezeigt hat, dass die unkontrollierte Verwendung von Übergängen (gehe zu Anweisungen) die Struktur des Programms schädigt. Er schlug vor, die Übergänge durch verständlichere if / then / else und do / while / till-Konstrukte zu ersetzen.

Jetzt sind die Anweisungen weniger häufig zu sehen. Aber vorher waren Goto-Anweisungen sehr verbreitet. Im Allgemeinen ist dies eine Form des Bösen, denn wenn Sie den Code sehen, in dem eine goto-Anweisung enthalten ist, haben Sie das Gefühl, dass Sie möglicherweise nicht genau den Punkt finden, an dem er abläuft. Und je mehr, desto komplizierter, das heißt, wir erhalten den Spaghetti-Code. Wir nennen diesen Code jetzt "Spaghetti", wo zum Beispiel 20 verschachtelte ifs und möglicherweise ein goto. Dies ist auch kein sehr klarer Code. Stellen Sie sich vor, Sie haben 10-15 und versuchen zu verstehen, wie der Zyklus funktioniert - das hatte Dijkstra im Sinn.

Spaghetti-Code ist ein schlecht strukturiertes, verwirrendes und schwer verständliches Programm, das viele goto-Anweisungen (insbesondere Sprünge), Ausnahmen und andere Konstrukte enthält, die die Struktur verschlechtern. Im Allgemeinen ein bekanntes und ziemlich verbreitetes Antipattern der Programmierung. Ein solches Programm braucht viel Zeit, um es zu verstehen, zu unterstützen und zu testen.

Strukturelle Programmierung


Es gab Programmiersprachen, sie haben einige Ziele verwirklicht. Bis zu einem gewissen Punkt hatte die Struktur der Programme keinen großen Einfluss auf die Umsetzung. Aber die Programme wuchsen, zwischen ihnen bildeten sich zahlreiche Bindungen. Und irgendwann hielt es eine Person für wichtig, den Algorithmus in eine Struktur zu packen, die leicht zu lesen und zu testen war. Änderungen haben auf der Ebene der Programmstruktur begonnen. Das heißt, nicht nur das Programm selbst musste das Ergebnis erfüllen, sondern auch die Programmstruktur musste ein bestimmtes Kriterium erfüllen.

So sind wir reibungslos auf strukturelle Programmierung umgestiegen . Ihm zufolge wird das Programm ohne Verwendung des goto-Operators erstellt und besteht aus drei grundlegenden Steuerungsstrukturen:

  • Reihenfolge,
  • Verzweigung
  • Zyklus.

Wenn Unterprogramme verwendet werden, wird die Entwicklung selbst Schritt für Schritt von oben nach unten durchgeführt.
Und wieder im Jahr 1966 ... In diesem Jahr stellten Ole-Johan Dahl und Kristen Nyugor fest, dass es in der ALGOL-Sprache möglich ist, den Frame des Funktionsaufrufstapels in den dynamischen Speicher (Heap) zu verschieben, damit lokale Variablen, die in der Funktion deklariert sind, danach gespeichert werden können verlasse es. Infolgedessen wurde die Funktion zum Konstruktor der Klasse, lokale Variablen zu Instanzvariablen und verschachtelte Funktionen zu Methoden. Dies führte zur Entdeckung des Polymorphismus durch die strikte Verwendung von Funktionszeigern.

Objekt orientierte Programmierung


Wie Sie alle wissen, werden Programme in OOP als eine Sammlung von Objekten dargestellt, von denen jedes eine Instanz einer bestimmten Klasse ist, und Klassen bilden eine Vererbungshierarchie.

Grundprinzipien der Strukturierung:

  • Abstraktion;
  • Erbe;
  • Polymorphismus.

Sie können all diese Prinzipien aus einer anderen Perspektive betrachten. Robert Martin entwickelte die Prinzipien von SOLID, die einerseits bestimmen, wie ein Programmierer mit Abstraktionen arbeitet, und andererseits den Prozess des Polymorphismus und der Vererbung bilden.

Imperative Programmierung


Ein zwingendes Programm ähnelt den Befehlen, die ein Computer ausführen muss. Solche Programme zeichnen sich aus durch:

  • Anweisungen sind im Quellcode des Programms geschrieben;
  • Anweisungen müssen nacheinander befolgt werden;
  • Daten, die während der Ausführung vorheriger Anweisungen erhalten wurden, können durch nachfolgende Anweisungen aus dem Speicher gelesen werden;
  • Daten, die durch Ausführen des Befehls erhalten werden, können in den Speicher geschrieben werden.

Auch ein sehr altes Design. Die Hauptmerkmale der imperativen Sprachen:

  • Verwendung benannter Variablen;
  • Verwendung des Zuweisungsoperators;
  • Verwendung zusammengesetzter Ausdrücke;
  • Verwendung von Routinen.

Wir setzen jedoch die „Zeitreise“ fort. Diesmal werden wir 1936 (!) Für einen Moment zurückkehren. Es ist insofern interessant, als die Alonzo-Kirche in diesem Jahr den Lambda-Kalkül (oder λ-Kalkül) erfand , der später, 1958, die Grundlage für die von John McCarthy erfundene LISP-Sprache bildete. Das Grundkonzept des λ-Kalküls ist die Unveränderlichkeit - das heißt die Unmöglichkeit, die Werte von Symbolen zu ändern.

Funktionsprogrammierung


Die funktionale Programmierung umfasst die Berechnung der Ergebnisse von Funktionen aus den Quelldaten und den Ergebnissen anderer Funktionen und impliziert keine explizite Speicherung des Programmstatus.

Tatsächlich bedeutet dies, dass eine funktionale Sprache keine Zuweisungsanweisung hat.

Betrachten wir den Unterschied zwischen imperativen und funktionalen Stilen anhand eines Beispiels:

#  
target = []  #   
for item in source_list:  #     
    trans1 = G(item)  #   G()
    trans2 = F(trans1)  #   F()
    target.append(trans2)  #     
#  
compose2 = lambda A, B: lambda x: A(B(x))
target = map(compose2(F, G), source_list)

Was ist Softwarearchitektur?


Die Softwarearchitektur besteht aus einer Reihe von Entscheidungen über die Organisation eines Softwaresystems.

Es enthält:

  • Auswahl von Strukturelementen und deren Schnittstellen;
  • das Verhalten der ausgewählten Elemente und Schnittstellen, ihre Interaktion;
  • Kombinieren ausgewählter Struktur- und Verhaltenselemente zu größeren Systemen;
  • Baustil, der die gesamte Organisation leitet.

Bitte beachten Sie: Zuerst kamen wir zu dem Schluss, dass goto nicht zu uns passt, dann sahen wir, dass es bestimmte Regeln gibt (Kapselung, Vererbung, Polymorphismus), dann stellten wir fest, dass diese Regeln nicht nur funktionieren, sondern bestimmten Prinzipien entsprechen. Der vierte Punkt ist der architektonische Stil, über den wir später sprechen werden.

Der Hauptzweck der Architektur besteht darin, den Lebenszyklus des Systems zu unterstützen. Durch eine gute Architektur ist das System leicht zu erlernen, leicht zu entwickeln, zu warten und bereitzustellen. Das ultimative Ziel ist es, die Kosten über die Lebensdauer des Systems zu minimieren und die Produktivität des Programmierers und genauer des Entwicklungsteams zu maximieren.

Zuerst sprachen wir darüber, welche Regeln wir zum Schreiben von Programmen benötigen. Neben dem Schreiben von Programmen gibt es aber auch Support, Entwicklung und Bereitstellung. Das heißt, die Architektur erfasst nicht einen bestimmten Programmierbereich, sondern den gesamten Entwicklungszyklus.

Eine gute Architektur sollte bieten:

  1. Eine Vielzahl von Anwendungsfällen und ein effektiver Systembetrieb.
  2. Einfachheit der Systemwartung.
  3. Einfaches Systemdesign.
  4. Einfache Systembereitstellung.

Architekturstile


Monolith


Lassen Sie uns zunächst über den bekannten Monolithen sprechen . Dieser Stil findet sich jedoch immer noch in kleinen Systemen. Monolithische Architektur bedeutet, dass Ihre Anwendung ein großes, verbundenes Modul ist. Alle Komponenten sind so konzipiert, dass sie zusammenarbeiten, Speicher und Ressourcen gemeinsam nutzen. Alle Funktionen oder deren Hauptteil sind in einem Prozess oder Container konzentriert, der in interne Ebenen oder Bibliotheken unterteilt ist.



Vorteile:

  1. Einfach zu implementieren. Sie müssen keine Zeit damit verschwenden, über Interprozesskommunikation nachzudenken.
  2. Es ist einfach, End-to-End-Tests zu entwickeln.
  3. Einfach zu implementieren.
  4. Skalieren Sie mit Loadbalancer einfach über mehrere Instanzen Ihrer Anwendung hinweg.
  5. Leicht zu bedienen.



Aber jetzt hat er mehr Mängel :

  1. Ein starker Zusammenhalt führt zu einer Verstrickung mit der Entwicklung der Anwendung.
  2. Die unabhängige Skalierung von Komponenten führt zu Komplikationen und einem vollständigen erneuten Testen der Funktionalität.
  3. Schwieriger zu verstehen.
  4. Mit zunehmender Komplexität wächst die Entwicklungszeit.
  5. Fehlende Isolierung der Komponenten.

Einerseits ist der Monolith gut, aber sobald Sie anfangen, ihn zu entwickeln, treten Schwierigkeiten auf.

Was ist ein Service?


Jetzt weiß jeder, was ein Service ist. Es kann als sichtbare Ressource definiert werden, die eine sich wiederholende Aufgabe ausführt und durch eine externe Anweisung beschrieben wird.

Moderne Dienste weisen folgende Merkmale auf :

  • Services orientieren sich nicht an IT-Fähigkeiten, sondern an geschäftlichen Anforderungen.
  • Dienste sind autark und werden in Bezug auf Schnittstellen, Operationen, Semantik, dynamische Merkmale, Richtlinien und Eigenschaften des Dienstes beschrieben.
  • Die Wiederverwendung von Diensten erfolgt durch ihre modulare Planung.
  • Servicevereinbarungen werden zwischen Unternehmen, die als Lieferanten und Benutzer bezeichnet werden, geschlossen und haben keinen Einfluss auf die Implementierung der Services selbst.
  • Während des Lebenszyklus werden Dienste gehostet und über Dienstmetadaten, Register und Repositorys sichtbar gemacht.
  • Aggregation: Die Kombination von Geschäftsprozessen und komplexen Anwendungen für ein oder mehrere Unternehmen basiert auf lose gekoppelten Diensten.

Aufgrund der oben genannten Merkmale entstand das Konzept der serviceorientierten Architektur (SOA).

Serviceorientierte Architektur (SOA)


SOA ist ein Architekturstil zum Erstellen einer Unternehmens-IT-Architektur, bei dem die Prinzipien der Serviceorientierung verwendet werden, um eine enge Beziehung zwischen dem Unternehmen und seinen unterstützenden Informationssystemen herzustellen.



SOA hat die folgenden Eigenschaften :

  1. Verbessert die Beziehung zwischen Unternehmensarchitektur und Geschäft.
  2. Ermöglicht das Erstellen komplexer Anwendungen aus einer Reihe integrierter Dienste.
  3. Erstellt flexible Geschäftsprozesse.
  4. Es hängt nicht von einer Reihe von Technologien ab.
  5. Autonom im Sinne einer unabhängigen Entwicklung und Bereitstellung.

Ein SOA- Bereitstellungsmodell besteht aus Business Intelligence und Entwicklung sowie IT Intelligence und Entwicklung. Die Assembly besteht aus Programmierservices und dem Erstellen komplexer Anwendungen. Das Hosting besteht aus Hosting-Anwendungen und Laufzeit-Tools wie Enterprise Service Buses (ESBs). Das Handbuch besteht aus der Unterstützung der Betriebsumgebung, der Überwachung der Leistung von Diensten und der Überwachung der Einhaltung von Dienstrichtlinien.



Microservice-Architektur


Es ist Zeit, über Microservice-Architektur zu sprechen . Darin besteht die Anwendung aus kleinen unabhängigen Dienstanwendungen mit jeweils eigenen Ressourcen. Services interagieren miteinander, um Aufgaben im Zusammenhang mit ihren Geschäftsmöglichkeiten auszuführen. Es gibt mehrere Bereitstellungseinheiten. Jeder Dienst wird unabhängig bereitgestellt.



Vorteile:

  1. Unterstützt die Modularität des gesamten Systems.
  2. Nicht verwandte Dienste können einfacher geändert werden, um verschiedene Anwendungen zu bedienen.
  3. Unterschiedliche Dienste können zu verschiedenen Teams gehören.
  4. Service-Services können im gesamten Unternehmen wiederverwendet werden.
  5. Einfacher zu verstehen und zu testen.
  6. Nicht an die Technologie gebunden, die in anderen Diensten verwendet wird.
  7. Die Isolierung des Dienstes erhöht die allgemeine Zuverlässigkeit aller Funktionen.



Nachteile:

  1. Schwierigkeiten bei der Implementierung der Gesamtfunktionalität (Protokollierung, Zugriffsrechte usw.).
  2. Es ist schwierig, End-to-End-Systemtests durchzuführen.
  3. Härterer Betrieb und Support.
  4. Es wird mehr Ausrüstung benötigt als für einen Monolithen.
  5. Die Unterstützung durch mehrere Teams führt zur Koordination der Interaktion zwischen ihnen.

Es ist erwähnenswert, dass es in dieser Architektur sehr schwierig ist, etwas ohne DevOps zu tun.

Schichtarchitektur


Schichtarchitektur ist das häufigste Architekturmuster. Es wird auch als n-Tier-Architektur bezeichnet, wobei n die Anzahl der Ebenen ist.

Das System ist in Ebenen unterteilt, von denen jede nur mit zwei benachbarten interagiert.

Architektur impliziert keine obligatorische Anzahl von Ebenen - es kann drei, vier, fünf oder mehr geben. Am häufigsten werden dreistufige Systeme verwendet: mit einer Präsentationsebene (Client), einer Logikebene und einer Datenebene.
Die häufigsten Schichten sind :

  • Präsentationsschicht (für die Arbeit mit Benutzern);
  • Anwendungsschicht (Service - Sicherheit, Zugriff);
  • Geschäftslogikschicht (Domänenimplementierung);
  • Datenzugriffsschicht (Darstellung der Schnittstelle zur Datenbank).

Geschlossene Schichten


Das Konzept der Isolation von Ebenen trennt eine Ebene streng von einer anderen: Sie können nur von einer Ebene zur nächsten wechseln und nicht mehrere gleichzeitig durchspringen.



Ebenen öffnen


Das System ermöglicht es Ihnen, über offene Ebenen zu springen und auf die darunter liegenden zu fallen.



MVC


Das Konzept der MVC wurde 1978 beschrieben. Die endgültige Version des MVC-Konzepts wurde erst 1988 in der Zeitschrift Technology Object veröffentlicht.

Das Hauptziel ist es, die Geschäftslogik (Modell) von ihrer Visualisierung (Präsentation, Ansicht) zu trennen. Was gibt es:

  • Die Möglichkeit der Wiederverwendung von Code ist erhöht.
  • Der Benutzer kann dieselben Daten gleichzeitig in verschiedenen Kontexten sehen.



Das Modell liefert Daten, reagiert auf Steuerungsbefehle und ändert seinen Status. Die Ansicht ist dafür verantwortlich, dem Benutzer Modelldaten anzuzeigen und auf Modelländerungen zu reagieren. Der Controller interpretiert Benutzeraktionen und benachrichtigt das Modell über die Notwendigkeit von Änderungen.



Ereignisgesteuerte Architektur


Eine weitere interessante Architektur. Es wird bei der Entwicklung und Implementierung von Systemen verwendet, die Ereignisse zwischen lose gekoppelten Softwareelementen übertragen.

Besteht aus unterschiedlichen Einzelzweck-Ereignisverarbeitungskomponenten, die Ereignisse asynchron empfangen und verarbeiten.

Die Vorlage besteht aus zwei Haupttopologien - einem Vermittler und einem Makler.

Reseller-Topologie


Es gibt Prozesse, bei denen die Kontrolle über die Abfolge der Schritte erforderlich ist. Hier sind wir nützliche Vermittler.

Die Haupttypen von Architekturkomponenten:

  • Ereigniswarteschlangen;
  • Vermittler von Ereignissen;
  • Kanäle von Ereignissen;
  • Event-Handler.

Ereignis Ein

Ereignis kann als „signifikante Zustandsänderung“ definiert werden. Eine Veranstaltung kann aus zwei Teilen bestehen:

  • Header (Ereignisname, Zeitstempel für das Ereignis und Art des Ereignisses);
  • Körper (beschreibt, was tatsächlich passiert ist).

Mediator-Topologie

Der Client sendet ein Ereignis an die Ereigniswarteschlange, mit der das Ereignis an den Mediator gesendet wird.

Der Mediator empfängt das Anfangsereignis und sendet für jeden Schritt des Prozesses zusätzliche asynchrone Ereignisse an die Ereigniskanäle.

Ereignisprozessoren, die Ereigniskanäle abhören, empfangen ein Ereignis von einem Vermittler und führen bestimmte Geschäftslogiken aus, indem sie das Ereignis verarbeiten.



Brokertopologie

Die Topologie des Brokers unterscheidet sich von der Zwischentopologie darin, dass es keinen zentralen Ereignismediator gibt. Der Nachrichtenfluss wird über einen kompakten Nachrichtenbroker (z. B. ActiveMQ, HornetQ usw.) auf die Ereignisprozessorkomponenten in einer Kette verteilt. Diese Topologie ist nützlich, wenn die Ereignisverarbeitung relativ einfach abläuft und keine zentralisierte Ereignis-Orchestrierung erforderlich ist.

Jede Komponente eines Ereignisprozessors ist dafür verantwortlich, ein Ereignis zu verarbeiten und ein neues Ereignis zu veröffentlichen, das die gerade abgeschlossene Aktion angibt.



Wenn die erste Situation „irgendwo unten“ asynchron war, dann ist die zweite Situation vollständig asynchron, könnte man sagen. Ein Ereignis generiert mehrere Ereignisse, die sich erhöhen und erhöhen können.

Vorteile ereignisgesteuerte Architektur:

  • Die Komponenten sind isoliert und ermöglichen die Fertigstellung der einzelnen Komponenten, ohne den Rest des Systems zu beeinträchtigen.
  • einfache Bereitstellung;
  • Hochleistung. Ermöglicht parallele asynchrone Operationen;
  • skaliert gut.

Nachteile:

  • schwer zu testen;
  • aufgrund ausgeprägter Asynchronität schwer zu entwickeln.

Serverlose Architektur


Auf diese Weise können Anwendungen und Dienste erstellt und ausgeführt werden, ohne dass ein Infrastrukturmanagement erforderlich ist. Die Anwendung wird weiterhin auf den Servern ausgeführt, die Plattform übernimmt jedoch die vollständige Kontrolle über diese Server.

Die gesamte Infrastruktur wird von Drittanbietern unterstützt, und die erforderlichen Funktionen werden in Form von Diensten angeboten, die für Authentifizierungsprozesse, Nachrichtenübermittlung usw. verantwortlich sind.

Die folgende Terminologie wird unterschieden:

  1. (Function-as-a-Service) — , .
  2. (Backend as a Service) — , - API, . , , , .

Wenn wir die Architektur von "Client-Server" berücksichtigen, wird der größte Teil der Logik im System (Authentifizierung, Seitennavigation, Suche, Transaktionen) von der Serveranwendung implementiert.



In der Architektur ohne Server ist alles etwas anders. Die Authentifizierung wird durch einen BaaS-Dienst eines Drittanbieters (fertiger Cloud-Dienst) ersetzt. Der Zugriff auf die Datenbank wird auch durch einen anderen BaaS-Dienst ersetzt. Die Anwendungslogik befindet sich teilweise bereits im Client, z. B. zum Verfolgen der Sitzung eines Benutzers.

Der Client ist bereits auf dem Weg, eine einseitige Anwendung zu werden. Die Suche kann über den Suchdienst erfolgen (FaaS - Funktion als Dienst). Die Kauffunktion ist auch als separater Service (FaaS) vom Kunden isoliert.



Nun, das ist alles, wenn Sie an den Details interessiert sind, schauen Sie sich das gesamte Video an. Wie für den neuen Kurs, können Sie sich mit dem Programm vertraut machen hier.

More articles:


All Articles