Перемещение приложения с одним арендатором с очередью в веб-приложение с несколькими арендаторами

Question

Мне нужно переместить веб-приложение с одним арендатором (. net core) в веб-приложение с несколькими арендаторами (около 100 клиентов). Арендаторы собираются совместно использовать одно и то же приложение, но у каждого арендатора будет своя собственная база данных (база данных для арендаторов). Я уже планировал переместить кэш своего незавершенного приложения в общий распределенный кеш, идентифицирующий элементы кеша, добавив префикс (арендатор). -id) к ключам кеша итерации (шаблон с предопределенным владельцем).

Приложение также использует RabitMQ для реализации асинхронных c процессов. На самом деле у меня не так много очередей, только дюжина и несколько обменов, но я полагаю, что в будущем число очередей и обмен будет увеличиваться.

Теперь я запутался из-за лучшего архитектурного шаблона для очередей при перемещении. к мультитенантной архитектуре.

Выбор:

1) Несколько виртуальных хостов (по одному на каждого клиента) с одинаковой топологией, реплицированных на виртуальный хост

2) Один виртуальный домен с одни и те же очереди, обмены, e cc, общие для арендаторов.

Первый вариант представляется более сложным в управлении, так как я хочу синхронизировать топологию для каждого виртуального хоста (предположим, 100 арендаторов означают 100 виртуальных хостов) Второй выбор проще, мне нужно только передать в контексте всех сообщений, отправляемых в очереди, идентификатор арендатора, чтобы потребитель знал, кто является владельцем сообщения и что с ним делать.

Я бы хотел знаю некоторые мнения в основном в отношении второго варианта, так как он кажется мне более доступным.

Answer 1

Второй вариант намного проще в управлении, поскольку является чисто конфигурацией для привлечения новых клиентов (в отличие от создания / управления инфраструктурой). Для дальнейшей экстраполяции вашей жизни было бы намного проще создать единую базу данных и добавить что-то, похожее на «идентификатор клиента», во все ваши таблицы / запросы. Это позволяет сегментировать ваше приложение и сделать новых клиентов столь же простыми, как вставка строки в базу данных (в отличие от создания нового экземпляра базы данных).

Answer 2

Многопользовательская реализация означает, что вы вступаете в многомерный мир. ИМО, очень сложно дать рецепт для мультитенантного приложения, не зная природу бизнеса и его факторы.

Один важный пункт, на который я посмотрю, - это нагрузка , которую собирается каждый арендатор. ввести в приложение. Как правило, вы хотите, чтобы арендаторы с аналогичной нагрузкой разделяли ресурсы. Если у одного нагрузка в 100 раз больше, чем у других, то опыт будет невелик.

В то же время вы хотите иметь возможность сделать небольшой шаг и не можете позволить себе реализацию, основанную на 10 тыс. Арендаторов, и служить только для 100. Однако вы также не хотите выбрасывать свое приложение и писать с нуля, когда количество ваших арендаторов вырастет до 10 тысяч.

Как видите, это не простое решение.

Я всегда думал о своем следующем шаге, когда проектировал для своей текущей потребности. Важно, чтобы ваш дизайн был гибким и расширяемым, по крайней мере, для следующей фазы вашего бизнеса, которую вы видите.

В вашем случае кажется, что вы видите следующий шаг (несколько виртуальных хостов - в основном выделенные ресурсы для арендаторов) но вы знаете, что вам это не нужно на данный момент.

Я предлагаю вам спроектировать на основе нескольких виртуальных хостов, но реализовать на основе одного хоста. Таким образом, если в итоге окажется, что нагрузка одного арендатора убивает других, то по крайней мере вы можете отделить этого арендатора с относительно меньшими усилиями.