На приведенной ниже диаграмме показано, почему игровые приложения в реальном времени и торговые приложения с низкой задержкой не должны использовать микросервисную архитектуру.
![Нет альтернативного текстового описания для этого изображения Нет альтернативного текстового описания для этого изображения](https://resize.yandex.net/mailservice?url=https%3A%2F%2Fsubstackcdn.com%2Fimage%2Ffetch%2Fw_462%2Cc_limit%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep%2Fhttps%253A%252F%252Fsubstack-post-media.s3.amazonaws.com%252Fpublic%252Fimages%252Fe0a6d625-3bd5-4db0-addb-a12c0c569f9e_800x806.jpeg&proxy=yes&key=28221b6b20ee0efa9d10d473b7140557)
У этих приложений есть некоторые общие особенности, которые заставляют их выбирать монолитную архитектуру:
- Эти приложения очень чувствительны к задержкам. Для игр в реальном времени задержка должна составлять миллисекунду; для торговли с низкой задержкой задержка должна составлять микросекунду. Мы не можем разделить службы на разные процессы, потому что задержка в сети невыносима.
- Архитектура микросервиса обычно не имеет состояния, и состояния сохраняются в базе данных. Для игр в реальном времени и торговли с низкой задержкой необходимо сохранять состояния в памяти для быстрого обновления. Например, когда персонаж получает травму в игре, мы не хотим видеть обновление через 3 секунды. Такого рода пользовательский опыт может убить игру.
- Игры в реальном времени и торговля с низкой задержкой должны взаимодействовать с сервером на высокой частоте, а запросы должны поступать в один и тот же запущенный экземпляр. Таким образом, необходимы подключения к веб-сокетам и липкая маршрутизация.
Таким образом, микросервисная архитектура предназначена для решения проблем в определенных доменах. Нам нужно думать о том, “почему” при разработке приложений.
👉 К вам: сталкивались ли вы с подобными ситуациями на работе, когда вам приходилось выбирать архитектуру, отличную от микросервиса?