Дизайн мікросервісу з декількома орендарями


13

Ми переносимо монолітну програму на архітектуру мікросервісу. Зважаючи на деякі нормативні вимоги, ми маємо зберігати дані клієнтів з різних країн в окремих (конкретних для країни) базах даних. Тобто американські db для клієнтів США, Великобританія db для клієнтів Великобританії ...

Наступні проекти, які ми розглядаємо, такі:

Варіант 1: Додаток із багатоліковими орендарями із підтримкою багатомісного споживання в сплячому режимі, який можна масштабувати до N кількості разів залежно від попиту (подумайте про стручки кубернетів). Один екземпляр цієї програми зможе підключитися до всіх баз даних.

Варіант 2: Розгорніть 1 екземпляр мікросервісу на базу даних країни. З шлюзом API перед ними маршрутизується трафік

Якби ви розробляли такий тип системи, яким би був ваш вибір?


3
Я думаю, це буде залежати від ваших конкретних функціональних та нефункціональних вимог.
Роберт Харві

Різні бази даних, але той самий екземпляр це читає? Чи це теж не порушує нормативних вимог?
Джиммі Т.

Варіант 1 не надто узгоджується зі стилем архітектури Microservices.
Лаїв

Ви згадуєте про Kebernetes, але незрозуміло, використовуєте ви контейнери чи ні. Якщо ви робите це за допомогою Docker (наприклад), ви просто створите додаток, який підключається до бази даних. Потім при запуску контейнера і вкажіть деталі з'єднання через параметри та / або конфігурацію. Наявність однієї програми, яка підключається до багатьох подібних баз даних, лише створює потенційні проблеми. Це не додає нічого хорошого дизайну.
JimmyJames

Відповіді:


4

Я думаю, що варіант 2 не є поганим, але може не знадобитися. Мікросервіси дозволяють вам вирішувати потреби декількох додатків.

Важливим фактором тут є те, чи є якась різниця між двома схемами, і чи коли-небудь буде в майбутньому.

Зазвичай, я вважаю, що використання інтерфейсів для сховищ непотрібне; однак, можливо, варто докласти зусиль у цьому випадку. Фабрики сховищ будуть для вас важливими.

Моя проблема з варіантом 1 полягає в тому, що він занадто конкретний. Ви повинні мати можливість перейти від описаних вами налаштувань до двох окремих примірників, кожен з яких вказує на свій власний БД. Додаток НЕ повинен дбати про те, звідки він отримує свої дані.

Хоча схема не відрізняється для вашої двох різних баз даних, ви можете мати один репозиторій легко мати справу з обома, не знаючи, що програма знає різницю:

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

Якщо схеми БД коли-небудь стають розрізненими між США та Великобританією, тоді ви розділите функціонал на два абсолютно різних сховища. Це було б просто, адже все, що вам потрібно було зробити, - це змінити свій завод.


1
Я не розумію, навіщо вам потрібна ця фабрика. Чому б просто не перейти на шляху до деталей конфігурації при запуску? За допомогою цього вам потрібно змінювати код щоразу, коли ви хочете додати новий регіон / країну.
JimmyJames

1
Тут питання не стосується користувачів у окремих країнах ... це стосується різних баз даних. що робити, якщо є різні схеми? Чому споживчий клас повинен нести відповідальність за з'ясування, де взяти рядок з'єднання БД?
TheCatWhisperer

Я не знаю, що ти маєш на увазі. Ніщо в коді не повинно бути відповідальним за "з'ясування", де взяти рядок з'єднання. Це конфігурація. Я не бачу, чому це відрізняється від використання конфігурації для баз даних QA проти виробництва. Ви не ставите, якщо твердження в коді для цього, чи не так?
JimmyJames

Це одна програма, що розмовляє з двома базами даних.
TheCatWhisperer

Я думаю, що ви неправильно розумієте проблему: "ми повинні зберігати дані клієнтів з різних країн в окремих (конкретних для країни) базах даних. Немає потреби в одному" екземплярі "програми для спілкування з двома базами даних. Сумніваюсь, що це всього два БД. ОП, ймовірно, означало "наприклад", коли вони набирали "тобто"
JimmyJames

0

Я б пішов з другим варіантом, він дає менше тертя в розробці та розгортанні.

Це дозволить покращити масштабованість та доступність та кращі нульові варіанти розгортання, оскільки ви розповсюджували свою програму на 1 (або принаймні один) екземпляр на регіон, на відміну від принаймні одного для всього світу.

У міру зміни вимог у вас може бути більше конкретної логіки бізнесу та, можливо, зміни даних, я б спробував розділити код і його дані на регіон, а також уникати спільної ділової логіки для конкретного регіону (ви можете в кінцевому підсумку ділитися деяким основним кодом).

Мати сенс?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.