Comments 6
После того, как модули разделены, переход к сервисам является довольно тривиальным. Ради примера я просто скопировал содержимое всего приложения в отдельные каталоги, затем удалил ненужные модули из исходного кода и исправил пару конфигов. Вот окончательная структура:
не раскрыта тема - насколько тормознее будет работать асинхронная и разделенная архитектура из-за задержек, вносимых сетью и передачей данных. Не в тестах с 1 (одним_ запросом, а при реальном пиковом числе запросов
Добрый день. Спасибо за комментарий.
По опыту двух проектов, HTTP оверхед интуитивно пугает больше, чем он есть на самом деле. В обоих случаях сервисы находились в рамках одного дата-центра, и данный оверхед почти не имел импакта на latency. Если не изменяет память, то RPS в нашем случае колебался от 10 до 100.
Что же касается async, то здесь картина другая, и нужно хорошо продумывать архитектуру. В большинстве случаев как минимум необходим autoscaling консумеров и хороший мониторинг с алертами, чтобы сообщения в очередях не копились. Зато потенциально такая архитектура масштабируется даже лучше.
Сферический конь в вакууме, хоть в статье и есть полезные мысли и вещи
Не увидел outbox pattern в финальной версии, я что-то не заметил или вы это решили не реализовывать?
Добрый день. Реализация таких event-driven-specific техник интересна, но выходит за рамки миграции архитектуры, а статья именно об этом. Возможно, вы пропустили следующую ремарку:
На последнем этапе мы не будем реализовывать полноценную event-driven архитектуру с event streams, bounded context models, outbox pattern и т.д.
Практический пример декомпозиции монолитного PHP приложения