Zentraler Bus gegen Service Mesh: Wie man einen Mitap in eine Schlacht verwandelt

Als wir feststellten, dass es für uns langweilig sein würde, das nächste Treffen abzuhalten, beschlossen wir, daraus etwas Actionreicheres zu machen. In einem Duell, nämlich in einem Duell zwischen zwei Integrationsansätzen - ESB und Distributed -, deren Ehre von Schwergewichtsexperten verteidigt wurde. In diesem Beitrag werden wir Ihnen erzählen, wie der Kampf verlaufen ist und den Gewinner herausfinden.

Ein paar Worte zum Format

Alexander Trekhlebov , unser Unternehmensarchitekt, sprach für den Zentralbus. Für die Dezentralisierung - Andrey Trushkin, Leiter des Zentrums für Innovation und vielversprechende Technologien der Promsvyazbank. Sie gaben abwechselnd Berichte über ihre Technologien und beantworteten verschiedene Fragen, provokativ und nicht sehr. So war es.

Warum ist ESB cool?

Zunächst sollten Sie es wissen lassen und erzählen, wie alles begann. Viele erinnern sich wahrscheinlich daran, dass in der ersten Phase alles ohne Integration geschah, als jedes System mit jedem anderen System kommunizierte und seine Integrationstests durchführte.

Wenn also eine Person kündigte oder ihm etwas anderes passierte, wusste niemand, wie das alles funktionieren würde. Jeder Computer interagierte mit einem Server. Welches Protokoll, welche Art von Interaktion? Nur die Person, die im System arbeitete, wusste das alles.

Dann kam der Integrationsbus. Es schien nicht nur so, sondern weil die wichtigsten Protokolle und Interaktionsmethoden darauf gesammelt wurden und es möglich war, das System nicht zu zwingen, bestimmte Dinge zu beschreiben. Sie konnte mit ihren internen Algorithmen mit ihnen kommunizieren.



Ferner stellte sich heraus, dass sie meistens über Warteschlangen oder über REST mit dem Bus kommunizieren.

Im Laufe der Zeit verschwand jedoch in vielen Fällen die Notwendigkeit eines Busses und einer REST. Aber es sah aus wie ein Rollback, wichtige Fragen hingen wieder:

• Wie man orchestriert, wenn kein Reifen vorhanden ist. Wo wird das passieren?
  
• Was tun mit Daten- und Protokollformaten?
  

Darüber hinaus ist die Leistung in einem zentralisierten System viel besser als in Distributed. Sie können sich auf die Geschwindigkeit, das Volumen und die Verfügbarkeit verlassen. All dies, weil es sich um ein System handelt, das von einem bestimmten Team gewartet wird.

Wie anfällig ist dieses System? Was passiert, wenn ein Computer gehackt wird?

Es gibt immer Redundanz und Zentralisierung. Falls einer außer Betrieb ist, funktioniert das System.

Wer ist für den Reifen verantwortlich? Ihr Team oder Entwickler von Drittanbietern?

Im internen Team bieten wir operative Dienstleistungen, Zuverlässigkeit und Überwachung. Wenn etwas nicht funktioniert, wissen wir, wo wir suchen müssen. Es gibt eine Frage: "Ist es in solchen Fällen möglich, Anbietern und Teams von Drittanbietern zu vertrauen?" Hier ist eine gute Überwachung erforderlich. Denn die Qualität liegt in jedem Fall in der Verantwortung des internen Teams.



Wenn der Bus wächst, werden die Dienste nicht verbunden. Ändern Sie Dienste mit Releases oder was? Was tun mit Agile?

Hier kommen wir zur Grundfrage. Integration ist keine Anwendung. Früher war es ein Teil, jetzt ist es nicht mehr. Integrationsentwicklung ist keine Anwendungsentwicklung. Es ist die Entwicklung von Integrationsinteraktionen oder die Entwicklung im Rahmen eines separaten Projekts, jedoch nicht speziell einer Anwendung.

