Комментарии 11
Как я понял из статьи. Для другого микросервиса с админкой ты просто поднял новый инстанс django c DRF, и React?
Не использовал систему контейнеров типа Docker?
Не использовал систему контейнеров типа Docker?
DRF остался на стороне основного проекта и использовался только для разработки API интерфейса.
Админка это просто клиент на Javascript, который использует это API. Может быть это не совсем типичный «микросервис», а просто клиент, но тем не менее, по такому принципу можно выстраивать и другие решения. Например через HTTP API у меня работает логгер.
Docker я не использовал в этом проекте, для меня он до сих пор не до конца очевидно работает :)
Админка это просто клиент на Javascript, который использует это API. Может быть это не совсем типичный «микросервис», а просто клиент, но тем не менее, по такому принципу можно выстраивать и другие решения. Например через HTTP API у меня работает логгер.
Docker я не использовал в этом проекте, для меня он до сих пор не до конца очевидно работает :)
А можно более детально об общении между микросервисами?
Каждый микросервис — это просто мини веб-сервер? То есть принимает и отдает http запросы. Тогда вопрос, как обрабатывает сервис ошибку, если микросервис отваливается? И есть ли какая либа для упрощенного создании(обработки) запросов между микросервисами?
Или если общение через систему очередей, то получается каждый микросервис это просто celery воркер?
Каждый микросервис — это просто мини веб-сервер? То есть принимает и отдает http запросы. Тогда вопрос, как обрабатывает сервис ошибку, если микросервис отваливается? И есть ли какая либа для упрощенного создании(обработки) запросов между микросервисами?
Или если общение через систему очередей, то получается каждый микросервис это просто celery воркер?
Веб-сервер это другое. Микросервис это приложение, выполняющее определенный ограниченный набор функций.
Один веб-сервер, например nginx, может обслуживать несколько апстримов. HTTP запросы принимает веб-сервер и пробрасывает их на апстримы, например на uwsgi, gunicorn и т.д.
По поводу обработки ошибок — для мониторинга микросервисов (да и обычных проектов) я использую zabbix, как и многие другие. Он пингует определенный URL и сравнивает полученный ответ с тем, что должно быть.
По поводу какой-то либы, не очень понял вас, взаимодействие между микросервисами может быть налажено как угодно — по HTTP, по AMQP или еще как-то. Простейший вариант — HTTP API, т.е. микросервисы общаются между собой по API, в этом случае отправлять можно, например с помощью requests, а обрабатывать с помощью того же DRF.
Нет, микросервис это просто приложение, которое запускается с помощью uwsgi (например). Воркеры celery это по сути процессы, которые получают сообщения из брокера и обрабатывают их.
Один веб-сервер, например nginx, может обслуживать несколько апстримов. HTTP запросы принимает веб-сервер и пробрасывает их на апстримы, например на uwsgi, gunicorn и т.д.
По поводу обработки ошибок — для мониторинга микросервисов (да и обычных проектов) я использую zabbix, как и многие другие. Он пингует определенный URL и сравнивает полученный ответ с тем, что должно быть.
По поводу какой-то либы, не очень понял вас, взаимодействие между микросервисами может быть налажено как угодно — по HTTP, по AMQP или еще как-то. Простейший вариант — HTTP API, т.е. микросервисы общаются между собой по API, в этом случае отправлять можно, например с помощью requests, а обрабатывать с помощью того же DRF.
Или если общение через систему очередей, то получается каждый микросервис это просто celery воркер?
Нет, микросервис это просто приложение, которое запускается с помощью uwsgi (например). Воркеры celery это по сути процессы, которые получают сообщения из брокера и обрабатывают их.
А как кстати почту отправляете? через smtplib по таскам из celery?
Спасибо за статьи.
А не расскажите со скольких ip происходит отправка? Вы «прогревали» их?
А не расскажите со скольких ip происходит отправка? Вы «прогревали» их?
Интересно какова пропускная способность воркеров, если конкаренси=4? Похоже такая очередь при первой же проблеме с сетью запхлебнется в потоке задач. Для неблокирующих операций можно запускать celery, используя eventlet, --concurrency=400 --pool=eventlet.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нам стоит сервис email-маркетинга построить? Взгляд изнутри, часть вторая