Разница между работником и службой в контексте инфраструктурных примитивов

Question

Я создаю инфраструктурные примитивы для поддержки работников и служб http.

• работники автономны
• Службы http имеют веб-сервер и балансировщик нагрузки

Насколько я понимаю, рабочий обычно извлекает ресурсы из внешнего ресурса для выполнения задач, в то время как служба обрабатывает входящие запросы и обращается к вышестоящим службам.

Celery - очевидный работник, а веб-приложение - очевидная служба,Линии могут быть размытыми, и я не уверен, что лучший подход:

• Является ли примитив работник / служба хорошей идеей?
• Что если есть служба, которая потребляетзадачи, как рабочий, но также обрабатывает некоторые запросы http, чтобы добавить задачи? Это работник или сервис?
• А как насчет сервисов, которые не проходят через nginx, означает ли это, что третий "сетевой" примитив с NLB - это путь?
• Чтоо случаях службы с отслеживанием состояния, к которой подключается главная служба? Мастер должен знать отдельные экземпляры агентов, поэтому мы не можем скрывать их за LB. Как бы вы представляли это?

Answer 1

Один из способов увидеть разницу - взглянуть на свои имена - работники делают то, что говорит их имя, - они выполняют (обычно) тяжелые задачи (работу) - то, что вы не хотите, чтобы ваш сервис беспокоился, особенно если это микросервис. - По этой конкретной причине вы редко увидите 32-ядерные машины с сотнями ГБ ОЗУ, на которых запущены сервисы, но очень часто вы увидите, что они работают. Наконец, они хорошо дополняют друг друга. Службы разгрузить тяжелые задачи для рабочих. Это согласуется с известной философией UNIX «делай одно и делай это хорошо».

Answer 2

• Является ли рабочий / сервисный примитив хорошей идеей?

ИМО, основное различие между службой и работником может заключаться в том, что работники должны назначаться только для одной задачи, но для службыможет выполнять несколько задач. Служба может использовать работника или цепочку работников для обработки запроса пользователя.

• Что если есть служба, которая потребляет задачи, например, рабочий, но также обрабатывает некоторые запросы http для добавления задач?

Службы могут быть разнымитакие формы, как веб-служба, служба FTP, служба SNMP или служба обработки. Написание логики обработки в сервисе может быть плохой идеей, если она не принимает форму работника.

• Что касается сервисов, которые не проходят через nginx, значит ли это треть? "сетевой" примитив с NLB - это путь?

Я полагаю, вы полагаете, что служба основана только на HTTP, но, как я уже упоминал в предыдущем ответе, службы могут быть разнымитипы. Да, вы можете написать службу TCP для конкретной реализации протокола, которая может быть присоединена за NLB

• Как насчет экземпляров службы с сохранением состояния, к которой подключается служба-концентратор? Хаб должен знать отдельные экземпляры, поэтому мы не можем спрятать их за LB.

Не знаете, что вы подразумеваете под хабом? Но хорошей практикой для масштабируемой архитектуры является использование серверов / служб без сохранения состояния. Состояние сеанса не должно храниться в служебной памяти, а должно быть сериализовано в хранилище данных, такое как DynamoDB.