Всі можливості, які пропонує ПДР, вимагають інтеграції з різними компонентами продуктів Яндекса і не тільки. По суті своїй, ПДР - це інтеграційний сервіс, який зведе воєдино розрізнені компоненти під управлінням адміністратора домену.
ПДР починається з домена: його потрібно підключити і перевірити, що власник домену та адміністратор ПДР - один і той же чоловік. Трапляється, що домени з тих чи інших причин відключаються від ПДР на рівні DNS. Для підтвердження володіння і для підтвердження статусу домену ми використовуємо систему черг перевірок, що складається з декількох серверів сховища черг перевірок в реляційної СУБД і кластера розподілених блокувань на базі MongoDB.
Щоб не перевантажувати перевірками сервери, на яких розміщені сайти доменів або DNS-сервери зон, кожна наступна перевірка підтвердження відбувається зі зростаючим часовим інтервалом - починаючи з п'яти хвилин і закінчуючи 24 годинами. Перевірки статусів доменів відбуваються частіше - приблизно раз на чотири години з постійними інтервалами часу. Такий підхід дозволяє значно знизити навантаження на Воркер черг перевірок. Як тільки домен підтверджено, його адміністратору стають доступні всі основні функції і він може створювати ящики.
Щоб зберегти універсальний підхід і зменшити число помилок, ми розробили внутрішній API пошти для доменів, який може бути використаний іншими компонентами Яндекса для обміну необхідною інформацією. Так, наприклад, публічний API пошти для доменів - це один з таких компонентів. Виклики публічного API транслюються в універсальні виклики внутрішнього API. Будь-які дії в веб-інтерфейсі ПДР також викликають методи внутрішнього API.
Залежно від необхідних дій обробник викликів внутрішнього API може звертатися до тих чи інших компонентів Яндекса. Основний принцип при проектуванні нової функціональності полягає в тому, щоб не зберігати на боці ПДР інформації, яка вже зберігається десь в іншому місці. Виняток робиться лише для запитів, які критичні до часу виконання, - їх доводиться кешувати.
Наприклад, щоб створити новий поштовий ящик, необхідно в Паспорті завести нового користувача, після чого проинициализировать для цього користувача сховище в Пошті і налаштувати новий поштовий ящик саме так, як вибрав адміністратор домену.
При подібній інтеграції великого значення набуває час відповіді сервісів і обробка можливих виникаючих помилок. В основному помилки бувають двох видів: мережеві і логічні. Для повноти картини подивимося на список сервісів і особливості інтеграції ПДР з ними.
Фактично, це основне джерело даних для ПДР, не менш важливий ніж база даних, а місцями навіть і більше. З Паспортом ПДР спілкується через внутрішнє API по протоколу HTTP. Будь-які помилки Паспорти критичні. Якщо Паспорт повернув помилку або в спілкуванні з Паспортом стався збій, ми транслюємо помилку користувачеві і скасовуємо дії, вже виконані в базі даних або інших сервісах. Таким чином, підтримується транзакційність операцій між різними інтегрованими сервісами: для кожної команди є її антипод - команда скасування операції.
Це ключовий сервіс, яким адміністратор домену управляє через ПДР. Створення поштової скриньки вимагає великого обсягу обчислень, тому відбувається у фоновому режимі. Утворюється чергу атомарних операцій, необхідних для завершення реєстрації: завести ящик, застосувати основні настройки, задані для домену тощо Мережеві помилки в цьому випадку не настільки критичні, тому в разі проблем операція спокійно відкладається на потім, в ще одну розподілену чергу, обробники цієї черги старанно намагаються донастроіть ящик протягом доби після збою.
Приблизно кожен третій домен ПДР розміщує DNS зону на серверах Яндекса. Помилки роботи з бекенд DNS вважаються критичними тільки в разі мережевих збоїв і повної неможливості записати в базу. У всіх інших випадках спрацьовують алгоритми, які дозволяють вирішити задачу користувача.
Наприклад, в момент делегування домену, Яндекс копіює частину записів з колишнього DNS сервера, щоб користувачеві не доводилося виконувати нудну роботу по акуратному переносу зони. При цьому може виникнути ситуація, коли коренева запис домена має тип CNAME, що суперечить стандарту. Користувач з такою CNAME записом не може включити Яндекс.Пошту на своєму домені, тому при імпорті такий запис буде пропущена.
Журнал роботи і протоколювання
Як і в будь-якому великому господарстві, тут без протоколів нікуди. ПДР веде докладні журнали для всіх операцій взаємодії з іншими компонентами Яндекса. Часто за цими журналам вдається знайти проблему до того, як вона стає помітна користувачам. За тим, щоб сервіс працював швидко і якісно, стежить спеціальне ПЗ для моніторингу системних журналів. У разі великих аварій або помилок, коли час обробки запитів значно збільшується або у відповідях з'являються помилки, системні адміністратори помічають це протягом декількох хвилин і приступають до ремонту в будь-який час дня чи ночі. Але про це наступного разу.
Чекаємо ваших запитань!