Я не совсем уверен, что все правильно понял, но из того, что я понял, я могу указать на следующие ключевые моменты, касающиеся требований к вашей системе:
- Вы имеете дело с большим количеством данных, иданные будут быстро расти
- Большая часть трафика поступает из системы электронной почты
- У вас есть мультиклиентская система
- У вас есть агент, который может просматривать данные от нескольких клиентов.Вопрос в том, может ли этот агент манипулировать (создавать, обновлять, удалять) данными нескольких клиентов?Это довольно важный момент для будущих ограничений архитектуры или нет.Я предполагаю, что он может читать данные только от нескольких клиентов.
Ваши 2 предложения:
Я бы не рекомендовал это какподход, так как многие другие проблемы могут возникнуть по мере роста базы данных.Например, вы будете вынуждены добавлять индексы для ускорения запросов к вашей базе данных, что поможет вначале, но позже это выследит вас, особенно если вам нужно добавить много некластеризованных индексов.Вы могли бы сделать это немного лучше, используя реплики только для чтения, но даже с этим у вас в какой-то момент возникнут проблемы.Проблема все еще останется в вашей 1 основной базе данных, которая будет расти.
Цитата:
отдельное приложение, состоящее из двух частей, одна дляИТ-агенты и еще один для клиентов.Идея состоит в том, чтобы разделить приложение на две части: один централизованный интерфейс и серверная часть для ИТ-агентов, а другой - для клиентов.Для каждого клиента мы создали бы отдельную базу данных вместе с копией проекта PHP (синхронизацию кода легко автоматизировать).Несколько клиентских экземпляров могут быть размещены на одном или нескольких серверах.Они будут общаться через API.Например: ИТ-агент открывает информационную панель и отображается список ожидающих заявок.Если этот агент работает с 10 крупными клиентами, бэкэнд должен будет связаться с 10 экземплярами через API и запросить выдающиеся билеты.Мы можем гарантировать, что будет отображаться только определенное количество запросов ...
Вы можете разделить его на 2 отдельных приложения, как вы сказали:
Централизованный интерфейс +back-end вызовет 1 или несколько баз данных
Клиентское приложение + back-end (монолит или несколько служб) вызовет ту же базу данных, что и централизованный интерфейс, но только для текущего клиента
Насколько я понял, ваша проблема не в масштабировании веб-серверов (вашего сервера), а в дб?Если ваша проблема также заключается в масштабировании серверной части, вы можете рассмотреть возможность масштабирования до нескольких экземпляров или разделения вашего домена на микроуслуги и масштабирования этой архитектуры на уровне микроуслуг для каждой услуги независимо.
Мое предложение:
1.Масштабирование вашего бэкенда: Вы можете хранить все в одном сервисе (монолитный подход), развернуть его на нескольких серверах и масштабировать весь сервис вместе.В этом нет ничего плохого.Как и все, это зависит от требований вашего бизнеса / домена и того, что лучше всего сработало для васХотя в наши дни очень популярно пользоваться микроуслугами, они не являются лучшим решением для каждой проблемы.Я работал с обоими типами архитектуры, и они отлично работали для разных сценариев.Вы даже можете иметь промежуточное решение между ними, чтобы взять на себя определенную часть, которая имеет высокий спрос на масштабирование, и извлечь ее как отдельную услугу (например, создание службы подсистемы Билетов), а остальная часть приложения, которая имеет низкую потребность, будет однойбольшой сервис.
2.Масштабирование вашей базы данных: Учитывая вышеизложенное, я бы предложил вам использовать Data Sharding или Partitioning.Вы можете прочитать о sharding данных здесь .В общем, это способ логически и физически разделить ваши данные из одной базы данных на несколько на основе некоторого ключа разделения или ключа сегмента.Это означает, что вы можете использовать одну конкретную концепцию в своем Домене в качестве ключа Shard для разделения данных на его основе.В вашем случае это может быть CustomerId. Это может быть сделано только если бизнес-операции, которые включают в себя больше
тогда один клиент не подходит для вашего бизнеса. Означает, что все ваши операции выполняются в рамках одного Клиента.
Единственным исключением здесь будет чтение / просмотр большего количества клиентов вместе. Это нормально, так как это не нужно
транснациональное поведение.
Это действительно зависит от ваших бизнес-сценариев и логики.
Если разделение вашей базы данных на несколько баз данных на основе shard-ключа CustomerId недостаточно, вы можете взять shard-ключ
что является еще более конкретным в рамках области клиента. Опять же, это зависит от того, позволяет ли это ваш домен.
В этом случае это может быть, например, концепция, что у CustomerA будет осколок CustomerA-Europe.
CustomerA-USA шард, CustomerA-Африка и так далее.
Это будет представлять логический осколок. Физический осколок будет физической базой данных.
Важным моментом является то, что вы выбираете логический осколок в начале, чтобы вы могли легко
перенести ваши данные в другие физические базы данных позже, когда вам это нужно, на основе этого шард-ключа.
В дополнение к этому вы можете включить Историзацию для некоторых тяжелых таблиц, чтобы отделить обновленную версию
данные из ваших исторических данных. Вы можете прочитать больше об этом здесь.