На приведенной ниже диаграмме показано, почему игровые приложения в реальном времени и торговые приложения с низкой задержкой не должны использовать микросервисную архитектуру.
У этих приложений есть некоторые общие особенности, которые заставляют их выбирать монолитную архитектуру:
- Эти приложения очень чувствительны к задержкам. Для игр в реальном времени задержка должна составлять миллисекунду; для торговли с низкой задержкой задержка должна составлять микросекунду. Мы не можем разделить службы на разные процессы, потому что задержка в сети невыносима.
- Архитектура микросервиса обычно не имеет состояния, и состояния сохраняются в базе данных. Для игр в реальном времени и торговли с низкой задержкой необходимо сохранять состояния в памяти для быстрого обновления. Например, когда персонаж получает травму в игре, мы не хотим видеть обновление через 3 секунды. Такого рода пользовательский опыт может убить игру.
- Игры в реальном времени и торговля с низкой задержкой должны взаимодействовать с сервером на высокой частоте, а запросы должны поступать в один и тот же запущенный экземпляр. Таким образом, необходимы подключения к веб-сокетам и липкая маршрутизация.
Таким образом, микросервисная архитектура предназначена для решения проблем в определенных доменах. Нам нужно думать о том, “почему” при разработке приложений.
👉 К вам: сталкивались ли вы с подобными ситуациями на работе, когда вам приходилось выбирать архитектуру, отличную от микросервиса?