Leider gibt es für diesen Begriff kein gutes russischsprachiges Analogon. Wikipedia gibt „Multi-Tenant, Mehrfach-Tenant.“ Dies wird manchmal als „Mehrfachbesitz“ bezeichnet. Diese Begriffe können etwas verwirrend sein, da der Gegenstand nicht unbedingt mit Mieten oder Besitzen verbunden ist. Dies ist eine Frage der Softwarearchitektur und der Organisation ihres Betriebs. Und Letzteres ist nicht weniger wichtig.
Wir begannen, unser Verständnis von Mandantenfähigkeit zu formulieren, während wir gleichzeitig damit begannen, einen Ansatz für das Cloud-(Dienst-)Arbeitsmodell in 1C:Enterprise zu entwerfen. Das war vor einigen Jahren. Und seitdem hat sich unser Verständnis kontinuierlich erweitert. Wir entdecken ständig neue Aspekte dieses Themas (Vor- und Nachteile, Schwierigkeiten, Funktionen usw.).
Manchmal verstehen Entwickler Multitenancy als ein sehr einfaches Thema: „Damit die Daten mehrerer Organisationen in einer Datenbank gespeichert werden können, müssen Sie allen Tabellen eine Spalte mit der Organisationskennung hinzufügen und einen Filter darauf festlegen.“ Von diesem Moment an haben wir natürlich auch mit der Beschäftigung mit diesem Thema begonnen. Doch schnell wurde ihnen klar, dass dies nur eine Lichtung war (übrigens auch nicht einfach). Im Allgemeinen handelt es sich um ein „ganzes Land“.
Der Grundgedanke der Multitenancy lässt sich etwa so beschreiben. Eine typische Anwendung ist ein Ferienhaus, das für die Unterbringung einer Familie konzipiert ist und dessen Infrastruktur (Wände, Dach, Wasserversorgung, Heizung usw.) nutzt. Eine Multitenancy-Anwendung ist ein Mehrfamilienhaus. Dabei nutzt jede Familie die gleiche Infrastruktur, die Infrastruktur selbst wird jedoch für das gesamte Haus implementiert.
Ist der Multitenancy-Ansatz gut oder schlecht? Hierzu kann man sehr unterschiedliche Meinungen finden. Es scheint überhaupt kein „Gut oder Böse“ zu geben. Sie müssen die Vor- und Nachteile im Kontext der konkret zu lösenden Aufgaben vergleichen. Aber das ist ein anderes Thema...
Im einfachsten Sinne besteht das Ziel der Mandantenfähigkeit darin, die Kosten für die Wartung einer Anwendung durch „Vergesellschaftung“ der Infrastrukturkosten zu senken. Dies ist derselbe Vorgang wie die Reduzierung der Kosten einer Anwendung durch den Einsatz einer Produktionslösung (möglicherweise mit Anpassung und Modifikation), anstatt sie „auf Bestellung“ zu schreiben. Nur in einem Fall ist die Entwicklung sozialisiert, im anderen Fall die Ausbeutung.
Darüber hinaus besteht, wie wir wiederholen, kein direkter Zusammenhang mit der Verkaufsmethode. Die Multitenancy-Architektur kann auch in einer Unternehmens- oder Abteilungs-IT-Infrastruktur verwendet werden, um eine große Anzahl ähnlicher Zweigstellen und Holdingunternehmen zu automatisieren.
Wir können sagen, dass es bei Multitenancy nicht nur um die Organisation der Datenspeicherung geht. Dabei handelt es sich um ein Modell dafür, wie die Anwendung als Ganzes funktioniert (einschließlich eines wesentlichen Teils ihrer Architektur, ihres Bereitstellungsmodells und ihrer Wartungsorganisation).
Das Schwierigste und Interessanteste am Mandantenfähigkeitsmodell ist unserer Meinung nach, dass sich das Wesen der Anwendung „verzweigt“. Ein Teil der Funktionalität arbeitet mit bestimmten Datenbereichen (Wohnungen) und ist „nicht daran interessiert“, dass sich in anderen Wohnungen Bewohner befinden. Und manche nehmen das Haus als Ganzes wahr und arbeiten für alle Bewohner gleichzeitig. Dabei darf jedoch nicht außer Acht gelassen werden, dass es sich letztlich um getrennte Wohnungen handelt und auf die nötige Granularität und Sicherheit geachtet werden muss.
In 1C:Enterprise ist das Multitenancy-Modell auf der Ebene mehrerer Technologien implementiert. Dies sind die Mechanismen der 1C:Enterprise-Plattform, die Mechanismen von"Und"", Mechanismen (Bibliotheken von Standard-Subsystemen).
Jeder dieser Punkte trägt zum Aufbau der gesamten Infrastruktur eines Mehrfamilienhauses bei. Warum wird dies in mehreren Technologien umgesetzt und nicht in einer, beispielsweise in einer Plattform? Erstens, weil es unserer Meinung nach durchaus angebracht ist, einige der Mechanismen für eine bestimmte Bereitstellungsoption zu modifizieren. Aber im Allgemeinen ist dies eine schwierige Frage, und wir stehen ständig vor der Wahl: Auf welcher Ebene ist es besser, diesen oder jenen Aspekt der Mandantenfähigkeit umzusetzen?
Offensichtlich musste der grundlegende Teil der Mechanismen in der Plattform implementiert werden. Nun, zum Beispiel die eigentliche Datentrennung. Hier fängt man normalerweise an, über Mandantenfähigkeit zu sprechen. Aber am Ende „wanderte“ das Mandantenfähigkeitsmodell durch einen erheblichen Teil der Plattformmechanismen und erforderte deren Verfeinerung und in einigen Fällen ein Umdenken.
Auf Plattformebene haben wir genau die grundlegenden Mechanismen implementiert. Sie ermöglichen Ihnen die Erstellung von Anwendungen, die in einem Mandantenfähigkeitsmodell ausgeführt werden. Damit Anwendungen jedoch in einem solchen Modell „leben und arbeiten“ können, benötigen Sie ein System zur Verwaltung ihrer „Lebensaktivitäten“. Verantwortlich dafür sind 1cFresh-Technologien und ein einheitlicher Business-Logic-Layer auf BSP-Ebene. So wie in einem Mehrfamilienhaus die Infrastruktur den Bewohnern alles bietet, was sie brauchen, so stellen die 1cFresh-Technologien alles bereit, was sie für Anwendungen benötigen, die in einem Mandantenfähigkeitsmodell laufen. Und damit Anwendungen (ohne wesentliche Änderungen) mit dieser Infrastruktur interagieren können, werden in ihnen die entsprechenden „Konnektoren“ in Form von BSP-Subsystemen platziert.
Aus Sicht der Plattformmechanismen ist leicht zu erkennen, dass wir mit zunehmender Erfahrung und Entwicklung des Cloud-Anwendungsfalls „1C:Enterprise“ die Zusammensetzung der an dieser Architektur beteiligten Mechanismen erweitern. Geben wir ein Beispiel. Im Multitenancy-Modell ändern sich die Rollen der Anwendungsdienstteilnehmer erheblich. Die Rolle (Verantwortungsebene) der Verantwortlichen für den Betrieb von Anwendungen nimmt deutlich zu. Sie mussten über leistungsfähigere Anwendungskontrolltools verfügen. Denn Anwendungsnutzer (Bewohner) vertrauen in erster Linie dem Anbieter, mit dem sie zusammenarbeiten. Dazu haben wir ein neues implementiert . Dieser Mechanismus ermöglicht es Anbieteradministratoren, die Freiheit der Anwendungsentwickler auf das erforderliche Sicherheitsniveau zu beschränken – im Wesentlichen, um den Betrieb der Anwendung für jeden Mandanten innerhalb einer bestimmten Sandbox zu isolieren.
Nicht weniger interessant ist die Architektur zur Verwaltung von Anwendungen, die im Multitenancy-Modus betrieben werden (was in den Technologien 1cFresh und BSP implementiert ist). Hier sind im Vergleich zum herkömmlichen Deployment-Modell die Anforderungen an die Automatisierung von Managementprozessen deutlich erhöht. Es gibt Dutzende solcher Prozesse: Erstellen neuer Datenbereiche („Apartments“), Aktualisieren von Anwendungen, Aktualisieren von Regulierungsinformationen, Backups usw. Und natürlich steigen die Anforderungen an das Maß an Zuverlässigkeit und Verfügbarkeit. Um beispielsweise eine zuverlässige Interaktion zwischen Anwendungen und Steuerungssystemkomponenten sicherzustellen, haben wir die asynchrone Aufrufsystemtechnologie mit garantierter Zustellung implementiert.
Ein sehr subtiler Punkt ist die Art und Weise der Sozialisierung von Daten und Prozessen. Es scheint nur auf den ersten Blick einfach (wenn es jemandem so vorkommt). Die größte Herausforderung ist die Balance zwischen Zentralisierung von Daten und Prozessen und Dezentralisierung. Einerseits können Sie durch die Zentralisierung Kosten reduzieren (Speicherplatz, Prozessorressourcen, Administratoraufwand usw.). Andererseits schränkt es die Freiheit der „Mieter“ ein. Dies ist genau einer der Momente der „Aufteilung“ der Anwendung, wenn der Entwickler gleichzeitig über die Anwendung im engeren Sinne (für eine „Wohnung“) und im weiteren Sinne (für alle „Mieter“ gleichzeitig) nachdenken muss. .
Als Beispiel für ein solches „Dilemma“ können Regulierungs- und Referenzinformationen angeführt werden. Natürlich ist die Versuchung groß, es allen „Mietern“ des Hauses gemeinsam zu machen. Dadurch können Sie es in einer Kopie speichern und für alle gleichzeitig aktualisieren. Es kommt jedoch vor, dass einige Bewohner spezifische Veränderungen benötigen. Seltsamerweise geschieht dies in der Praxis sogar für Informationen, die von Regulierungsbehörden (Regierungsbehörden) festgelegt werden. Das stellt sich als schwierige Frage heraus: sozialisieren oder nicht sozialisieren? Es ist natürlich verlockend, die Informationen allgemein für alle und privat für diejenigen zu machen, die sie haben möchten. Und das führt bereits zu einer sehr schwierigen Umsetzung. Aber wir arbeiten daran...
Ein weiteres Beispiel ist die Gestaltung der Umsetzung regelmäßiger Prozesse (nach einem Zeitplan ausgeführt, durch das Steuerungssystem initiiert usw.). Einerseits können sie für jeden Datenbereich separat implementiert werden. Es ist einfacher und bequemer. Andererseits führt eine solch feine Granularität jedoch zu einer großen Belastung des Systems. Um die Belastung zu reduzieren, müssen Sie sozialisierte Prozesse implementieren. Sie erfordern jedoch eine sorgfältigere Untersuchung.
Dies wirft natürlich eine sehr wichtige Frage auf. Wie können Anwendungsentwickler Mandantenfähigkeit sicherstellen? Was müssen sie dafür tun? Natürlich streben wir danach, sicherzustellen, dass die Last der Technologie- und Infrastrukturprobleme so weit wie möglich auf den Schultern der bereitgestellten Technologie liegt und der Anwendungsentwickler nur in Bezug auf Geschäftslogikaufgaben denkt. Aber wie bei anderen wichtigen Architekturproblemen müssen Anwendungsentwickler ein gewisses Verständnis für die Arbeit im Mandantenfähigkeitsmodell haben und bei der Entwicklung von Anwendungen ist ein gewisser Aufwand erforderlich. Warum? Denn es gibt Punkte, die die Technologie nicht automatisch bereitstellen kann, ohne die Semantik der Daten zu berücksichtigen. Zum Beispiel die gleiche Definition der Grenzen der Informationssozialisierung. Aber wir versuchen, diese Schwierigkeiten gering zu halten. Es gibt bereits Beispiele für die Umsetzung solcher Anwendungen.
Ein wichtiger Punkt im Zusammenhang mit der Implementierung von Multitenancy in 1C:Enterprise ist, dass wir ein Hybridmodell erstellen, in dem eine Anwendung sowohl im Mandantenmodus als auch im Normalmodus arbeiten kann. Dies ist eine sehr schwierige Aufgabe und Gegenstand einer gesonderten Diskussion.
Source: habr.com