Microservices und gespeicherte Prozeduren

Werden gespeicherte Prozeduren in einer Mikrodienstarchitektur als fehlerhaft angesehen?

Hier sind meine Gedanken:

• Die meisten Bücher über Microservices empfehlen eine Datenbank pro Microservice. Gespeicherte Prozeduren arbeiten normalerweise mit einer monolithischen Datenbank.

• Auch in den meisten Büchern zur Mikrodienstarchitektur heißt es, dass sie autonom und lose gekoppelt sein sollten. Durch die Verwendung von gespeicherten Prozeduren, die beispielsweise speziell in Oracle geschrieben wurden, wird der Mikroservice eng mit dieser Technologie verbunden.

• In den meisten Büchern zur Mikrodienstarchitektur (die ich gelesen habe) wird empfohlen, dass Mikrodienstleistungen geschäftsorientiert sein sollten (entworfen unter Verwendung von Domain-Driven Design (DDD)). Durch das Verschieben von Geschäftslogik in gespeicherte Prozeduren in der Datenbank ist dies nicht mehr der Fall.

Irgendwelche Gedanken dazu?

Es gibt nichts, was die Verwendung gespeicherter Prozeduren mit Microservices ausdrücklich verbietet oder dagegen spricht.

Haftungsausschluss: Ich mag keine gespeicherten Prozeduren aus dem POV eines Entwicklers, aber das hat in keiner Weise mit Microservices zu tun.

Gespeicherte Prozeduren arbeiten normalerweise mit einer Monolith-Datenbank.

Ich glaube, Sie erliegen einem logischen Irrtum.

Gespeicherte Prozeduren sind heutzutage rückläufig. Die meisten gespeicherten Prozeduren, die noch verwendet werden, stammen aus einer älteren Codebasis, die noch vorhanden ist. Damals waren auch monolithische Datenbanken viel häufiger als zu Zeiten, als Microservices populär wurden.

Gespeicherte Procs und monolithische Datenbanken kommen beide in alten Codebasen vor, weshalb Sie sie häufiger zusammen sehen. Aber das ist kein Kausalzusammenhang. Sie verwenden keine gespeicherten Prozesse, da Sie eine monololithische Datenbank haben. Sie haben keine monolithische Datenbank, weil Sie gespeicherte Prozesse verwenden.

Die meisten Bücher über Microservices empfehlen eine Datenbank pro Microservice.

Es gibt keinen technischen Grund, warum diese kleineren Datenbanken keine gespeicherten Prozeduren haben können.

Wie ich schon sagte, mag ich keine gespeicherten Procs. Ich finde sie umständlich und widerstandsfähig gegen zukünftige Wartung. Ich denke, dass das Verteilen von Sprocs auf viele kleine Datenbanken die Probleme, die ich bereits nicht mag, weiter verschärft. Das heißt aber nicht, dass es nicht möglich ist.

Auch in den meisten Büchern zur Mikrodienstarchitektur heißt es, dass sie autonom und lose gekoppelt sein sollten. Koppelt den Microservice mithilfe von speziell in Oracle geschriebenen Stored Procedures eng an diese Technologie.

Auf der anderen Seite kann dasselbe Argument für den von Ihrem Microservice verwendeten ORM vorgebracht werden. Nicht jeder ORM unterstützt auch jede Datenbank. Die Kopplung (insbesondere ihre Dichtheit) ist ein relatives Konzept. Es geht darum, so locker wie möglich zu sein.

Sprocs leiden im Allgemeinen unter dichter Kopplung, unabhängig von Mikrodiensten. Ich würde generell von Sprocs abraten, aber nicht besonders, weil Sie Microservices verwenden. Es ist das gleiche Argument wie zuvor: Ich denke nicht, dass Sprocs der richtige Weg sind (im Allgemeinen), aber das könnte nur meine Voreingenommenheit sein, und es hat nichts mit Microservices zu tun.

Die meisten MSA-Bücher (die ich gelesen habe) empfehlen, dass Microservices geschäftsorientiert sein sollten (entwickelt mit Ddd). Durch das Verschieben von Geschäftslogik in gespeicherte Prozeduren in der Datenbank ist dies nicht mehr der Fall.

Das war schon immer mein Hauptproblem bei Sprocs: Geschäftslogik in der Datenbank. Auch wenn es nicht die Absicht ist, endet es irgendwie immer so.

