Веб-сервер это другое. Микросервис это приложение, выполняющее определенный ограниченный набор функций.
Один веб-сервер, например nginx, может обслуживать несколько апстримов. HTTP запросы принимает веб-сервер и пробрасывает их на апстримы, например на uwsgi, gunicorn и т.д.
По поводу обработки ошибок — для мониторинга микросервисов (да и обычных проектов) я использую zabbix, как и многие другие. Он пингует определенный URL и сравнивает полученный ответ с тем, что должно быть.
По поводу какой-то либы, не очень понял вас, взаимодействие между микросервисами может быть налажено как угодно — по HTTP, по AMQP или еще как-то. Простейший вариант — HTTP API, т.е. микросервисы общаются между собой по API, в этом случае отправлять можно, например с помощью requests, а обрабатывать с помощью того же DRF.
Или если общение через систему очередей, то получается каждый микросервис это просто celery воркер?
Нет, микросервис это просто приложение, которое запускается с помощью uwsgi (например). Воркеры celery это по сути процессы, которые получают сообщения из брокера и обрабатывают их.
DRF остался на стороне основного проекта и использовался только для разработки API интерфейса.
Админка это просто клиент на Javascript, который использует это API. Может быть это не совсем типичный «микросервис», а просто клиент, но тем не менее, по такому принципу можно выстраивать и другие решения. Например через HTTP API у меня работает логгер.
Docker я не использовал в этом проекте, для меня он до сих пор не до конца очевидно работает :)
С этим никак нельзя бороться. Но я добавляю событие об открытии письма каждый раз дополнительно при переходе по ссылке в письме, если оно не было зафиксировано ранее.
Плюс клиент может разместить в теле письма ссылку на его веб-версию, и тогда получатель сможет открыть его на сайте, там все картинки будут на месте.
Что вы подразумеваете под «модулем сбора базы адресов»?
Каждый пользователь моего сервиса может сгенерировать форму подписки для определенного списка подписчиков и встроить на сайт. Процедура подписки через эту форму включает double-opt-in авторизацию. Соответственно, человек подписавшийся через эту форму сразу попадает в определенный список подписчиков.
Что означает «Проверка подтверждения рассылки перед отправкой»?
Репутацию доменов я проверяю через mx-toolbox, пока вручную, попозже напишу робота.
Тогда логичнее унести трекинг в асинхронный таск :) Класть в какой-нибудь rabbitmq сообщение, а потом уже в рамках асинхронной задачи писать ивент в базу. Спасибо за хороший пример, подумаю по поводу оптимизации.
Ну, это дело вкуса. Поэтому я и сказал, что это не будет проще — вы сами сказали что вам нужно и elasticsearch прикрутить чтобы он логи парсил, а потом еще и его API дергать со стороны сервиса.
Что-то я не уверен, что парсинг логов nginx проще, чем обработка запроса к API :) Тем более, этот метод API можно потом переиспользовать.
Кроме того парсинг логов это плохо, потому что нужен realtime. Пользователь хочет знать когда прочитали письмо, а не когда парсер получил ивент из логов.
В этом случае на пиксель вы получите только «безголовый» запрос от робота с почтового клиента, а реальный получатель картинку не увидит, т.к. она будет вырезана. Соответственно запрос от его браузера вы тоже не увидите. По крайней мере с этим я столкнулся в gmail.
Также в некоторых email-клиентах такие пиксели не вырезаются, но тем не менее запросы браузера к реальным src картинок блокируются прокси-сервисом почтового сервиса.
Каждая рассылка проходит модерацию. Т.е. это ручная проверка + поиск адресов из списка в черных списках сервиса. Ну и с пользователем не помешает поговорить, откуда он эту базу взял и какие письма планируется рассылать.
В общем ответ на ваш вопрос — вручную. В следующих статьях распишу процесс подробнее.
Double-Opt-In это процедура, которая заключается в том, что после подписки на рассылку, человеку отправляется письмо со ссылкой активации, переходя по которой он подтверждает что действительно подписался на рассылку. Логи Double-Opt-In в дальнейшем позволят избежать спорных ситуаций с почтовыми провайдерами.
Что мешает сайту начать спамить пользователя, после того как он подтвердил посредством Double-Opt-In свой адрес?
Ну, ничего не мешает. Ему тоже ничего не мешает отправить письма такого отправителя в спам :)
Да, пустые письма похуже воспринимаются спам-фильтрами. Мы чекаем наши письма с помощью SpamCheck от Postmark, он позволяет отслеживать баллы SpamAssassin. Можете проанализировать свои письма: http://spamcheck.postmarkapp.com/
Ну, судя по всему, ящик был удален или заблокирован. Не вижу смысла пытаться отправлять email на такие ящики повторно, по крайней мере в ближайшее время. Можете попробовать отправить email через пару месяцев, и в случае подобного ответа, смело удалить его из базы.
Т.к. проект рос в основном органически и поначалу писем было немного, это и послужило прогревом.
Один веб-сервер, например nginx, может обслуживать несколько апстримов. HTTP запросы принимает веб-сервер и пробрасывает их на апстримы, например на uwsgi, gunicorn и т.д.
По поводу обработки ошибок — для мониторинга микросервисов (да и обычных проектов) я использую zabbix, как и многие другие. Он пингует определенный URL и сравнивает полученный ответ с тем, что должно быть.
По поводу какой-то либы, не очень понял вас, взаимодействие между микросервисами может быть налажено как угодно — по HTTP, по AMQP или еще как-то. Простейший вариант — HTTP API, т.е. микросервисы общаются между собой по API, в этом случае отправлять можно, например с помощью requests, а обрабатывать с помощью того же DRF.
Нет, микросервис это просто приложение, которое запускается с помощью uwsgi (например). Воркеры celery это по сути процессы, которые получают сообщения из брокера и обрабатывают их.
Админка это просто клиент на Javascript, который использует это API. Может быть это не совсем типичный «микросервис», а просто клиент, но тем не менее, по такому принципу можно выстраивать и другие решения. Например через HTTP API у меня работает логгер.
Docker я не использовал в этом проекте, для меня он до сих пор не до конца очевидно работает :)
Плюс клиент может разместить в теле письма ссылку на его веб-версию, и тогда получатель сможет открыть его на сайте, там все картинки будут на месте.
Каждый пользователь моего сервиса может сгенерировать форму подписки для определенного списка подписчиков и встроить на сайт. Процедура подписки через эту форму включает double-opt-in авторизацию. Соответственно, человек подписавшийся через эту форму сразу попадает в определенный список подписчиков.
Что означает «Проверка подтверждения рассылки перед отправкой»?
Репутацию доменов я проверяю через mx-toolbox, пока вручную, попозже напишу робота.
Кроме того парсинг логов это плохо, потому что нужен realtime. Пользователь хочет знать когда прочитали письмо, а не когда парсер получил ивент из логов.
Также в некоторых email-клиентах такие пиксели не вырезаются, но тем не менее запросы браузера к реальным src картинок блокируются прокси-сервисом почтового сервиса.
В общем ответ на ваш вопрос — вручную. В следующих статьях распишу процесс подробнее.
Ну, ничего не мешает. Ему тоже ничего не мешает отправить письма такого отправителя в спам :)