2013-07-27 18 views
10

Używam Symfony od blisko 2 lat, do tej pory każdy projekt, który buduję, jest wdrażany specjalnie dla każdego klienta (tj. Jednego klienta, jednej bazy kodów, jednej bazy danych).SAAS i Multi-tenancy w Symfony2?

Powiedzmy, że mam aplikację do zarządzania projektami, którą chcę wdrożyć dla wielu klientów. Zakładając, że klienci będą iść z tym, co funkcje buduję do systemu, jeśli wdrożyć inny codebase (stąd inna dB) dla każdego klienta, tu są problemy przewiduję:

  1. Pushing poprawek i uaktualnień będzie bolesne. Muszę przesłać go do każdego repozytorium, które wdrożyłem. Nie będzie on dobrze skalowany, jeśli mam 50 klientów korzystających z tej samej aplikacji.

  2. Zarządzanie jest bolesne. Jak mogę zbudować dla siebie system administracyjny, w którym mogę przenieść WSZYSTKIE projekty do jednej tabeli HTML? W końcu każdy klient ma własną bazę danych, prawda? Dla mnie, aby zrobić cokolwiek znaczącego ze wszystkimi zapisami wszystkich moich klientów, potrzebuję sposobu na przeglądanie wszystkich ich baz danych za jednym zamachem, co ... Nie sądzę, żeby Symfony na to pozwalał. (Nie jestem pewien)

  3. Problemy z kontem użytkownika. Jeśli użytkownik pracuje dla wielu firm, wszystkie z nich za pomocą mojej aplikacji do zarządzania projektami, ten użytkownik musi zarejestrować się wiele razy. (Wiem, że to można obejść, jeśli mogę użyć OAuth, ale staram się nie iść tam, jeśli mogę)

Oto rozwiązania myślałem i próbowali do pewnego stopnia.


Rozwiązanie 1

Jedna baza danych i jeden codebase dla wszystkich moich klientów. Projekty będą umieszczane pod jedną tabelą, faktury będą umieszczane pod jedną tabelą, wszystkie oznaczone przez ich własny identyfikator_klienta. Użytkownicy mogą być przypisani do projektów, więc nie ma potrzeby wielokrotnego zapisywania się.

To nie jest trudne do stworzenia. Ale co się stanie, jeśli różni klienci potrzebują różnych kolumn dla swoich faktur? Moja tabela faktur będzie nadal rozwijana (z różnymi polami, których oczekują różni klienci), a każdy wiersz może potencjalnie zawierać wiele pustych pól. Nie wspominając już, moja jednostka Faktura będzie rosnąć w wielkości pliku, a będę musiał zaktualizować schematu bazy danych za każdym razem, gdy nowy dostosowywania wchodzi.


Rozwiązanie 2

jednej bazy danych, gdzie każdy klient ma swój własny prefiks tabeli. Tak więc dla klienta A mogłem używać clientA_projects, clientA_invoices, clientA_configuration itp.

Jest to idealne rozwiązanie, jeśli każdy klient chce dostosować swoje pola. Ale czy to oznacza, że ​​muszę utworzyć nowe jednostki i tworzyć klasy dla każdego nowego klienta, który wchodzi do systemu? Wygląda na to, że dzięki temu rozwiązaniu muszę aktualizować schemat bazy danych z każdym nowym klientem, który otrzymuję.


Obecnie jestem eksperymentuje z bazy danych schematu mniej (Mongo i sofa), mając nadzieję, że bez potrzeby określenia schematu tabeli góry, mogę wdrożyć rozwiązanie 1 bez kłopotów. Ale wciąż eksperymentuję i są sposoby, aby odejść, zanim odważę się wdrożyć gotową do produkcji aplikację, będąc nieznajomym problemami związanymi z mongo i kanapą z Symfony.


To jest miejsce, w którym utknąłem. Będąc samouczącym się programistą, czuję, że mam wiele dziur w mojej wiedzy, które wymagają wypełnienia (w przeciwieństwie do kogoś z tła CS). Nie ma zbyt wielu miejsc w Internecie mówiących o Symfony 2 i multi-tenancy (może szukam czegoś niewłaściwego). Jeśli ktokolwiek może wskazać mi jaśniejszy kierunek, może najlepsze praktyki, przykładowe projekty, naprawdę to doceniam!