Aber auch hier gibt es diesen Kritikpunkt, unabhängig davon, ob Sie Microservices verwenden oder nicht. Der einzige Grund, warum es so aussieht, ist, dass Microservices Sie zur Modernisierung Ihrer gesamten Architektur drängen und Sprocs in modernen Architekturen nicht mehr so ​​beliebt sind.

Um Software schreiben zu können, müssen Sie eng mit einer Technologie verbunden sein.

Zumindest für die Laufzeitumgebung, die von der Programmiersprache bereitgestellt wird, in der entwickelt wird.

Allgemeiner werden Sie jedoch feststellen, dass Ihr Mikrodienst eng an mehrere Technologien gekoppelt ist:

• Network Service Framework zur Bereitstellung von HTTP / SSL / SOAP-Protokollimplementierungen auf hoher Ebene
• Repository / ORM / DAO-Framework zur Bereitstellung von Persistenz.
• Datenmanipulations-Frameworks zur Bereitstellung von Tools für die Arbeit mit Daten.
• Process / Threading / OS Framework für den Zugriff auf Betriebssystemressourcen wie Multitasking, Dateisystem, Arbeitsspeicher, GPU-Computing, Erweiterungskarten usw.

Und das ist, um einen bloßen Mikrodienst zu leisten.

Gespeicherte Prozeduren

Eine gespeicherte Prozedur ist einfach eine andere Technologie, die Sie verwenden oder nicht verwenden können. Es macht Ihren Code nicht auf magische Weise monolithisch oder mikro.

Was es aber ist:

• Eine andere Technologie. Jede Technologie, die in der Anwendung vorhanden ist, verringert die Wahrscheinlichkeit, dass ein bestimmter Programmierer für diesen Technologiemix kluge Entwurfsentscheidungen lesen, verstehen und treffen kann.
• Eine Sprache, die ein anderes Programmierparadigma verwendet. Es ist viel zu einfach für Nicht-Experten, ihre eigene imperative, funktionale, OO, usw. -Perspektive darauf zu zwingen, was oft zu weniger als hervorragenden Ergebnissen führt.
• Eine API. Welche muss wie jede andere Klasse in der Codebasis gepflegt werden. Dies bedeutet auch, dass die Datenbank eine nicht generische Schnittstelle bereitstellt. Dadurch wird es schwieriger, sowohl das Datenbankmodul selbst zu ersetzen als auch allgemeines Verhalten wie das Zwischenspeichern von Speicher transparent anzuwenden.
• Ein Artefakt. Welche müssen versioniert, getestet und bereitgestellt werden. Dies ist möglich, aber Datenbanken sind lebende Artefakte, die einen anderen Ansatz erfordern. Normalerweise können Sie das Original nicht einfach löschen und ersetzen. Oft ist eine sorgfältige Orchestrierung der Änderungen im Laufe der Zeit erforderlich, um das System in den gewünschten Zustand zu migrieren.

Jedes davon ist ein echter Kostenfaktor. In einigen Fällen sind die Kosten gerechtfertigt, in anderen nicht.

Sie würden fast die gleichen Kosten zahlen, wenn Sie eine Skript-Engine hosten. Die einzige Einschränkung ist, dass Sie das gleiche Programmierparadigma wie die Hostsprache wählen können.

Geschäftslogik

Das Verschieben von Geschäftsregeln in die Datenbank ist keine gute Praxis. Nur nicht wegen gespeicherter Prozeduren.

Es ist eine schlechte Praxis, weil die Datenbank und die Geschäftslogik auf unterschiedlichen Schergraden arbeiten.

• Eine Datenbank in ausgereiften Anwendungen kann jahrzehntelang verwendet werden. In der Regel wird die Engine auf diesen Systemen regelmäßig aktualisiert, die Datenbank selbst wurde jedoch migriert. Es wurde nicht von Anfang an getötet und wieder aufgebaut. Es gibt keinen Grund, warum ein Mikrodienst nicht so langlebig sein kann.

• Vergleichen Sie Jahrzehnte damit, wie schnell sich Geschäftsregeln ändern. Nach meiner Erfahrung ist eine alte Geschäftsregel vielleicht ein paar Jahre alt, die meisten ändern sich jedoch schnell, und man kann nie sagen, welche sich als nächstes ändern wird. Eine neue Anforderung einer Aufsichtsbehörde, ein altes Produkt, das stillgelegt wird, Änderungen am Briefkopf, Änderungen an der Anzahl der Mitarbeiter, die einem Vorgesetzten Bericht erstatten, usw. usw. usw.

