Что из этого будет правильным/компромиссным архитектурным решением?

Question

[Rogue85]

У компании есть своя программа (ERP система), которая работает с удаленными базами MySQL, отдельными на каждого клиента. Теперь занимаемся разработкой CRM системы, которая будет тесно связана с ERP, но уже в вебе. Т.е. получается, что нужно каким-то образом втиснуть архитектуру CRM в то, что уже было до этого и сильно не потерять.

По сути вижу такие варианты:
1. Ничего не менять и реализовывать CRM на отдельных базах для каждого клиента с одним бекендом.
Т.е. каждый запрос мы проверяем к какой компании относится юзер, находим данные его базы, подключаемся, делаем что нужно и возвращаем ответ. При таком решении я вообще сомневаюсь в возможности нормально все это поддерживать в будущем (клиентов уже около 500) и в возможности системы справиться с нагрузками (получается бекенд каждый запрос будет заново коннектится к базе данных). Еще один минус - все базы удаленные, т.е. + время на отправку запроса в БД, а если они последовательные, то время растягивается до 5-10 секунд на ответ, но это еще как-то решаемо.

2. Делать одну базу, импортировать туда все данные клиентов, провести все нужные действия для оптимизации. Проблема в том, что в программе нужно будет много всего менять, но как по мне, это решение более дальновидное. Возможно нормально масштабироваться, не раздувать время ответов и т.п.

3. Для каждого клиента разворачивать отдельный бекенд и БД в контейнере. Реализовать средства мониторинга для поддержки, автоматического обновления и т.д. Но тут тоже сильно усложняется поддержка всей системы.

Нужен совет. Все решения имеют свои плюсы и минусы в краткосрочном и долгосрочном плане. Спасибо!

Answer 1

[Макс Кузнецов]

К сожалению, нет данных, почему базы удаленные и разделены на несколько. Это сильно влияет на ответ. Может быть это хотелка ваших клиентов, чтобы все данные хранились именно на их базах? Или по юридическим соображениям. Тогда имеет смысл вариант 3 — вы просто продаёте комлексный self-hosted продукт. Не думаю, что для админов составит много труда настроить системы мониторинга, сбора логов и бэкапа. Один раз написать скрипты и потом это автоматизировать.

Но если считать, что никаких ограничений нет, то я за вариант 2. Логичнее всего иметь одну базу, где каждая сущность имеет client_id, а в коде на уровне базовых классов ORM добавить фильтр по нему. С серверной стороны — шардинг по client_id:
— Всё будет работать быстро и масштабироваться горизонтально по мере роста клиентов
— Придётся архитектурно немного заморочить, но имхо меньше, чем в предложенных вами вариантах
— Можно иметь общий дефолтный ACL для всех клиентов с возможностью кастомизации для каждого из них (уверен, что это понадобится)
— Все данные в одной базе и при желании вы сможете сделать дэшборд для супер-админа, который будет уметь редактировать всё это хозяйство по всем клиентам сразу и онбоардить нового клиента: создать входной аккаунт для админа клиентской компании, установить дефолтные настройки и определить доступный набор фич. Если такое планируется, советую сразу продумать архитектуру, иначе будет потом крайне больно.

Comments

[Rogue85]

Определенного ответа нет, просто вот так повелось изначально, так как никто не планировал уводить это в веб. Но с вами полностью согласен, спасибо.

Answer 2

[xmoonlight]

Можно сделать п.2, но так, что в программе ничего не нужно будет менять.

Comments

[Rogue85]

Не расскажете подробнее? В программе же все равно придётся делать выборку по клиенту в каждом SQL запросе как минимум.

[Luc1f1er666]

Rogue85, если в существующем решении у вас уже реализован backend с использованием стека который вы указали, можно обойтись малой кровью, но полностью без изменений не получится.

[Rogue85]

Luc1f1er666, ну так а ваше мнение, способно ли такое решение выдерживать адекватные нагрузки? И нормально ли это все будет с текущим стеком? Laravel не захлебнется от такого количества баз?

[DevMan]

Rogue85, с чего ему захлёбываться?
в классическом исполнении ларавел на каждый новый запрос создаёт новое подключение. ему без разницы будет это подключение к сервер1 или сервер3 или сервер100500.

[Luc1f1er666]

Rogue85, согласен с DevMan, все что написано на PHP на каждый запрос к серверу выполняет скрипт заново, а после выполнения скрипта сервер отдает ответ на клиент и убивает процесс выполнявший скрипт. Это если в общих чертах.

[Luc1f1er666]

Rogue85, тут больше вопрос в том, какое решение будет более удобным с точки зрения реализации и дальнейшей поддержки. Если у вас уже есть готовая связка работающая как вам необходимо, и вы хотите сделать для всех клиентов единую точку входа, можно накидать клиентскую часть как душе угодно, а бекенд реализовать в виде подобия балансировщика нагрузки. Отличие только в том, что бекенд не будет распределять нагрузку, а перенаправлять запросы на нужные сервера, получать данные и отдавать на клиент. Эдакая виртуальная реализация usb-hub.

[Luc1f1er666]

Rogue85, но как по мне, удобнее всего п.2, слейте все базы в одну, при этом изменив структуры таблиц так, что бы идентифицировать какому клиенту принадлежит конкретная запись в новой базе. Еще возможно будет нужна дополнительная таблица для хранения всех идентификаторов.
Проще всего в каждую таблицу добавить поле и писать в него уникальный идентификатор клиента, например UUID4, или base64 по имени клиента или названия организации, при необходимости будет возможность восстановить исходные данные о владельце записей.
Правки кода минимальны, в запросах на запись добавится новое поле, в запросах на чтение/редактирование/удаление добавится проверка значения нового поля. На клиенте нужно реализовать или получение идентификатора на лету по данным клиента, или запрашивать на сервере из доп. таблицы

[Rogue85]

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

Answer 3

[Philipp]

Логичнее всего иметь одну базу для всех клиентов.
Разумно было бы держать какой-то идентификатор клиента в таблицах.
Например создать таблицу клиентов и оттуда брать некий id. Постараться протащить id клиента во все таблицы связанный с ним таблицы. Когда у вас вырастет количество клиентов, вы сможете его использовать как часть ключа для шардинга. А если попадется очень-очень жирный клиент, его можно будет легко и без последствий выдернуть на отдельную машинку.

В долгосрочном плане старайтесь делать хотелки клиентов с учетом других клиентов. В итоге все будут в выигрыше и клиенты будут лояльны к вашему продукту. И вам не потребуется вести 10 разных кодовых баз.
Введите управление фичами для каждого клиента. Включайте большинство их по умолчанию для всех клиентов. Если кому-то не понравится, всегда можно будет отключить.

Я так понимаю, никаких здоровых процессов по развертывания проекта у вас нет. Советую присмотреться к какой-нибудь CI, даже тот же Deployer облегчит вашу жизнь. Он прекрасно работает в связке с Laravel.