Przy okazji planuję to zrobić w najnowszej wersji Symfony (2.3.2 w tej chwili).

Z góry dzięki chłopaki.

+0

@ Lu0-dezhang jest tam jakąkolwiek możliwość podzielenia się swoimi wynikami? Uruchamiam nową aplikację SaaS przy użyciu Symfony3, ale nie mam pojęcia o bazach danych i organizacji projektu Symfony3, a także ... trudnych? – ReynierPM

Odpowiedz

6

Używam również Symfony2 przez podobny czas (od jednego z BETA) i radzę wybrać rozwiązanie # 1. Jeśli korzystasz z usługi SaaS, nie możesz podać kodu klientom z powodów, które napisałeś (głównie problemy z aktualizacjami/aktualizacjami). Cały problem będzie dotyczył zarządzania użytkownikami - który użytkownik ma dostęp do danych, należy do której grupy, firmy i tak dalej. Wszystkie inne rzeczy, jeśli zostaną prawidłowo wykonane, zostaną zakodowane w ten sam sposób, jaki nie ma dla użytkownika. Co należy zrobić z różnymi wymaganiami dla różnych firm? Stwórz takie funkcje configurable. Można zaimplementować to na różnych poziomach:

  • prosta jednostka przyporządkowuje: mają pole attributes w każdej tabeli i zapisać wszystko jako JSON, YAML lub innym dynamicznie structurable treści
  • ogólną konfigurację: mieć jedno miejsce, gdzie podmiot konfiguracja podstawowa jest przechowywana (w środkach, które napisałem powyżej) i pozwala użytkownikom zarządzać nowymi funkcjami, wszystkie zmiany są propagowane do prostych obiektów,
  • zaimplementować coś, co nazywam Entity Parameters Pattern - projektować tabele bazy danych, które zawierałyby typy parametrów, parametr wartości i relacje z innymi jednostkami na różnych poziomach, a następnie wprowadź ogólny konfigurowalny parametr typy, które można zastosować w dowolnym miejscu o zdefiniowanym znaczeniu. Na przykład "preferred_season" będący parametrem typu "choice_string", który zawiera konfigurację "wiosna, lato, jesień, zima" i kiedy jest dołączony do danego obiektu, zawsze wyświetlałby pole z wyborem i zapisuje wybraną wartość w odniesieniu zarówno do jednostki, jak i typu parametru .

Również rozwiązanie nr 1 ma jedną niepokonaną zaletę - może obsłużyć więcej niż jedną firmę, nawet jeśli chcesz podać kod na końcu. Po prostu trzeba ukryć zdolność dodawania kolejnych. :)

To pytanie jest oznakowane Symfony2, ale naprawdę nie powinno. Nie ma znaczenia, z której struktury korzystasz, powinieneś streścić swój projekt aplikacji z kodu, a następnie użyć frameworka jako zwykłego narzędzia do płynnego wykonywania pracy. Chciałbym powiedzieć, że nawet biorąc pod uwagę poprzednie zdanie, jestem absolutnie zakochany w Symfony2. :)

1

Wiem, że jest to starsze pytanie, ale może być przydatne dla innych.

Zgadzam się z @Tomasz i rozwiązaniem # 1 z one database - wszystkich najemców w jednej bazie danych. Największym problemem jest właściwe projektowanie baz danych w celu rozwiązania dalszych problemów związanych z bezpieczeństwem: dostęp do zasobów musi być kontrolowany przez aplikację, aby zapobiec nieautoryzowanemu dostępowi między lokatorami. Z drugiej strony mamy łatwą implementację, ponieważ wdrażamy pojedynczą aplikację z tylko jedną bazą danych.

Nicea artykuł o Symfony2 i przeprowadzce do SaaS modelu http://www.browserlondon.com/blog/2015/01/moving-to-a-saas-model-with-symfony2/

także "lektura obowiązkowa" artykuł o projektowaniu baz danych w SaaS platformie - wzory, które są niezależne od platformy: http://labs.octivi.com/database-design-in-saas-platforms/