Ihre agilen Bedenken sind verständlich. Dieses Modell wird verwendet, wenn wir ein separates System herstellen, das irgendwo an der Seite mit dem Bus verbunden ist. Als ich bei einer anderen Bank arbeitete, gab es ein solches System: einen Monat des Testens, einen Monat der Entwicklung. Dadurch werden alle Integrationsinteraktionen schnell auf dem Bus implementiert. Noch schneller als von Analysten beschrieben, da Entwicklungssysteme sehr ausgefeilt und einfach sind. Und Agilität wird bei der Entwicklung des endgültigen Systems verwendet.

Wie lange sucht das Team nach dem Service, den es benötigt, und wo sucht es danach?

Jeder hat den Traum, dass es eine Weltkarte gibt, auf der alle wichtigen Geschäftsbereiche über die Kontinente verteilt sind. Und es ist sogar teilweise implementiert. Der Analytiker geht dorthin und beginnt intensiv auf den Kontinenten zu wandern. Nach einiger Zeit findet er die Interaktion, die benötigt wird. Wenn alles perfekt passt, benutzt er es einfach. Wenn nicht, beschreibt in TK, welche Ergänzungen er benötigt. Es wäre großartig, eine solche Option zu haben, aber bisher sind weniger bequeme Systeme relevant, die viel mehr Zeit und Mühe erfordern, um mit ihnen zu arbeiten.

Oder ist Service Mesh vielleicht cooler?

Zunächst hat sich in 3-4 Jahren viel verändert. Aber was genau ist passiert? Die gleiche Banalität, die alle Redner regelmäßig wiederholen und an der wir auch nicht vorbeikommen können, ist eingetreten: Die Welt verändert sich.

Die Anforderungen an die Geschwindigkeit des Wandels werden immer größer. Gleichzeitig verschwinden Zuverlässigkeitsanforderungen, Sicherheitsanforderungen nirgendwo und die Lastanforderungen steigen nur. Wie wir sehen können, versuchen alle, Marktanteile zu gewinnen, was zwangsläufig zu einer Erhöhung der Belastung der Unternehmenssysteme und folglich der Integration führt.

In der Tat half der ESB zu einer Zeit sehr cool als Vorlage für die technische Implementierung in Bezug auf die Dezentralisierung von Anwendungen, die Zuordnung von Logik zwischen verschiedenen Anwendungen, ein einheitliches Gerät für die Integration von Anwendungen untereinander. Sagen wir einfach bedingt einheitlich.

Stellen wir uns nun vor, dass es nicht 20 Systeme im Unternehmen gibt - schließlich wird versucht, zu der Architektur überzugehen, die als das Schlagwort „Microservices“ bezeichnet wird. Und was ist ein Microservice? Es gibt viele Definitionen, eine davon wird regelmäßig von Martin Fowler verwendet: Es ist ein Service, den ein Mid-Developer in einem Sprint entwickeln kann. Stellen Sie sich vor, wie viele solcher Dienste in einem großen Unternehmen angeboten werden. Zum Beispiel schätzt Netflix die Anzahl seiner Microservices auf 800-900. In einem Unternehmen, das ein externes Ökosystem für Partner aufbauen möchte, können diese Dienstleistungen im Prinzip mehr als tausend betragen. Aber jeder dieser Dienste hält langfristig einer enormen Belastung stand und sollte sich unabhängig entwickeln.

Was ist mit dem Bus? Wenn der Bus dieser gemeinsame Komplex zwischen ihnen bleibt, stellt sich heraus, dass er zu einem Engpass wird und die Entwicklung von Diensten verzögert. Nicht nur, weil sie auf genau diese Dienste wartet, sondern weil sie sich als eigenständiges Team von Menschen entwickelt, die dieselben Technologien und Fähigkeiten besitzen.

Und jetzt stellen wir uns vor: Mehrere Dutzend Produktteams entwickeln und arbeiten mit uns zusammen. Und jeder von ihnen sieht mehrere Dienste. Und der Bus wird von zwei Teams gefahren. Natürlich werden diese Teams mit hoher Wahrscheinlichkeit nicht in der Lage sein, diese Integration mit dem erforderlichen Maß an Geschwindigkeit und Qualität zu entwickeln.