Wenn die Geschäftslogik auf die Scherschichten verteilt ist, insbesondere auf eine langsamere und länger anhaltende Schicht, wird ein Widerstand gegen Änderungen erzeugt. Das ist nicht unbedingt eine schlechte Sache. Schließlich ist die einzige Datenbank, die keine Geschäftslogik enthält, ein Triple Store.

Das bloße Angeben eines Tabellenschemas verschiebt die Geschäftslogik in die Datenbank.

Die Architektur

Sie kämpfen mit der Verwendung des geeigneten Werkzeugs für das entsprechende Problem, ohne zu viele Werkzeuge zu benötigen oder es zu schwierig zu machen, um eine Lösung zu finden und aufrechtzuerhalten.

Das ist nicht einfach.

Aber lassen Sie uns das Undenkbare denken, wie würden Sie die auf mehrere Sprachen verteilte Geschäftslogik aufrechterhalten?

• Ein Katalog ... damit jede Geschäftsregelimplementierung nachverfolgt und gepflegt werden kann.
• Tests ..., die für jede Geschäftsregel verwendet werden können, unabhängig davon, wo und wie sie implementiert wurde.
• Eine Referenzimplementierung. Wenn Unstimmigkeiten festgestellt werden, gibt es eine Quelle der Wahrheit (oder zumindest eine Quelle der Debatte).

Das hat aber auch Kosten.

• Ist es besser, zuzulassen, dass die Geschäftsregeln viele Implementierungen haben? Das kann jeder von den Teamfähigkeiten und den Rahmenbedingungen profitieren, benötigt aber strenge Qualitätskontrollen, um viele kleine Unklarheiten abzuwehren?
• Oder ist es besser, eine einzige Quelle der Wahrheit zu haben, die in einer einzigen Sprache geschrieben ist? Günstiger zu implementieren, aber gleichzeitig eine einzige Fehlerquelle, selbst eine monolithische Komponente, die Veränderungen gegenüber verschiedenen Plattformen, Frameworks oder noch zu erfundenen Tools widersteht?

Vorab möchte ich sagen, dass ich tatsächlich einige Mikrodienste unterhalte, die gespeicherte Prozeduren verwenden. Außerdem habe ich an verschiedenen Stellen in meiner Karriere eine Menge gespeicherter Prozeduren geschrieben, und ich stimme definitiv zu, dass Dinge sehr, sehr schief gehen können, wenn sie falsch verwendet werden.

Die kurze Antwort lautet also: Nein, gespeicherte Prozeduren sind in einer Microservice-Architektur von Natur aus nicht schlecht. Aber Sie müssen verstehen:

1. Sie fügen dem Austausch von Speicher-Engines Hindernisse hinzu. Wenn Sie aufgrund einiger Betriebs- oder Leistungsmerkmale oder Funktionseinschränkungen die Speicher-Engines wechseln müssen, sind die Kosten höher, da Sie viel neuen Code schreiben und testen. Das Ausführen von mehr als einer Speicher-Engine (entweder während einer Migrationsphase oder zum Isolieren von Aktivitäten basierend auf den Leistungsanforderungen) kann zu Konsistenzproblemen führen, es sei denn, Sie verwenden 2PC (Two-Phase-Commit), das selbst Leistungsprobleme aufweist.
2. Sie müssen eine weitere API warten, was bedeutet, dass Ihre Abhängigkeiten unterbrochen werden können. Das Hinzufügen, Entfernen oder Ändern von Parametertypen in Prozeduren kann den vorhandenen Code beschädigen. Dasselbe passiert mit Tabellen und Abfragen, aber Ihre Tools sind möglicherweise weniger hilfreich, um festzustellen, wo Probleme auftreten können. Probleme mit gespeicherten Prozeduren treten normalerweise zur Laufzeit auf, und zwar sehr spät im Entwicklungs- / Bereitstellungsprozess.
3. Ihre Datenbankberechtigungen sind jetzt noch komplizierter. Wird eine Prozedur als angemeldeter Benutzer oder als eine andere Rolle ausgeführt? Sie müssen darüber nachdenken und dies verwalten (hoffentlich auf automatisierte Weise).
4. Sie müssen in der Lage sein, sicher auf neue Versionen zu migrieren. Oft muss eine Prozedur gelöscht und neu erstellt werden. Auch hier können Berechtigungen zu Problemen führen.
5. Ein Rollback einer fehlgeschlagenen Migration kann zusätzlichen Aufwand bedeuten. Wenn die Produktionsumgebung von den Entwicklern getrennt ist, wird es noch schwieriger.

