Стек технологий при переделке монолита на микросервисы?
Суть такая, есть древняя как помёт мамонта монолитная самописная учётная система (адская смесь CRM, ERP + блок отчётности и аналитики). Всё это работает медленно и печально.
Внезапно появились ресурсы по превращению всего этого в нечто посовременнее. Предлагаемые похожие решения на рынке (в первую очередь посмотрели на 1С, разумеется) либо очень сложны в допиливании, либо на них озвучивается совершенно конский ценник.
Заявлено следующее - перейти на тонкие клиенты (доступ в систему через браузер), каждый из блоков (пока их 4, возможно, захотят больше) должен быть автономен и независим от других (в части поддержки и обновлений), поддерживать обмен данными через общий API (идеально http, допускается TCP/IP), максимальное использование бесплатного ПО, до 1000 пользователей.
Рефактор старой бизнес-логики более-менее уже проводится, теперь необходимо выбрать подходящую платформу для сего проекта. В целом, напрашивается архитектура из микросервисов, но есть опасения по поводу согласованности данных.
В общем, прошу высказать ваши соображения по поводу стека необходимых технологий для развёртывания подобного приложения.
Допустим у нас была система на Django (Python) - огромная система с кучей всего. Мы прикинули и поняли, что разбивка монолита на микросервисы не обязательно должна быть "глобальной и сложной". Можно поделить монолит на более мелкие монолиты:
1) Вынесли сервис авторизации из монолита на Django в отдельную систему на Django.
2) Вынесли партнерский модуль из монолита на Django в отдельную систему на Django.
3) Вынесли модуль постройки отчетов из монолита на Django в отдельную систему на Django и поставил диспетчер очередей, чтобы не блокировался запрос.
4) Вынесли платежный модуль из монолита на Django в отдельную систему на Django.
И так далее.
В итоге, мы продолжили работать на той же Django, только получили несколько независимых систем в разных репозиториях (которые можно катить, стопать, обновлять независимо), получили более гибкую систему передачи запросов (прямые, менеджеры очередей очередей итд), плюс изолировали данные где-то прямо физически разные базы, а где-то разные юзеры с разными правами.
Ну т.е. не надо прямо так глобально думать, можно просто побить системы на более мелкие куски на том же стеке, что вы работаете и уже будет лучше и проще. А потом уже более мелкие куски дробить при необходимости.
Было бы хорошо, НО! Сейчас это десктопный виндовый клиент к тугодумному серверу, общающиеся по самописному же протоколу. Система эволюционировала почти 20 лет.
Автор верно подметил про согласованность данных. Об этом изначально думать нужно как это будет. Как правило в таких системах используют saga и получается eventual consistency, когда данные не консистентны сразу, но станут таковыми через N времени. Но требуется еще и некое подобие изолированности из ACID. Если сущность в текущий момент участвует в незавершенной саге, то никто другой не должен иметь возможности её изменять. Иначе всё сломается. Вот первичные вопросы. Толку от деления если не будет консистентности данных. Тут вон уже про реакт начали писать. Видимо это самое важное в микросервисах какую хрень выбрать для визуализации. Ну вообщем как обычно на тостере, советчики из тех кто сам ничего подобного не сделали и у которых всё просто. Советы из разряда разбей свой код и готово )))
xfg, Скажем так. Eventual consistency вполне допустима почти для всех блоков, за исключением складского, но там используется своя WMS, которой и будут скармливать наряды, сгенерированные в системе. Собственно, это пока единственный затык, так как необходимо как-то избежать выписки одного и того же товара дважды и видеть остатки в реальном времени (ну, или почти в реальном времени).
Предполагается использовать шину обмена на базе какого-нибудь менеджера сообщений, а разные блоки будут выступать подписчиками. Что же до отчётности и аналитики - то тут вполне можно и несколько часов подождать.
Собственно, вопрос ещё вот в чём. Всё, что я читал по этой теме предполагает поддержку собственных БД каждым сервисом, какие могут быть подводные камни, если мы, всё-таки, будем продолжать использовать единую БД, просто операторы, вместо того, чтобы ждать завершения транзакций, будут просто пулять данные в очередь, а уже отдельный сервис будет постепенно и неспеша эти транзакции выполнять.
А не будет соображений. История сферическая в вакууме и сами «микросервисы» вообще самая простая часть. А вот с процессом миграции и ее детальным планированием можно мучаться. В принципе, можно сразу сказать что системы существующие как монолит больше 5 лет редко занимают меньший срок для изменения архитектуры
1. Надо действительно продумать хорошо API
2. Для фронта React быстро и удобно
3. Для бека использовать то что уже есть и что знают ваши программисты.
4. Слой APItoClient - Appolo например может
Вариантов много, но этот выглядит наименее проблемным.
Средний
