Зачем нам использовать микросервисы, если требуется код с меньшей задержкой?
В монолите нам просто нужно либо вызвать функцию, либо вызвать метод, в отличие от взаимодействия между процессами. Может ли кто-нибудь, знакомый с архитектурой микросервисов, понять причины, по которым можно использовать микросервисы для разработки приложений с малой задержкой?
Я думаю, что фреймворк Chronicle утверждает, что вы можете разрабатывать продукты на основе микросервисов и использовать очереди хроники для связи, не вызывая задержек сетевого перехода.
Микросервисы могут иметь низкую задержку. Взгляните на реактивную архитектуру.
С микросервисами у вас есть приложения, разбитые на более мелкие единицы. Преимущество этого заключается в том, что вы можете масштабировать эти устройства независимо и устранять узкие места в их источнике. При этом один медленный элемент в монолите может стать узким местом для всего приложения.
@shinjw - Я полностью понимаю преимущества микросервисов по сравнению с монолитом. Мой вопрос касается его использования в приложениях с низкой задержкой.
Реактивная архитектура @ApurvaSingh не является синонимом низкой задержки
Во-вторых ... учитывая, что все ваши услуги находятся в одной сети. Накладные расходы сети будут номинальными (~ 10-50 мс). Хотя большое количество болтовни может вызвать потенциальное замедление. Но вы также захотите принять во внимание тот факт, что у вас может быть множество других сервисов, доступных для выполнения той же работы.
@shinjw Действительно, реактивный режим предназначен для малой задержки. Другой цели нет. Архитектура / программирование на основе push с использованием веб-сокетов, обмен сообщениями, кэширование, неблокирующий ввод-вывод с использованием обратных вызовов функциональных комбинаторов - все это часть уменьшения задержки. >> Отзывчивость << - центральный компонент реактивной архитектуры.
Ответы 1
Прежде всего, этот комментарий полностью верен: микросервисы сами по себе не помогают с задержкой. В идеале они только (ну, в основном) общаются с другими сервисами, используя их как сервис, таким образом добавляя потенциальный штраф для сетевых / межпроцессных вызовов.
Но важно понимать: идея не в том, что микросервис зависит от 15 различных сервисов, которые необходимы ему для выполнения своей работы. Вам лучше смотреть на них как на независимые единицы, которыми являются разработан, чтобы разрешить горизонтальное масштабирование (просто добавляя «больше» экземпляров).
Следовательно, ключевым элементом является фактическое определение микросервиса архитектура. Простое превращение монолита в распределенную систему сервисов при сохранении ненужной связи не приведет к этому.
Горизонтальное масштабирование - ключ к успеху. Я бы выделил это слово
Ну .. Горизонтальное масштабирование, пока не возникнет узкое место в базе данных
@shinjw Простое нанесение на бутылки этикеток "микросервисы" не меняет того факта, что бутылки имеют горлышки ;-)
У микросервисов задержка не снижается. Вы всегда будете вводить дополнительные сетевые накладные расходы, когда требуется связь между соответствующими службами.