Dies sind einige Verwendungen von gespeicherten Prozeduren, von denen ich denke, dass sie oft sinnvoll sind:

1. Durchsetzung des Bearbeitungsverlaufs (Audit-Protokolle). Auslöser werden üblicherweise für diesen Zweck verwendet, und Auslöser sind gespeicherte Prozeduren. In einigen Datenbanken ist es auch möglich, Einfügungen und Aktualisierungen für die Anwendungsrolle vollständig zu verbieten: Clients führen Prozeduren aus, die als andere Rolle mit entsprechenden Berechtigungen ausgeführt werden und das gesamte erforderliche Verhalten erzwingen.
2. Erweiterung der Check-Constraints. Dadurch gelangen Sie möglicherweise in den Bereich der Geschäftslogik. In einigen Fällen reichen die integrierten Einschränkungstools einer Datenbank jedoch möglicherweise nicht aus, um die Anforderungen zu erfüllen. Oft ist der beste Weg, Schecks auszudrücken, der imperative Code, und Sie riskieren, dass falsche Daten eingegeben werden, wenn Sie von Ihrer Anwendung abhängig sind, die dies für Sie erledigt.
3. Kapselung komplexer Abfragen, wenn eine Ansicht unangemessen oder zu kompliziert ist. Ich habe einige Fälle gesehen, in denen eine korrekte Ansicht extrem komplexes SQL erfordert, das in einer gespeicherten Prozedur viel verständlicher ausgedrückt werden kann. Dies ist wahrscheinlich selten, aber es kommt vor.

Im Allgemeinen empfehle ich, dass Sie zuerst Ansichten ausprobieren und nur dann auf Verfahren zurückgreifen, wenn dies erforderlich ist. Gut gestaltete Ansichten können tatsächlich als API fungieren und die Details der Abfrage zugrunde liegender Tabellen abstrahieren. Das Erweitern Ihrer API (Ansichten) mit gespeicherten Prozeduren ist unter bestimmten Umständen sinnvoll. Es ist sogar möglich, JSON direkt von einer SQL-Abfrage aus zu senden und so die gesamte Menge an Zuordnungsdaten aus den Abfrageergebnissen in das Datenmodell Ihrer Anwendung zu übertragen. Ob dies eine gute Idee ist, können Sie anhand Ihrer eigenen Bedürfnisse bestimmen.

Da Sie Ihre Datenbankressourcen (Schema, Berechtigungen usw.) bereits mithilfe eines automatisierten Tools verwalten sollten, sind gespeicherte Prozeduren für Microservices von Natur aus nicht schlecht.

Gespeicherte Prozeduren sind Implementierungsdetails. Datenbankfunktionen, Lambdas oder ein Shell-Skript, die irgendwo im Dateisystem gespeichert sind, sind alle Implementierungsdetails und für die Architektur irrelevant.

Die meisten Bücher über Microservices empfehlen eine Datenbank pro Microservice.

Ok, damit wir die gespeicherten Prozeduren in diesen Datenbanken codieren können.

Auch in den meisten Büchern zur Mikrodienstarchitektur heißt es, dass sie autonom und lose gekoppelt sein sollten

Zwischen Geschäftsfähigkeiten, Entwicklungslebenszyklen, Management, Bereitstellungen, Teamstandorten usw. Nichts mit den Implementierungsdetails zu tun. Microservices lösen kein technisches Problem (im Gegenteil). Sie lösen Probleme mit dem Management und der Time-to-Market. Es ist eine Strategie, keine Taktik. Ein Weg, um schnell mit den geringstmöglichen Kosten zu versagen. Wenn sich eine bestimmte Geschäftsfunktion als wertlos herausstellt, lassen wir sie fallen, ohne andere Funktionen, Bereitstellungen, Projektmanagement, Releases usw. zu beeinträchtigen.

Beachten Sie, dass der "Split" bereits wie ein Entkopplungsmittel wirkt. Angenommen, wir haben zwei Services: A wird von Oracle und B von MongoDB unterstützt. Wenn wir die goldene Regel der Entkopplung nicht brechen, sollte es möglich sein, A + Oracle mit vernachlässigbaren Nebenwirkungen auf B fallen zu lassen.

