Comments 11
я хотел бы осветить иные аспекты
Где аспекты? рука дрогнула и недопереведенный текст зарелизили?
— Передача на сопровождение — необходимо построить централизованный каталог микросервисов с контролем версий и жизни каждого сервиса
— Модификация — с целью минимизировать доработки всего ландшафта и ошибок необходимо: грамотно делить функционал, обеспечивать обратную совместимость, контролировать выдержку архитектурных стилей при проектировании интерфейсов, планировать регрессионное тестирование и детально документировать!!!
Мне кажется что это основные аспекты данной архитектуры, которые часто заставляют разработчиков смотреть в сторону монолита.
И поспорю со вторым вашим утверждением, все перечисленное вами — всего лишь рабочие моменты, которые присущи и монолиту, с той разницей что микросервисы перераспределяют роли между программистом и архитектором в пользу последнего…
По-моему самое интересное там начинается с вопроса: а как мы будем обеспечивать целостность?
Данных. Один микросервис заведует пользователями, второй фоточками. Как убедиться, что нет потерявшихся фоточек (юзера удалили) и фоточек с левыми user_id?
Это не дает целостности. Сервер очередей может упасть, сообщение не дойти (например в случае, если сервер очередей не будет справляться с потоком). Сервер БД тоже может упасть, но тогда не пройдет вся транзакция, а тут — частично. Что если "A" дергает "B", "C" и "D", на "С" все нормально, а "D" и "B" вернули ошибки? Как отменить транзакцию на "C"?
Я как-то интересовался микросервисами, гуглил, читал бложики, но все, что я смог найти: та ну ее эту целостность и транзакции! С таким подходом область применения микросервисов сильно сужается.
Все сводится к обеспечению архитектурной целостности продукта, а это можно достичь путем строгой выдержки принятых в группе разработки стандартов и жесткого контроля их выполнения.
3D Масштабирование микросервисов