Должны ли микросервисы разделять рабочих
Раскрутка нескольких наборов рабочих кажется самым простым способом сохранить все изолированным по мере необходимости, но также кажется несколько неэффективным с точки зрения ресурсов, поскольку это требует.
Производительность не является основным направлением микросервисов. Это часто неправильно понимаемый нюанс.
Если исходить из традиционного фокуса оптимизации на производительности одного запроса (т. е. сколько времени требуется для обработки одного запроса?), микросервисы на самом деле будут оцениваться как относительно неэффективные. Вам нужно несколько компьютеров, ваши базы данных разделены и не могут извлечь выгоду из оптимизации соединения, один запрос (к пользователю) может потребовать нескольких вызовов отдельных микросервисов... Все эти разделения влекут за собой накладные расходы соответствующих уровней связи.
Что касается вашего вопроса, неэффективность, на которой вы сосредоточены, - это не то, на чем вы должны фиксироваться в своей микросервисной архитектуре.
То, чего микросервисам не хватает в производительности среды выполнения с одним экземпляром, они с лихвой компенсируют значительно упрощенным процессом выпуска, строго соблюдаемым отсутствием жесткой связи и возможностью масштабировать сервисы на основе конкретного использования (без необходимости масштабировать сервисы, которые не нужны). т пользуется таким высоким спросом).
Чтобы максимизировать эти вещи, лучшим выбором здесь будет изоляция ваших рабочих процессов, поскольку это максимизирует независимость (и, следовательно, также масштабируемость) каждого отдельного микросервиса; именно в этом и заключается сила микросервисной архитектуры.
Прикрепляю к посту несколько видео по теме: