Comments 34
Скажите, на сколько REST будет просаживать производительность?
REST — это архитектурный стиль, он не может влиять на производительность. На производительность влияет конкретная реализация
Под REST вы понимаете HTTP взаимодействие вообще?
Просадка будет в зависимости от того, как работает сервер.
Вот у меня страничка генерируется 4мс. Но nginx отдает ее за 55мс. Хз как уменьшить.
Если за данными нужно стучаться далеко, просадка будет больше.
Просадка будет в зависимости от того, как работает сервер.
Вот у меня страничка генерируется 4мс. Но nginx отдает ее за 55мс. Хз как уменьшить.
Если за данными нужно стучаться далеко, просадка будет больше.
Вопрос не имеющий ответа. На сколько по сравнению с чем? В общем случае незначительно по сравнению с другими архитектурными стилями типа RPC, если вообще не выигрывать будет, из-за того, что серверу не надо хранить состояние сессии — всё что нужно для обработки запроса ему клиент в запросе будет предоставлять.
Цитата из текста:
«Если приложение относительно небольшое, то можно обойтись поддержкой REST-заросов, которые могут отсылаться непосредственно вовлеченными во взаимодействие сервисами. Это значительно упрощает архитектру приложения в целом, но приводит к существенным затратам на передачу информации (никогда не используйте синхронные запросы, если хотите чтобы ваше MSA-приложение работало достаточно быстро!)».
На сколько я понял автора, то имелось ввиду, что REST будет менее быстрым чем что-то другое.
Поэтому я решил уточнить, что подразумевалось.
«Если приложение относительно небольшое, то можно обойтись поддержкой REST-заросов, которые могут отсылаться непосредственно вовлеченными во взаимодействие сервисами. Это значительно упрощает архитектру приложения в целом, но приводит к существенным затратам на передачу информации (никогда не используйте синхронные запросы, если хотите чтобы ваше MSA-приложение работало достаточно быстро!)».
На сколько я понял автора, то имелось ввиду, что REST будет менее быстрым чем что-то другое.
Поэтому я решил уточнить, что подразумевалось.
Неудачная фраза, кажется. В общем и в целом нельзя сказать, что REST-запросы медленнее или быстрее других, а введение посредника в любом (кроме каких-то экзотических, связанных с конфигурацией сети) случае замедлит получение ответа. Но упростит архитектуру и ускорит разработку, как-только начнутся связи один-ко-многим.
Можно поподробнее вот про это:
Что имеется ввиду? Не опрашивать все нужные сервисы по очереди, а паралельно? Или что то другое?
никогда не используйте синхронные запросы, если хотите чтобы ваше MSA-приложение работало достаточно быстро!
Что имеется ввиду? Не опрашивать все нужные сервисы по очереди, а паралельно? Или что то другое?
UFO just landed and posted this here
Спасибо. Но в таком случае агрегатор никогда не покажет эти самые коменты, т.к. они придут слишком поздно и клиент уже покажет страницу. Клиенту придется отправить запрос на коменты еще раз и в этот раз ему придется таки дождатся ответа. Это не то что понимают под ассинхронностью, вернее совсем не то что понимаю я.
тут несколько вариантов
- грузить коменты асинхронно после загрузки страницы (так например youtube делает)
- кешировать коменты в микросервисе блогов, и обновлять кеш по мере обновления коментов (тогда "запрос" от сервиса блогов к сервису коментов будет вне контекста реквест-респонс для юзера и тоже "асинхронен")
а в первом случае асинхронность в том, что коменты грузятся в то время, пока пользователь уже читает бложек
UFO just landed and posted this here
ну так это уже с агрегатором ничего общего не имеет, а значит об асинхронности работы с микросервисом разговор не идет.
UFO just landed and posted this here
Ждать ответов от микросервисов можно (а обычно и нужно) в фоне.
Основной смысл — не допускать простоя. Менеджер очередей нужен нам прежде всего для логирования. С точки зрения разработчика это возможно и лишний элемент, но при тестировании очень удобно отслеживать взаимодействие процессов именно через него.
Единая шина общения между сервисами (в том числе организованная на базе менеджера очередей) нужна для унификации общения между сервисами. Логирование лишь частный случай. Сервисы как паблишеры отправляют в шину сообщения о важных (с их точки зрения) событиях, а другие сервисы как сабскрайберы предпринимают какие-то действия по получению важного (с их точки зрения) события, например запись в лог.
Вы и сами неплохо справляетесь, спасибо за такой живой интерес к статье.
Во-первых, сам агрегатор работает с микросервисами асинхронно, он не ждёт ответа от них. Во-вторых, и его клиенты могут работать с ним асинхронно по тем же веб-сокетам. Клиент даст запрос «дай мне пост с ид 303778 и комментарии к нему», агрегатор сначала отдаст пост, а потом комментарии (или наоборот, смотря что будет готово раньше).
Под асинхронностью обычно понимают отсутствие необходимости ждать ответа. Клиент отправляет запрос и занимается другими делами, обрабатывая ответ только когда он будет (если он ему вообще нужен, что не факт). В примере с агрегатором, при поступлении запроса от клиента по синхронному протоколу (например http запрос от браузера), он отправит два запроса к сервисам практически одновременно и отдаст управление ядру без ожидания ответа. Когда первый из ответов (не факто что это ответ на ушедший первым запрос) будет готов, ядро вызовет агрегатор уведомлением о готовности, агрегатор скопирует ответ в свой буфер (или сохранит указатель на буфер полученный от ядра) и опять отдаст управлению ядру. И только когда второй ответ будет готов, агрегатор полностью сформирует и отдаст ответ по синхронному протоколу. Агрегатор работает асинхронно, он не ждёт ответа от сервисов ни такта процессора, его работа по другим запросам не блокируется ожиданием.
А что понимаете под асинхронностью вы?
А что понимаете под асинхронностью вы?
UFO just landed and posted this here
Спасибо за ответ, но вы сказали абсолютно тоже самое, что сказал я: ваш агрегатор общается с сервисами паралельно, но не ассинхронно. Ответ клиент получит только когда оба сервиса отдадут ответ. Ассинхронности тут нет, здесь есть параллельность.
Под ассинхронностью я понимаю следующий сценарий:
агрегатор создает «пустую» (т.е. без статьи и коментов, но с хидером, футером, и т.д.) страницу и отдает ее браузеру. Браузер показывает страницу и открывает 2 сокета на получение статьи и комментов к ней. Одновременно агрегатор отсылает запрос каждому из сервисов. Как только ответ пришел, агрегатор обрабатывает его и отсылает браузеру через соответствующий сокет.
Под ассинхронностью я понимаю следующий сценарий:
агрегатор создает «пустую» (т.е. без статьи и коментов, но с хидером, футером, и т.д.) страницу и отдает ее браузеру. Браузер показывает страницу и открывает 2 сокета на получение статьи и комментов к ней. Одновременно агрегатор отсылает запрос каждому из сервисов. Как только ответ пришел, агрегатор обрабатывает его и отсылает браузеру через соответствующий сокет.
Мой агрегатор общается с сервисами асинхронно, он не ждёт ответа от них, а занимается другими делами или нечем не занимается (ничего не делать != делать ничего, ждать события == делать ничего до события)
Вы описывате трехзвенную архитектуру с асинхронным протоколом между клиентом и фронтом, я описал асинхронную реализацию фронта. Отделяйте протокол общения клиента с сервером (или узла с узлом или шиной в общем случае) и реализацию клиента/сервера/узла/шины. Протокол может быть синхронным, а реализация отправки запросов и обработки ответов асинхронной (часто и у клиента, и у сервера — например аякс запросы к серверу на ноде или просто к нжинкс, ). Речь в совете «никогда не используйте синхронные запросы, если хотите чтобы ваше MSA-приложение работало достаточно быстро!», насколько я понимаю, о реализации механизма отправки исходящих запросов и обработки ответов в целом, но прежде всего на самих микросервисах (в примере — агрегатора), обращающихся к другим микросервисам (в примере — сервисы постов и комментариев).
Вы описывате трехзвенную архитектуру с асинхронным протоколом между клиентом и фронтом, я описал асинхронную реализацию фронта. Отделяйте протокол общения клиента с сервером (или узла с узлом или шиной в общем случае) и реализацию клиента/сервера/узла/шины. Протокол может быть синхронным, а реализация отправки запросов и обработки ответов асинхронной (часто и у клиента, и у сервера — например аякс запросы к серверу на ноде или просто к нжинкс, ). Речь в совете «никогда не используйте синхронные запросы, если хотите чтобы ваше MSA-приложение работало достаточно быстро!», насколько я понимаю, о реализации механизма отправки исходящих запросов и обработки ответов в целом, но прежде всего на самих микросервисах (в примере — агрегатора), обращающихся к другим микросервисам (в примере — сервисы постов и комментариев).
не-не, конечно же ваш агрегатор что то делает: он ждет. И ждет он последний ответ. Время при этом уходит, в худшем случае вы получаете время отклика на 99.999% совпадающее со временем отклика, как если бы вы тупо опрашивали все сервисы по очереди в for- цикле с ожиданием ответа от каждого сервиса. Ведь клиенту вообще то все равно как там устроен агрегатор, ему важно время появления первого результата.
Он не ждёт, инициировав запрос, он обрабатывает другие запросы от клиента или ответы на них, или отдаёт управление ядру если в очереди ответов пусто. Ядро тоже не ждёт, ввод-вывод в ядре асинхронный как правило уже много лет, ядро инициирует отправку команду контроллерам диска, сети и т. п., а когда у них есть результат для ядра, они вызывают хардварное прерывание.
Если клиент общается с асинхронным фронтом по синхронному протоколу, то время ответа будет примерно равно максимальному из времён ответа бэков. Если агрегатор синхронный, то время ответа будет примерно равно сумме времён ответа бэков. Если клиент общается с асинхронным фронтом по асинхронному протоколу, то время первого значимого ответа (отклик «ваш запрос принят» за значимый не считаем) будет примерно равно минимальному из времён ответа бэков.
В любом случае если клиент асинхронный (например, ajax запрос из браузера), то независимо от протокола и реализации фронта, он (клиент) ответа не ждёт, а занимается своими делами (например, крутит спиннер для пользователя :) или отдаёт управление своему ядру.
Ответа ждут (то есть блокируют свою работу до получения) только синхронные клиенты. Совет в статье прежде всего относится к клиентам микросервисов таким как агрегатор, а не к клиентам клиентов микросервисов таким как браузер со страничкой агрегатора.
Если клиент общается с асинхронным фронтом по синхронному протоколу, то время ответа будет примерно равно максимальному из времён ответа бэков. Если агрегатор синхронный, то время ответа будет примерно равно сумме времён ответа бэков. Если клиент общается с асинхронным фронтом по асинхронному протоколу, то время первого значимого ответа (отклик «ваш запрос принят» за значимый не считаем) будет примерно равно минимальному из времён ответа бэков.
В любом случае если клиент асинхронный (например, ajax запрос из браузера), то независимо от протокола и реализации фронта, он (клиент) ответа не ждёт, а занимается своими делами (например, крутит спиннер для пользователя :) или отдаёт управление своему ядру.
Ответа ждут (то есть блокируют свою работу до получения) только синхронные клиенты. Совет в статье прежде всего относится к клиентам микросервисов таким как агрегатор, а не к клиентам клиентов микросервисов таким как браузер со страничкой агрегатора.
Решусь оставить это здесь на правах саморекламы. Фреймворк создавался как раз для реализации MSA.
Тут прежде всего напрашивается упоминание о тестовой пирамиде… (http://martinfowler.com/bliki/TestPyramid.html)
Микросервисная архитектура позволяет писать хорошие тесты у базы пирамиды и многое ими покрывать и отлавливать…
Однако МСА переносит часть сложности в интеграционный слой… и это момент особого внимания в микросервисной архитектуре…
Тут все должно быть четко и понятно, тогда можно (и нужно) ограничится минимум правильно написаных интеграционных тестов.
Микросервисная архитектура позволяет писать хорошие тесты у базы пирамиды и многое ими покрывать и отлавливать…
Однако МСА переносит часть сложности в интеграционный слой… и это момент особого внимания в микросервисной архитектуре…
Тут все должно быть четко и понятно, тогда можно (и нужно) ограничится минимум правильно написаных интеграционных тестов.
Sign up to leave a comment.
Микросервисы как архитектура: выжать по максимуму