«Почта для доменов». Несколько лет назад мы предположили, что собственные почтовые службы, развернутые в компаниях, — особенно небольших и без своего системного администратора — доставляют хлопот больше, чем приносят пользы. И со временем все больше людей будут передавать ответственность за хранение и обработку электронных писем на аутсорс, специальным сервисам. Так у нас появилась Почта для доменов.
Как показало время, мы не ошиблись, и сегодня Почта для доменов Яндекса является самым популярным почтовым сервисом в Рунете. Всего к ПДД подключено более 200 тысяч доменных имен и почти 3,5M почтовых ящиков. Каждый день к ПДД подключается около 200 доменов. В этой статье мы расскажем, как работает ПДД, а в комментариях с радостью ответим на ваши вопросы.
За время своего существования ПДД обросла множеством дополнительных функций: интеграцией с адресной книжкой, поддержкой jabber-сервера, списками рассылок, импортом почты с прежних серверов пользователя, и, конечно же, внешним API для автоматизации запросов. Например, нас долгое время просили сделать так, чтобы пользователь стороннего сайта, авторизованный на нём, сразу же попадал в свой ящик — без повторной авторизации в Яндекс.Почте для доменов. И наше API позволило реализовать такой способ беспарольной авторизации.
Почта для доменов
Все возможности, которые предлагает ПДД, требуют интеграции с различными компонентами продуктов Яндекса и не только. По сути своей, ПДД — это интеграционный сервис, сводящий воедино разрозненные компоненты под управлением администратора домена.
ПДД начинается с домена: его нужно подключить и проверить, что владелец домена и администратор ПДД — один и тот же человек. Случается, что домены по тем или иным причинам отключаются от ПДД на уровне DNS. Для подтверждения владения и для подтверждения статуса домена мы используем систему очередей проверок, состоящую из нескольких серверов хранилища очередей проверок в реляционной СУБД и кластера распределенных блокировок на базе MongoDB.
Чтобы не перегружать проверками серверы, на которых размещены сайты доменов либо DNS-серверы зон, каждая следующая проверка подтверждения происходит с возрастающим временным интервалом — начиная с пяти минут и заканчивая 24 часами. Проверки статусов доменов происходят чаще — приблизительно раз в четыре часа с постоянными временными интервалами. Такой подход позволяет значительно снизить нагрузку на воркеры очередей проверок. Как только домен подтвержден, его администратору становятся доступны все основные функции и он может создавать ящики.
Чтобы сохранить универсальный подход и уменьшить число ошибок, мы разработали внутренний API почты для доменов, который может быть использован другими компонентами Яндекса для обмена необходимой информацией. Так, например, публичный API почты для доменов — это один из таких компонентов. Вызовы публичного API транслируются в универсальные вызовы внутреннего API. Любые действия в веб-интерфейсе ПДД также вызывают методы внутреннего API.
В зависимости от требуемых действий обработчик вызовов внутреннего API может обращаться к тем или иным компонентам Яндекса. Основной принцип при проектировании новой функциональности заключается в том, чтобы не хранить на стороне ПДД информации, которая уже хранится где-то в другом месте. Исключение делается только для запросов, которые критичны ко времени выполнения, — их приходится кешировать.
Маленький пример
Например, чтобы создать новый почтовый ящик, необходимо в Паспорте завести нового пользователя, после чего проинициализировать для этого пользователя хранилище в Почте и настроить новый почтовый ящик именно так, как выбрал администратор домена.
Если для домена включена общая адресная книга, то каждый вызов методов создания или удаления ящика сопровождается дополнительными вызовами API адресной книги на изменение книжки домена. Таким образом, информация о новых адресатах домена моментально становится доступна для поиска. А если включен общий список контактов в jabber’е, то пользователя нужно добавить еще и в список контактов на стороне jabber-сервера.
При подобной интеграции большое значение приобретает время ответа сервисов и обработка возможных возникающих ошибок. В основном ошибки бывают двух видов: сетевые и логические. Для полноты картины посмотрим на список сервисов и особенности интеграции ПДД с ними.
Паспорт
Фактически, это основной источник данных для ПДД, не менее важный чем база данных, а местами даже и более. С Паспортом ПДД общается через внутреннее API по протоколу HTTP. Любые ошибки Паспорта критичны. Если Паспорт вернул ошибку или в общении с Паспортом произошел сбой, мы транслируем ошибку пользователю и отменяем действия, уже выполненные в базе данных или других сервисах. Таким образом, поддерживается транзакционность операций между разными интегрированными сервисами: для каждой команды есть ее антипод — команда отмены операции.
Почта
Это ключевой сервис, которым администратор домена управляет через ПДД. Создание почтового ящика требует большого объема вычислений, поэтому происходит в фоновом режиме. Образуется очередь атомарных операций, необходимых для завершения регистрации: завести ящик, применить основные настройки, заданные для домена и т.п. Сетевые ошибки в этом случае не столь критичны, поэтому в случае проблем операция спокойно откладывается на потом, в еще одну распределенную очередь, обработчики этой очереди старательно пытаются донастроить ящик в течении суток после сбоя.
DNS
Приблизительно каждый третий домен ПДД размещает DNS зону на серверах Яндекса. Ошибки работы с бэкендом DNS считаются критичными только в случае сетевых сбоев и полной невозможности записать в базу. Во всех остальных случаях срабатывают алгоритмы, которые позволяют решить задачу пользователя.
Например, в момент делегирования домена, Яндекс копирует часть записей с прежнего DNS сервера, чтобы пользователю не приходилось выполнять нудную работу по аккуратному переносу зоны. При этом может возникнуть ситуация, когда корневая запись домена имеет тип CNAME, что противоречит стандарту. Пользователь с такой CNAME записью не может включить Яндекс.Почту на своем домене, поэтому при импорте такая запись будет пропущена.
Журналирование и протоколирование
Как и в любом большом хозяйстве, здесь без протоколов никуда. ПДД ведет подробные журналы для всех операций взаимодействия с другими компонентами Яндекса. Часто по этим журналам удается найти проблему до того, как она становится заметна пользователям. За тем, чтобы сервис работал быстро и качественно, следит специальное ПО для мониторинга системных журналов. В случае больших аварий или ошибок, когда время обработки запросов значительно увеличивается или в ответах появляются ошибки, системные администраторы замечают это в течение нескольких минут и приступают к починке в любое время дня или ночи. Но об этом в следующий раз.
Источник: хабр