Koppelt den Microservice mithilfe von speziell in Oracle geschriebenen Stored Procedures eng an diese Technologie.

Dies kann zu einer Lieferantenbindung führen. Oft wird der Verkäufer aus historischen oder vertraglichen Gründen vom Unternehmen dazu verurteilt ¹ . Es ist wichtig zu wissen, wie Sie unseren Code nicht an den Anbieter binden können. Beispielsweise implementieren einige ORMs und Frameworks eine neue Abfragesprache, die die in die Datenbank integrierten Funktionen und Features verbirgt.

Wenn unsere Dienstleistungen klein genug sind, ist die Lieferantenbindung kein Problem mehr, da sie einen kleinen Teil des Ganzen betrifft. Ein kleines Teil, das schnell ausgetauscht (oder isoliert) werden sollte.

Die meisten MSA-Bücher (die ich gelesen habe) empfehlen, dass Microservices geschäftsorientiert sein sollten (mit DDD entworfen).

Es sollte geschäftsorientiert sein und hier das Ding. Nicht alle Unternehmen nutzen DDD. DDD und Microservices überlappen sich in vielen Punkten, sind aber keine Ursache-Wirkung. Es könnte zu einem Microservices-Ökosystem kommen, das sich aus anämischen Diensten zusammensetzt. Oder sie setzen sich aus einer Mischung aus beidem zusammen: Services, die eine komplexe Domäne implementieren, und dummen anämischen Services, die POJOs direkt von der DB bereitstellen. Daran ist nichts auszusetzen.

In Bezug auf Bücher konzentrieren sie sich nur auf die Umsetzung der Strategie. Die Taktiken - wie man das verteilte Computing nutzt - wie man es zum Erfolg führt, aber sie sind (normalerweise) strategieunabhängig. Die Strategien variieren von Unternehmen zu Unternehmen und hängen selten von den Entwicklern ab. Wir müssen also noch extrapolieren und das, was Bücher sagen, an unsere spezifischen Bedürfnisse, Anforderungen und Einschränkungen anpassen. Ziel ist es, die Geschäftsstrategie profitabel und nachhaltig zu gestalten.

Denken Sie immer daran, dass jede Architektur ein Mittel zum Zweck ist. Die Geschäftsregeln. Wir bauen keine Microservices-Ökosysteme für Mode oder für die Liebe zur Kunst.

Es hat eigentlich nichts mit Microservices zu tun.

Gespeicherte Prozeduren können sinnvoll sein, wenn Ihr Service über eine Layer-Architektur im "alten" Stil verfügt, in der die Datenbank die Grundlage des Service mit Datenzugriffs- und Geschäftslogik-Layern bildet. Die Schnittstelle zwischen dem Dienst und der Datenbank in einer solchen Architektur ist sehr spezifisch für die innersten Details des Dienstes. In der Regel gibt es dienstspezifische Adapter für jede Art von unterstützter Datenbank, und die vom Adapter bereitgestellte API ermöglicht die Verwendung gespeicherter Prozeduren in den zugrunde liegenden Layern.

Mit solchen Architekturen gibt es viele Probleme. Vor allem macht es den größten Teil der Logik sehr schwierig, einen Komponententest durchzuführen. Diese Architekturen sind nicht mehr dafür.

Wenn Sie eine neuere "saubere Architektur", "Zwiebelarchitektur" oder ähnliches verwenden, ist die Datenbank eine injizierte Abhängigkeit , die auf den äußeren Ebenen angegeben wird. Da dies in den äußeren Schichten definiert ist, muss die für die Datenbank bereitgestellte Schnittstelle generisch sein . Es kann nicht die innersten Details des Dienstes widerspiegeln, da diese Details vor den äußersten Schichten der Architektur verborgen sein müssen . Das Definieren einer generischen Schnittstelle für gespeicherte Prozeduren, die mit jeder Datenbank oder jedem Komponententest-Harness zusammenarbeiten kann, ist unglaublich schwierig und nicht unbedingt erforderlich. Daher sind gespeicherte Prozeduren in solchen Architekturen häufig nicht praktikabel.

Die Beziehung zu Microservices ist nur, dass Microservices neu und aufsteigend sind - wir machen keine Monolithen mehr - und dass diese neuen Architekturstile auch aufsteigend sind - wir machen keine flachen Schichten mehr.