Шаблон SOA Service Data Replication

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

Решение

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

Плюсы решения

• если падает сервис от которого зависит приложение, то на приложении это не сказывается (стабильность - самый большой плюс)
• пропадает необходимость в API по http, остается только библиотека внутри проекта (которая обычно предоставляет API-клиента)
• когда данные рядом, то нет затрат на сеть (ускорение работы)
• строгое ограничение доступа к данным (потребитель имеет доступ только на чтение, мастер-система имеет доступ на запись в свое хранилище)
• возможность выделения своего необходимого кол-ва ресурсов (ресурсы по потребности), изменение (уменьшения/увеличения)
• отсутствует сложная технологий обмена/синхронизации состояния данных (используется родная репликация бд)
• один клиент больше не блокирует второго клиента (ведь у каждого своя бд), выше скорость, меньше блокировок
• больше нет необходимости в централизованном доступе к сервису предоставляющего данные (а следовательно чуть меньше логирования, мониторинга, безопасности) Из возможных плюшек:
• совместный доступ к одним и тем же физическим экземплярам системы (например 2 клиента используют 1 приложение)
• отсутсвие хаотичного контракта на данные (используется библиотека использующая стандартный протокол взаимодействия с бд)

Минусы решения

• согласованность данных (реплика может отставать, но у нас сейчас и так используется долгий кэш)
• увеличение количества бд, а следовательно чуть больше логирования, мониторинга, безопасности, восстановления (но не бэкапирования)
• количество API-библиотек равно количеству языков на которых написаны приложения
• это решение только для read only клиент
• чем больше клиентов, тем больше данных в бд (размер)

Нейтральные выводы

• сохраняется централизованное место изменения данных (админа есть и будет дальше)
• децентрализованное обновление бизнес-логики (это может быть как плюсом, так и минусом, ведь изменения иногда приносят не только исправления, но и баги)

Нерешенные вопросы

• строгое тестирование всех используемых версий схем данных, ианче внезапно могут появляться ошибки несовместимости со схемой бд (ведь схема тоже реплицируется), по правде сейчас поломать обратную совместимость тоже легко

Альтернатива

• каждому клиенту по своей версии веб-сервиса (плюс - более быстрое обновление API, минус - чем больше клиентов, тем больше сервисов с разными версиями и больше логирования, мониторинга, безопасности)