Es stellt sich die Frage: "Wie können wir die gleiche schnelle Geschwindigkeit sicherstellen, ohne die Zugänglichkeit, Sicherheit usw. zu verlieren?" Die Antwort ist sehr einfach: "Lassen Sie diese Dienste ohne expliziten Vermittler direkt interagieren."

Dann wird die nächste wichtige Frage aufgeworfen: "Wie lernen Dienste voneinander?" Und hier ist die Antwort auch sehr einfach: Sie können ein System entwickeln, mit dem die Dienste selbst über sich selbst berichten würden. Das heißt, in dem Moment, in dem der Dienst entwickelt wird, veröffentlicht er unabhängig Informationen über sich selbst in einer bestimmten Registrierung. Und basierend auf diesen Informationen können alle Dienste mit ihm interagieren.

So entstand das Konzept eines „Netzes von Dienstleistungen“ - wie es ursprünglich als „Dienstleistungsnetz“ bezeichnet wurde . Als eine Art Zwischenstufe der Integration zwischen Diensten, die eine solche Integration wie eine Cloud-Lösung bietet.



Große Unternehmen versuchen nun, die Probleme der Entwicklungsgeschwindigkeit parallel zu lösen - um dafür eine bestimmte allgemeine Lösung zu finden, die verteilt und oft eingebettet ist. In diesem Fall verwendet jeder Dienst einen bestimmten Satz vorgefertigter Bibliotheken, um Informationen bei der Bereitstellung automatisch in einer Registrierung zu veröffentlichen.

Oft stellt sich immer noch die Frage: "Aber was tun mit dem kanonischen Datenmodell, dessen Quelle in der Regel der ESB war, in dessen Implementierung und Wartung so viel Geld und Aufwand investiert wurde?" Immerhin war sie ein Standardmodell. Hier eine Gegenfrage: „Und welche Vorteile hat es uns gebracht? Und war es nicht genau der Punkt, der unsere Entwicklung verzögerte? " Tatsächlich erweitert sich das Modell bei der Entwicklung von Diensten immer mehr. Es wird immer neue Herausforderungen geben.

Um es auf den Punkt zu bringen: Die Kosten für das Hinzufügen neuer Geräte, das Organisieren von Interaktionen usw. sind in der Regel erheblich geringer als die Kosten für die Aktualisierung des kanonischen ESB-Datenmodells .

Auch die dezentrale Integration gewährleistet weitgehend die gleiche hohe Verfügbarkeit. Jeder der Mikrodienste ist unabhängig, auch von anderen Mikrodiensten, hängt jedoch entscheidend von der externen Belastung ab, die auf ihn ausgeübt wird. Parallel zur Integration bereitgestellt kann auch technologisch unabhängig implementiert werden.

Manchmal ist die Verwendung eines ziemlich schweren ESB unter modernen Bedingungen nicht sinnvoll oder verringert die Qualität der Lösung. Die Anwendung von Serverless-Technologien, die Infrastruktur, die sich nicht an die kurzlebigen Anforderungen der zu erstellenden Lösungen anpasst, steht bereits kurz bevor, wird jedoch in der richtigen Form für einen bestimmten Dienst bereitgestellt. Jetzt sieht es nach etwas sehr Fernem aus, aber die Welt verändert sich, wie bereits gesagt, ziemlich schnell.

Viele Softwareanbieter gehen diesen Weg in Bezug auf ihre Integrationslösungen. Es gibt bereits Frameworks, die im Wesentlichen das Konzept des Service Mesh implementieren (derselbe Linkerd oder Istio). Dasselbe passiert bereits beim Hosten einer großen Anzahl von Netzwerk-Proxys und Service-Mesh-Integrationsdiensten. Viel gemeinsam mit Service-Mesh- und Container-Orchestrierungssystemen wie Kubernetes.

