Wdrażanie wielu dzierżawy dla dojrzałych aplikacji korporacyjnych

Question

Zostałem zlecony w celu utworzenia aplikacji dla wielu dzierżawców. Posiada BLL Java/Glassfish wykorzystujący usługi sieciowe SOAP i backend PostgreSQL. Każdy lokator ma swoją własną bazę danych, więc (w moim przypadku przynajmniej) "multi-tenant" oznacza obsługę wielu baz danych na serwer aplikacji.

Obecny aplikator dla pojedynczego dzierżawcy inicjuje pulę połączeń C3P0 za pomocą ciągu połączenia, który pobiera z pliku konfiguracyjnego. Myślę, że teraz będzie potrzebna jedna pula połączeń na klienta/bazę danych obsługiwaną przez serwer aplikacji.

Po zalogowaniu użytkownika mogę go przypisać do właściwej puli połączeń, sprawdzając jej dzierżawcę. Moim głównym problemem jest to, jak osiągnąć tak daleko - kiedy użytkownik jest po raz pierwszy zalogowany, tabela backendu User jest sprawdzana, a odpowiedni obiekt User jest obsługiwany. Wygląda na to, że będę musiał wiedzieć, z której bazy danych korzystać, używając tylko nazwy użytkownika.

Jedyny przyzwoity pomysł to to, że będzie potrzebna baza danych "config" - scentralizowana baza danych do zarządzania informacjami najemców, takimi jak ciągi połączeń. BLL może wysłać do tej bazy danych wystarczającą ilość informacji, aby zainicjować niezbędne pule połączeń. Ale ponieważ mam tylko nazwę użytkownika do pracy, wydaje mi się, że potrzebowałbym również scentralizowanego wyszukiwania nazwy użytkownika, innymi słowy tabeli UserName z obcym kluczem do tabeli Tenant.

To tutaj mój plan projektowy zaczyna pachnieć, dając mi wątpliwości. Teraz będę miał informacje o użytkowniku w dwóch oddzielnych bazach danych, które powinny być utrzymywane synchronicznie (dodatki użytkownika, aktualizacje i usuwanie). Ponadto nazwy użytkowników będą musiały być globalnie unikatowe, podczas gdy wcześniej musiały być unikalne na jednego dzierżawcę.

Podejrzewam, że wymyślam nowe koło lub że jest co najmniej lepsza architektura. Nigdy wcześniej tego nie robiłem, nie ma nikogo w moim zespole, stąd nasza ignorancja. Niestety, aplikacja w niewielkim stopniu wykorzystuje istniejące technologie (ORM był na przykład zwijany w domu), więc nasza ścieżka może być trudna.

pytam za:

• Krytyka mojego istniejącego planu projektu oraz sugestie dotyczące poprawy lub przerabianiu architekturę.
• Zalecenia dotyczące istniejących technologii, które stanowią rozwiązanie tego problemu. Mam nadzieję na coś, co można łatwo podłączyć pod koniec gry, choć może to być nierealistyczne. Przeczytałem o jspirit, ale znalazłem mało informacji na ten temat - wszelkie opinie na ten temat lub inne struktury będą pomocne.

AKTUALIZACJA: Rozwiązanie zostało pomyślnie wdrożone i wdrożone i przeszło wstępne testy. Dzięki @mikera za pomocny i pomocny odpowiedź!

Answer 1

Kilka szybkich myśli:

• pewno trzeba jakaś forma indeksu zarządzania wspólną użytkownika (w przeciwnym razie nie można skojarzyć logowanie klienta z prawej docelowej instancji bazy danych). Sugerowałbym jednak, aby było to bardzo lekkie i wykorzystywałem je tylko do pierwszego logowania. Twój obiekt użytkownika może nadal być pobrany z bazy danych klienta po ustaleniu, która to baza danych.
• Możesz zrobić klucz podstawowy [identyfikator_klienta, nazwa użytkownika], aby nazwy użytkowników nie musiały być unikalne między klientami.
• Oprócz tej cienkiej warstwy indeksu użytkownika, musiałbym zachować większość informacji o użytkowniku, gdzie znajduje się w bazach danych specyficznych dla klienta. Refaktoryzacja w tej chwili prawdopodobnie będzie zbyt uciążliwa, powinieneś najpierw uruchomić podstawową funkcję wielu dzierżawców.
• Będziesz musiał utrzymać indeks wspólny zsynchronizowany z indywidualnymi bazami danych klienta. Ale nie sądzę, że powinno to być zbyt trudne. Możesz także "przetestować" synchronizację i skorygować błędy za pomocą zadania wsadowego, które może być uruchomione na noc lub przez DBA na żądanie, jeśli coś kiedykolwiek się zsynchronizuje. Będę traktował bazy danych klienta jako wzorzec i użyję go do odbudowania współdzielonego indeksu użytkownika na żądanie.
• biegiem czasu można byłaby kierunku w pełni współdzielonej warstwy zarządzania użytkownikami (a nawet w końcu całkowicie udostępnionego baz klientów, jeśli chcesz. Ale to ocalić dla przyszłych iteracji .....