Leider hat dieser Begriff kein gutes deutsches Äquivalent. Die „Wikipedia“ schlägt vor, „Multimietverhältnis, Mehrfachmiete“. Manchmal wird auch von „gemeinsamem Besitz“ gesprochen. Diese Begriffe können etwas verwirrend sein, da das Thema im Grunde nichts mit Miete oder Besitz zu tun hat. Es geht dabei um die Architektur von Software und deren Betriebsgestaltung, wobei letzteres nicht weniger wichtig ist.
Wir haben begonnen, unser Verständnis von Multitenancy gleichzeitig mit der Entwicklung unseres Ansatzes zur Cloud (Service-)Modellierung für „1C:Unternehmen“ zu formen. Das war vor einigen Jahren. Seitdem erweitert sich unser Verständnis ständig. Wir entdecken immer neue Aspekte (Vorzüge, Nachteile, Komplexitäten, Besonderheiten usw.) zu diesem Thema.
Manchmal verstehen Entwickler unter Multitenancy ein recht einfaches Konzept: „Damit die Daten mehrerer Organisationen in einer Datenbank gespeichert werden können, muss in alle Tabellen eine Spalte mit der Organisations-ID hinzugefügt und ein Filter darauf gesetzt werden.“ Natürlich haben auch wir unsere Überlegungen zu diesem Thema von diesem Punkt aus gestartet. Aber wir haben schnell erkannt, dass das nur eine Wiese ist (auch diese ist übrigens nicht einfach). Insgesamt handelt es sich dabei um ein „ganzes Land“.
Die grundlegende Idee der Multitenancy lässt sich ungefähr so beschreiben. Eine typische Anwendung ist ein Einfamilienhaus, das für eine Familie ausgelegt ist, die dessen Infrastruktur (Wände, Dach, Wasserversorgung, Heizung usw.) nutzt. Eine Multitenancy-Anwendung hingegen ist ein Mehrfamilienhaus. Dort nutzt jede Familie dieselbe Infrastruktur, aber diese Infrastruktur ist für das gesamte Haus implementiert.
Ist der Ansatz der Multitenancy gut oder schlecht? Darüber gibt es viele unterschiedliche Meinungen. Es scheint, dass es kein „gut oder schlecht“ im Allgemeinen gibt. Man muss die Vor- und Nachteile im Kontext der spezifischen Aufgaben vergleichen, die gelöst werden sollen. Aber das ist ein eigenes Thema...
Im einfachsten Sinne besteht das Ziel der Multitenancy darin, die Kosten für den Betrieb einer Anwendung durch die „Gemeinschaftlichkeit“ der Infrastrukturkosten zu senken. Das ist eine ähnliche Bewegung wie die Senkung der Kosten für eine Anwendung durch die Nutzung einer Standardlösung (eventuell mit Anpassungen), anstatt eine „maßgeschneiderte“ Lösung zu entwickeln. Nur wird im einen Fall die Entwicklung gemeinschaftlich gestaltet und im anderen der Betrieb.
Übrigens, um es zu wiederholen, gibt es hier keinen direkten Bezug zu einer Verkaufsart. Die Multitenancy-Architektur kann durchaus auch in der Unternehmens- oder behördlichen IT-Infrastruktur zur Automatisierung einer großen Zahl ähnlicher Filialen oder Unternehmenszweige eingesetzt werden.
Man kann sagen, dass Multitenancy nicht nur eine Frage der Organisation der Datenspeicherung ist. Es handelt sich um ein Arbeitsmodell der gesamten Anwendung (einschließlich eines wesentlichen Teils ihrer Architektur, des Bereitstellungsmodells und der Organisation des Supports).
Das Schwierigste und Interessanteste an dem Multitenancy-Modell ist unserer Ansicht nach, dass die Essenz der Anwendung "zweigeteilt" wird. Ein Teil der Funktionalität arbeitet mit spezifischen Datenbereichen (Wohnungen) und "interessiert sich nicht" dafür, dass es andere Bewohner in anderen Wohnungen gibt. Ein anderer Teil betrachtet das Gebäude als Ganzes und arbeitet sofort für alle Bewohner. Dabei kann letzterer nicht abstrahieren, denn es handelt sich schließlich um separate Wohnungen, und es muss ein erforderliches Maß an Granularität und Sicherheit gewährleistet werden.
In "1C:Unternehmung" wird das Multitenancy-Modell auf der Ebene mehrerer Technologien umgesetzt. Das sind die Mechanismen der Plattform "1C:Unternehmung", die Mechanismen "» und „", die Mechanismen (Bibliotheken von Standardunterstützungssystemen).
Jedes dieser Elemente trägt zur Schaffung der gemeinsamen Infrastruktur eines Mehrfamilienhauses bei. Warum wird es in mehreren Technologien und nicht in einer, zum Beispiel in der Plattform, umgesetzt? Zunächst einmal, weil wir der Meinung sind, dass es durchaus sinnvoll ist, einige Mechanismen im konkreten Bereitstellungsvariante zu modifizieren. Aber im Allgemeinen ist dies keine einfache Frage, und wir stehen ständig vor der Wahl, auf welcher Ebene der eine oder andere Aspekt von Multitenancy besser umgesetzt werden kann.
Offensichtlich war es notwendig, den Grundteil der Mechanismen in der Plattform umzusetzen. Nun, zum Beispiel die tatsächliche Trennung der Daten. Das, womit man normalerweise das Gespräch über Multitenancy beginnt. Aber letztendlich hat das Multitenancy-Modell einen wesentlichen Teil der Mechanismen der Plattform durchlaufen und erforderte deren Weiterentwicklung, und in einigen Fällen sogar ein erneutes Nachdenken.
Auf der Ebene der Plattform haben wir tatsächlich die grundlegenden Mechanismen implementiert. Diese ermöglichen die Erstellung von Anwendungen, die im Modell der Multitenancy arbeiten. Damit Anwendungen in diesem Modell „leben und arbeiten“, benötigt man ein Managementsystem für deren „Lebenszyklus“. Dafür sind die Technologien 1cFresh und die vereinheitlichte Ebene der Geschäftslogik auf BSP-Ebene verantwortlich. Ebenso wie in einem Mehrfamilienhaus die Infrastruktur den Bewohnern alles Notwendige bietet, liefern die Technologien 1cFresh alles Notwendige für Anwendungen, die im Multitenancy-Modell arbeiten. Damit Anwendungen mit dieser Infrastruktur interagieren können (ohne wesentliche Anpassungen), werden entsprechende „Schnittstellen“ in Form von BSP-Subsystemen integriert.
Aus der Perspektive der Plattformmechanismen ist leicht zu erkennen, dass wir mit zunehmender Erfahrung und der Entwicklung der Cloud-Nutzung von „1C:Unternehmen“ die Zusammensetzung der Mechanismen erweitern, die in diese Architektur einbezogen sind. Ein Beispiel sei genannt. Im Modell der Multitenancy verändert sich die Rollenverteilung der Teilnehmer am Anwendungsmanagement erheblich. Die Rolle (Verantwortungsgrad) derjenigen, die für den Betrieb der Anwendungen verantwortlich sind, gewinnt erheblich an Bedeutung. Sie benötigen leistungsfähigere Kontrollinstrumente für die Anwendungen. Denn die Anwender der Anwendungen (Mieter) vertrauen in erster Linie dem Anbieter, mit dem sie arbeiten. Zu diesem Zweck haben wir in der Version 8.3 einen neuen . Dieser Mechanismus ermöglicht es den Administratoren des Anbieters, die Freiheit der Anwendungsentwickler auf das erforderliche Sicherheitsniveau zu beschränken – im Wesentlichen die Arbeit der Anwendung für jeden Mieter in bestimmten Rahmen einer „Sandbox“ zu isolieren.
Genauso faszinierend ist die Architektur für das Management von Anwendungen, die im Multitenancy-Modus betrieben werden (was in 1cFresh- und BSP-Technologien umgesetzt wird). Hier steigen im Vergleich zu einem normalen Bereitstellungsmodell die Anforderungen an die Automatisierung von Managementprozessen erheblich. Solcher Prozesse gibt es Dutzende: Erstellung neuer Datenbereiche („Wohnungen“), Aktualisierung von Anwendungen, Aktualisierung von Norminformationen, Datensicherung usw. Und natürlich steigen die Anforderungen an die Zuverlässigkeit und Verfügbarkeit. Zum Beispiel haben wir eine Technologie für ein asynchrones Aufrufsystem mit garantierter Zustellung implementiert, um die zuverlässige Interaktion zwischen Anwendungen und den Komponenten des Managementsystems zu gewährleisten.
Ein sehr heikler Punkt ist der Umgang mit den Daten und Prozessen. Einfach erscheint dies (wenn es jemandem so erscheint) nur auf den ersten Blick. Die größte Herausforderung besteht im Gleichgewicht zwischen der Zentralisierung von Daten und Prozessen und der Dezentralisierung. Auf der einen Seite ermöglicht die Zentralisierung die Reduzierung von Kosten (Speicherplatz, Prozessorressourcen, Aufwand für Administratoren …). Auf der anderen Seite schränkt sie die Freiheit der „Mieter“ ein. Dies ist gerade einer der Punkte der „Dualität“ der Anwendung, bei dem der Entwickler gleichzeitig an die Anwendung im engen Sinne (die eine „Wohnung“ bedient) und im weiteren Sinne (die alle „Mieter“ bedient) denken muss.
Ein Beispiel für eine solche „Dilemma“ wäre die normative Referenzinformation. Natürlich ist die Versuchung groß, sie für alle „Mieter“ des Hauses allgemein zu machen. Das ermöglicht es, sie in einer einzigen Instanz zu speichern und sie sofort für alle zu aktualisieren. Doch manchmal benötigt ein Mieter spezifische Anpassungen. Merkwürdigerweise kommt das in der Praxis vor, selbst bei Informationen, die von Regulierungsbehörden (staatlichen Stellen) spezifiziert sind. Es entsteht die schwierige Frage: Soll man diese Informationen allgemein machen oder nicht? Verlockend ist es natürlich, allgemeine Informationen für alle und private für die Interessierten zu schaffen. Doch das führt bereits zu einer recht komplexen Umsetzung. Darauf arbeiten wir …
Ein weiteres Beispiel ist die Gestaltung der Implementierung regelmäßiger Prozesse (die nach einem Zeitplan ausgeführt werden, von einem Verwaltungssystem initiiert werden usw.). Einerseits können sie für jeden Datenbereich separat implementiert werden. Das ist einfacher und bequemer. Andererseits erzeugt eine so feine Granularität eine hohe Last für das System. Um die Last zu reduzieren, müssen gemeinschaftliche Prozesse implementiert werden. Diese erfordern jedoch eine sorgfältigere Ausarbeitung.
Natürlich stellt sich eine sehr wichtige Frage. Wie können Anwendungsentwickler den Betrieb im Multitenancy-Modus sicherstellen? Was müssen sie dafür tun? Natürlich streben wir danach, dass die Belastung durch technologische und infrastrukturelle Fragen größtenteils auf die bereitgestellte Technologie entfällt, während der Anwendungsentwickler sich nur auf die Geschäftslogik konzentriert. Aber wie bei anderen wichtigen Architekturfragen müssen Anwendungsentwickler ein gewisses Verständnis für die Arbeit im Multitenancy-Modell haben und einige Anstrengungen bei der Anwendungsentwicklung erfordern. Warum? Weil es Momente gibt, die die Technologie nicht automatisch unter Berücksichtigung der Semantik der Daten gewährleisten kann. Zum Beispiel die Definition der Grenzen der Informationsgemeinschaft. Aber wir bemühen uns, dass diese Schwierigkeiten gering sind. Es gibt bereits Beispiele für die Implementierung solcher Anwendungen.
Ein wichtiger Aspekt im Kontext der Implementierung von Multitenancy in „1C:Unternehmen“ besteht darin, dass wir ein hybrides Modell schaffen, in dem eine Anwendung sowohl im Multitenancy-Modus als auch im normalen Modus arbeiten kann. Das ist eine ziemlich komplexe Aufgabe und ein Thema für eine gesonderte Diskussion.
Quelle: habr.com