Ist es möglich, Distributed basierend auf ESB zu erstellen? Ist es möglich, aus einem System ein anderes zu machen? Und wenn ja, worum geht es bei diesen Streitigkeiten?

Hier kommen Hegel und seine „Verleugnung der Verneinung“ in den Sinn. Wenn sich eine Idee auf einer höheren historischen Ebene wiederholt. Von einem zum anderen zu kommen ist meiner Meinung nach möglich. Eine andere Frage ist, wie wir vorgehen werden. Tatsächlich ähnelt das Konzept der Mikrodienste und ihrer Implementierung in vielerlei Hinsicht dem Konzept der Integration, das ursprünglich war: die Interaktion von Mikrodiensten untereinander, jeweils mit jedem.

Ist es möglich, nach den Grundsätzen des Netzes zur Integration zu gelangen, wenn wir vom ESB ausgehen? Tatsächlich folgt Red Hat, jetzt IBM, bereits demselben Prinzip. Schauen Sie sich nur ihr Verständnis des Konzepts des Integrationsstapels und der flexiblen Integration (Agile Integration) an. Sie bieten eine große Anzahl von Integrations-Proxys, die nicht mit Logik überladen sind. Das Wichtigste ist die Transparenz und das Wissen über die Dienstleistungen, das alle neuen Teilnehmer an der Interaktion benötigen.

Versteht Ihre Bank, dass der ESB sich selbst überlebt hat, wenn er weiterhin erhebliche Budgets in ihn investiert?

Budgetfragen sind ehrlich gesagt ein Geschäftsgeheimnis. Für die verwendeten Ansätze entwickeln wir derzeit eine Parallele von zwei Ansätzen. In der Promsvyazbank gibt es wirklich viele Systeme, die an den Bus gebunden sind. Sie sind weiterhin über den Bus integriert. Wir für unseren Teil verstehen jedoch, dass ESB ein vielversprechender Ansatz ist und es effizienter ist, in verteilte Integrationen zu investieren, ohne einen Bus zu verwenden. Dies ist jetzt unsere strategische Priorität.

Wo ist der Ort für die Geschäftsüberwachung in einem verteilten System?

Bei der dezentralen Integration schließt das Vorhandensein einer großen Anzahl von Diensten das Vorhandensein einer Geschäftsüberwachung nicht aus. All dies kann auf der Ebene der jeweiligen Rahmenbedingungen festgelegt werden. Dementsprechend kann diese Überwachung Informationen in einem bestimmten Speicher zusammenführen, der für Daten verantwortlich ist. Diese Daten werden dort analysiert und ein zusammenfassender Bericht erstellt.

Wie sehen Sie den Plan für den Übergang zur dezentralen Integration?

Der Übergang zur dezentralen Integration ist im Zusammenhang mit dem Übergang zu neuen Architekturprinzipien sinnvoll zu betrachten. Dies ist ein komplexer Übergang, der nicht sofort stattfinden kann. Ja, Sie können versuchen, es im Format eines "Urknalls" zu halten, aber diese Szenariooption birgt ernsthafte Risiken. Logischer ist die Möglichkeit, eine neue Schaltung parallel zur vorhandenen zu erstellen und beim Erstellen (im iterativen Modus) neue Produkte einzuführen. Während sich die neue Architekturkontur entwickelt, können die Produkte aus der aktuellen IT-Landschaft, die den Test der Zeit bestanden haben, dorthin übertragen werden. Ein solcher Weg ist ziemlich lang - er wird auf 4 bis 5 Jahre geschätzt -, aber aufgrund der Iteration ist es möglich, Ergebnisse in der Art des industriellen Betriebs nacheinander zu erhalten.

Wer hat gewonnen?

Nach drei interaktiven Runden mit Präsentationen, Fragen und Antworten versteckte sich das Publikum in Erwartung der Bekanntgabe des Endergebnisses. Sie erkennen wahrscheinlich, dass der Gewinner der PSB-Schlacht Andrey Trushkin und das verteilte System war.

Abschließend bieten wir ein Video an, das dazu beiträgt, die Atmosphäre unseres Kampfes zu spüren: