Niestety termin ten nie ma dobrego odpowiednika w języku rosyjskim. Wikipedia podaje „wielu najemców, wielokrotnych najemców”. Nazywa się to czasem „własnością wielokrotną”. Terminy te mogą być nieco mylące, ponieważ przedmiot nie jest nieodłącznie związany ani z wynajmem, ani z posiadaniem. Jest to kwestia architektury oprogramowania i organizacji jego działania. A to drugie jest nie mniej ważne.
Zaczęliśmy formułować nasze rozumienie multitenancy w tym samym czasie, gdy zaczęliśmy projektować podejście do chmurowego (usługowego) modelu pracy w 1C:Enterprise. To było kilka lat temu. Od tego czasu nasze zrozumienie stale się poszerza. Stale odkrywamy coraz więcej nowych aspektów tego tematu (zalety, wady, trudności, cechy itp.).
Czasami programiści rozumieją multitenancy jako bardzo prosty temat: „aby dane kilku organizacji mogły być przechowywane w jednej bazie danych, należy dodać do wszystkich tabel kolumnę z identyfikatorem organizacji i ustawić na niej filtr”. Oczywiście od tego momentu rozpoczęliśmy również badanie tego problemu. Szybko jednak zorientowali się, że to tylko jedna polana (swoją drogą też niełatwa). Ogólnie rzecz biorąc, jest to „cały kraj”.
Podstawową ideę wielodostępności można opisać mniej więcej w ten sposób. Typowym zastosowaniem jest domek przeznaczony dla jednej rodziny, która korzysta z jego infrastruktury (ściany, dach, wodociąg, ogrzewanie itp.). Aplikacja wielodostępna to budynek mieszkalny. W nim każda rodzina korzysta z tej samej infrastruktury, ale sama infrastruktura jest realizowana dla całego domu.
Czy podejście wielodostępne jest dobre czy złe? Można znaleźć bardzo różne opinie na ten temat. Wydaje się, że w ogóle nie ma „dobra i zła”. Trzeba porównać zalety i wady w kontekście konkretnych rozwiązywanych zadań. Ale to już osobny temat...
W najprostszym sensie celem wielodostępności jest zmniejszenie kosztów utrzymania aplikacji poprzez „uspołecznienie” kosztów infrastruktury. Jest to ten sam ruch, co redukcja kosztów aplikacji poprzez wykorzystanie rozwiązania produkcyjnego (ewentualnie z dostosowaniem i modyfikacją), zamiast pisania go „na zamówienie”. Tylko w jednym przypadku rozwój jest uspołeczniony, w drugim – wyzysk.
Co więcej, powtarzamy, nie ma bezpośredniego związku ze sposobem sprzedaży. Architekturę wielodostępną można również zastosować w korporacyjnej lub wydziałowej infrastrukturze IT w celu zautomatyzowania dużej liczby podobnych oddziałów i przedsiębiorstw holdingowych.
Można powiedzieć, że multitenancy to nie tylko kwestia organizacji przechowywania danych. Jest to model działania aplikacji jako całości (w tym znacznej części jej architektury, modelu wdrożenia i organizacji utrzymania).
Najtrudniejszą i najbardziej interesującą rzeczą w modelu multitenancy jest to, że istota aplikacji „rozgałęzia się”. Część funkcjonalności współpracuje z określonymi obszarami danych (mieszkaniami) i „nie jest zainteresowana” faktem, że w innych mieszkaniach znajdują się mieszkańcy. A niektórzy postrzegają dom jako całość i pracują dla wszystkich mieszkańców na raz. Jednocześnie ten ostatni nie może ignorować faktu, że są to przecież odrębne mieszkania i należy zadbać o niezbędny poziom szczegółowości i bezpieczeństwa.
W 1C:Enterprise model multitenancy jest realizowany na poziomie kilku technologii. Oto mechanizmy platformy 1C:Enterprise, mechanizmy"A"", mechanizmy (biblioteki standardowych podsystemów).
Każdy z tych elementów przyczynia się do budowy ogólnej infrastruktury apartamentowca. Dlaczego jest to realizowane w kilku technologiach, a nie w jednej, np. na platformie? Przede wszystkim dlatego, że naszym zdaniem niektóre mechanizmy nadają się do modyfikacji pod kątem konkretnej opcji wdrożenia. Ale ogólnie rzecz biorąc, jest to trudne pytanie i ciągle stajemy przed wyborem - na jakim poziomie lepiej wdrożyć ten czy inny aspekt wielodostępności.
Oczywiście podstawową część mechanizmów należało zaimplementować w platformie. Cóż, na przykład faktyczna separacja danych. W tym miejscu ludzie zwykle zaczynają mówić o wielodostępności. Ostatecznie jednak model multitenancy „przebył” znaczną część mechanizmów platformy i wymagał ich dopracowania, a w niektórych przypadkach przemyślenia.
Na poziomie platformy zaimplementowaliśmy dokładnie podstawowe mechanizmy. Umożliwiają tworzenie aplikacji działających w modelu multitenancy. Aby jednak aplikacje mogły „żyć i pracować” w takim modelu, trzeba mieć system zarządzania ich „aktywnościami życiowymi”. Odpowiadają za to technologie 1cFresh i ujednolicona warstwa logiki biznesowej na poziomie BSP. Tak jak w apartamentowcu infrastruktura zapewnia mieszkańcom wszystko, czego potrzebują, tak technologie 1cFresh zapewniają wszystko, czego potrzebują aplikacje działające w modelu multitenancy. I aby aplikacje mogły współdziałać z tą infrastrukturą (bez znaczących modyfikacji), umieszcza się w nich odpowiednie „łączniki” w postaci podsystemów BSP.
Z punktu widzenia mechanizmów platformy łatwo zauważyć, że w miarę zdobywania doświadczenia i rozwijania przypadku użycia chmury „1C:Enterprise” poszerzamy kompozycję mechanizmów zaangażowanych w tę architekturę. Podajmy jeden przykład. W modelu multitenancy role uczestników usług aplikacyjnych zmieniają się znacząco. Znacząco wzrasta rola (poziom odpowiedzialności) osób odpowiedzialnych za obsługę aplikacji. Konieczne stało się posiadanie potężniejszych narzędzi do kontroli aplikacji. Ponieważ użytkownicy aplikacji (rezydenci) ufają przede wszystkim dostawcy, z którym współpracują. W tym celu wdrożyliśmy nowy . Mechanizm ten pozwala administratorom dostawców ograniczyć swobodę twórców aplikacji do wymaganego poziomu bezpieczeństwa – czyli w istocie wyizolować działanie aplikacji dla każdego najemcy w ramach określonego piaskownicy.
Nie mniej interesująca jest architektura zarządzania aplikacjami działającymi w trybie multitenancy (co jest realizowane w technologiach 1cFresh i BSP). Tutaj, w porównaniu do konwencjonalnego modelu wdrożenia, wymagania dotyczące automatyzacji procesów zarządzania są znacznie zwiększone. Takich procesów są dziesiątki: tworzenie nowych obszarów danych („mieszkań”), aktualizacja aplikacji, aktualizacja informacji prawnych, tworzenie kopii zapasowych itp. I oczywiście rosną wymagania dotyczące poziomu niezawodności i dostępności. Na przykład, aby zapewnić niezawodną interakcję pomiędzy aplikacjami i elementami systemu sterowania, wdrożyliśmy technologię asynchronicznego systemu wywołań z gwarantowaną dostawą.
Bardzo subtelnym punktem jest sposób uspołecznienia danych i procesów. Wydaje się to proste (jeśli komuś się tak wydaje) tylko na pierwszy rzut oka. Największym wyzwaniem jest zachowanie równowagi pomiędzy centralizacją danych i procesów a decentralizacją. Z jednej strony centralizacja pozwala na redukcję kosztów (miejsca na dysku, zasobów procesora, wysiłku administratora...). Z drugiej strony ogranicza swobodę „najemców”. To jest właśnie jeden z momentów „rozdwojenia” aplikacji, kiedy deweloper musi jednocześnie myśleć o aplikacji w wąskim znaczeniu (obsługującym jedno „mieszkanie”) i szerokim (obsługującym jednocześnie wszystkich „najemców”). .
Jako przykład takiego „dylematu” można przytoczyć informacje regulacyjne i referencyjne. Oczywiście istnieje wielka pokusa, aby uczynić go wspólnym dla wszystkich „najemców” domu. Dzięki temu możesz przechowywać go w jednym egzemplarzu i aktualizować dla wszystkich jednocześnie. Ale zdarza się, że niektórzy mieszkańcy potrzebują konkretnych zmian. Co dziwne, w praktyce zdarza się to nawet w przypadku informacji określonych przez organy regulacyjne (organy rządowe). Okazuje się, że jest to trudne pytanie: towarzysko czy nie towarzysko? Oczywiście kuszące jest, aby informacje były ogólne dla wszystkich i prywatne dla tych, którzy ich chcą. A to już prowadzi do bardzo trudnego wdrożenia. Ale pracujemy nad tym...
Innym przykładem jest projekt realizacji procesów regularnych (realizowanych zgodnie z harmonogramem, inicjowanych przez system kontroli itp.). Z jednej strony można je wdrożyć dla każdego obszaru danych osobno. To prostsze i wygodniejsze. Ale z drugiej strony tak drobna szczegółowość powoduje duże obciążenie systemu. Aby zmniejszyć obciążenie, musisz wdrożyć procesy uspołecznione. Wymagają jednak dokładniejszych badań.
Oczywiście wiąże się to z bardzo istotnym pytaniem. W jaki sposób twórcy aplikacji mogą zapewnić wielodostępność? Co muszą w tym celu zrobić? Oczywiście dążymy do tego, aby ciężar kwestii technologicznych i infrastrukturalnych w jak największym stopniu spadał na barki dostarczonej technologii, a twórca aplikacji myślał wyłącznie w kategoriach zadań logiki biznesowej. Jednak podobnie jak w przypadku innych ważnych kwestii związanych z architekturą, twórcy aplikacji muszą mieć pewną wiedzę na temat pracy w modelu wielu dzierżawców, a tworzenie aplikacji będzie wymagało pewnego wysiłku. Dlaczego? Ponieważ są punkty, których technologia nie może zapewnić automatycznie bez uwzględnienia semantyki danych. Na przykład ta sama definicja granic socjalizacji informacyjnej. Staramy się jednak, aby te trudności były niewielkie. Istnieją już przykłady realizacji takich aplikacji.
Ważnym punktem w kontekście wdrażania multitenancy w 1C:Enterprise jest to, że tworzymy model hybrydowy, w którym jedna aplikacja może działać zarówno w trybie multitenancy, jak i w trybie normalnym. To bardzo trudne zadanie i temat na osobną dyskusję.
Źródło: www.habr.com