@cicatrix
было бы большой ошибкой думать

Стек технологий при переделке монолита на микросервисы?

Суть такая, есть древняя как помёт мамонта монолитная самописная учётная система (адская смесь CRM, ERP + блок отчётности и аналитики). Всё это работает медленно и печально.
Внезапно появились ресурсы по превращению всего этого в нечто посовременнее. Предлагаемые похожие решения на рынке (в первую очередь посмотрели на 1С, разумеется) либо очень сложны в допиливании, либо на них озвучивается совершенно конский ценник.

Заявлено следующее - перейти на тонкие клиенты (доступ в систему через браузер), каждый из блоков (пока их 4, возможно, захотят больше) должен быть автономен и независим от других (в части поддержки и обновлений), поддерживать обмен данными через общий API (идеально http, допускается TCP/IP), максимальное использование бесплатного ПО, до 1000 пользователей.

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

В общем, прошу высказать ваши соображения по поводу стека необходимых технологий для развёртывания подобного приложения.
  • Вопрос задан
  • 541 просмотр
Пригласить эксперта
Ответы на вопрос 7
@hatman
Подходите к решению проще и спокойно.

Допустим у нас была система на Django (Python) - огромная система с кучей всего. Мы прикинули и поняли, что разбивка монолита на микросервисы не обязательно должна быть "глобальной и сложной". Можно поделить монолит на более мелкие монолиты:

1) Вынесли сервис авторизации из монолита на Django в отдельную систему на Django.
2) Вынесли партнерский модуль из монолита на Django в отдельную систему на Django.
3) Вынесли модуль постройки отчетов из монолита на Django в отдельную систему на Django и поставил диспетчер очередей, чтобы не блокировался запрос.
4) Вынесли платежный модуль из монолита на Django в отдельную систему на Django.

И так далее.

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

Ну т.е. не надо прямо так глобально думать, можно просто побить системы на более мелкие куски на том же стеке, что вы работаете и уже будет лучше и проще. А потом уже более мелкие куски дробить при необходимости.
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
А не будет соображений. История сферическая в вакууме и сами «микросервисы» вообще самая простая часть. А вот с процессом миграции и ее детальным планированием можно мучаться. В принципе, можно сразу сказать что системы существующие как монолит больше 5 лет редко занимают меньший срок для изменения архитектуры
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
https://amphp.org/ и "прямые руки" архитектора.
Ответ написан
Допустим если вы продумали очень грамотное API для взаимодействия всех составных частей, то не всё ли равно на чём будут написаны микросервисы?
Ответ написан
firedragon
@firedragon
Senior .NET developer
Есть взрослые системы microsoft \oracle и прочие ibm
Делайте на них.

Кстати сбор и обработка традиционно делаются на разных комплексах. Единая только база данных.
Это не микросервисы это обычная архитектура.

Использование http/s в качестве транспорта добавит вам лишние накладные расходы, как в пинге, так и в обьеме.

Насчет бесплатного (опенсорсного). Вы платите за функционал, представьте вы захотели нарисовать своими силами что то типа power bi?

Впечатлились ?

Так что разделите систему на 2 части:

1. АРМ для пользователя - все что относится к оперативному вводу и обработке
2. АРМ для аналитиков - все что относится к анализу и отчетам

Платформа:
Net core, MS SQL server, SSRS возможны конечно варианты
Ответ написан
@YuriKukharev
1. Надо действительно продумать хорошо API
2. Для фронта React быстро и удобно
3. Для бека использовать то что уже есть и что знают ваши программисты.
4. Слой APItoClient - Appolo например может

Вариантов много, но этот выглядит наименее проблемным.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы