Недавно мне дали тестовое задание на проектирование интеграции между 1С и Yandex 360. На первый взгляд задача выглядела достаточно прямолинейно: 1С формирует письмо, дальше его нужно передать в почтовую систему, отправить и получить информацию о результате. Но в исходном ТЗ не было отдельного сервиса на Go. Я добавил его сам. И в этой статье хочу разобрать не столько само тестовое задание, сколько процесс принятия архитектурного решения: зачем вообще добавлять ещё один компонент и в какой момент он действительно оправдан. Потому что сделать архитектуру из нескольких сервисов несложно. Гораздо сложнее объяснить, зачем каждый из них нужен.
Что было в задаче
Есть 1С, из которой необходимо отправлять электронные письма через Yandex 360.
При этом недостаточно просто сделать:
1С → Yandex 360 → письмо отправлено
В процессе возникают вполне обычные для интеграций проблемы:
внешний сервис может быть временно недоступен;
запрос может завершиться таймаутом;
ответ может не прийти, хотя операция уже была выполнена;
одну и ту же операцию нельзя бездумно выполнять повторно;
нужно понимать текущее состояние письма;
нужна история обработки;
после перезапуска сервиса состояние не должно потеряться;
необходимо получать информацию о результате отправки.
И вот здесь начинается самое интересное.
Самый простой вариант
Первое, что приходит в голову:
1С │ ▼ Yandex 360
1С формирует письмо и непосредственно обращается к внешней системе. Для небольшой системы это вполне может быть нормальным решением. Я бы не стал автоматически добавлять между ними ещё один сервис только потому, что «так правильнее». Но у прямого взаимодействия появляется несколько вопросов.
Что делать с повторной отправкой?
Допустим, 1С отправила запрос, Yandex 360 принял письмо, Но ответ до 1С не дошёл из-за сетевого сбоя.
1С видит:
timeout
и повторяет запрос.
Что произойдёт?
Если архитектура никак не учитывает повторную обработку одной и той же операции, получатель потенциально может получить два одинаковых письма. Самое неприятное здесь в том, что для 1С первый запрос выглядит неуспешным, хотя операция на самом деле могла выполниться.
Это классическая проблема распределённых систем: мы не всегда можем точно определить, что произошло на другой стороне после сетевого сбоя.
Я решил разделить ответственность
Вместо прямого взаимодействия я предложил промежуточный сервис:
┌─────────────┐ │ 1С │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Go-сервис │ └──────┬──────┘ │ ┌────▼─────┐ │ DB │ └────┬──────┘ │ ▼ ┌─────────────┐ │ Yandex 360 │ └─────────────┘
Важно ещё раз подчеркнуть: Go-сервиса в ТЗ не было. Это моё архитектурное решение. Поэтому его появление нужно было обосновать. Главная идея была достаточно простой: не заставлять 1С заниматься всей механикой взаимодействия с внешним почтовым сервисом.
Для 1С интерфейс можно свести примерно к следующему:
«Вот письмо с таким идентификатором. Прими его в обработку».
А дальше уже сервис занимается своей частью работы:
сохраняет письмо, ставит его в очередь, выполняет отправку, повторяет попытки при необходимости, хранит текущее состояние, сохраняет историю, взаимодействует с Yandex 360, восстанавливает обработку после перезапуска.
Получается граница ответственности:
1С │ │ «Отправь это письмо» ▼ Go │ ├── сохранить ├── поставить в очередь ├── отправить ├── повторить при необходимости ├── проверить результат └── сохранить историю
При этом 1С не нужно знать, сколько раз сервис пытался отправить письмо, почему произошёл timeout и что происходило с worker'ом после перезапуска.
Почему я не стал добавлять отдельный брокер
Здесь начинается первый архитектурный компромисс. Можно было сразу добавить RabbitMQ, Kafka или другой брокер:
1С │ ▼ Go API │ ▼ RabbitMQ │ ▼ Worker │ ▼ Yandex 360
Выглядит уже гораздо более «архитектурно». Но возникает простой вопрос: а действительно ли нам это нужно? Если объём сообщений и требования к системе не требуют отдельного брокера, мы получаем дополнительную инфраструктуру, которую тоже нужно: устанавливать, настраивать мониторить, обновлять, резервировать, восстанавливать.
И самое главное — появляется ещё один компонент, за который нужно отвечать. Поэтому в тестовом я выбрал более простой вариант: состояние очереди хранится в базе данных. То есть база здесь — не просто хранилище писем. Она одновременно хранит состояние обработки.
Например, условно:
ready ↓ sending ↓ sent
или:
ready ↓ sending ↓ failed ↓ sending ↓ sent
Для поставленной задачи этого было достаточно.
Почему GUID не стал первичным ключом
У письма есть внешний идентификатор — GUID.
На первый взгляд логично сделать:
guid PRIMARY KEY
Но я предпочёл разделить внешний и внутренний идентификаторы:
id — внутренний идентификатор записи в БД guid — идентификатор, пришедший из внешней системы
Это разные сущности по смыслу.
id нужен самой базе данных.
guid нужен для связи с внешней системой и, в том числе, для контроля повторной обработки.
Например, 1С может повторно прислать письмо с тем же GUID.
Сервис должен уметь определить:
Такая логическая операция уже существует.
И вместо создания второй записи обработать существующую. При этом наличие GUID само по себе не решает проблему дублей при взаимодействии с внешним сервисом. Для этого нужна вся совокупность механизмов: состояние операции, проверки, правила повторной обработки и понимание того, на каком этапе произошёл сбой.
Текущее состояние и история — не одно и то же
Следующий вопрос: достаточно ли одного поля status?
Например:
emails.status = sent
Этого достаточно, если нас интересует только текущее состояние.
Но со временем появляются вопросы: когда письмо было создано? когда началась отправка сколько было попыток? когда произошла ошибка? когда была выполнена повторная попытка когда операция завершилась?
Поэтому я разделил текущее состояние и историю.
Условно:
emails
хранит текущее состояние.
А:
email_events
хранит события.
Например:
created ↓ ready ↓ sending ↓ failed ↓ retry ↓ sending ↓ sent
В итоге можно быстро узнать текущее состояние:
письмо отправлено
и отдельно восстановить историю:
первая попытка завершилась ошибкой, после чего была выполнена повторная.
Что происходит при ошибке?
Предположим, Yandex 360 временно недоступен.
Worker пытается отправить письмо:
sending ↓ timeout ↓ failed
Но failed в данном случае не обязательно означает:
больше никогда не пытаться.
Можно хранить количество попыток и повторять обработку.
Например:
attempt = 1 attempt = 2 attempt = 3
Количество попыток и параметры timeout при этом имеет смысл вынести в конфигурацию. Не потому, что «всё должно быть конфигурируемым», а потому что параметры взаимодействия с внешней системой могут потребовать изменения без изменения самого алгоритма обработки.
Самый неприятный случай — timeout
На самом деле retry сам по себе не решает проблему.
Представим:
Go → Yandex 360
Yandex 360 принял запрос.
Но ответ потерялся.
Go получает:
timeout
Что теперь делать?
Если просто повторить запрос:
retry
мы потенциально можем получить дубль. Но и не повторять запрос автоматически тоже нельзя: письмо могло не дойти.
Получается неприятная ситуация:
мы не знаем, завершилась операция или нет.
Именно здесь особенно важна идемпотентность и возможность определить состояние конкретной операции. Поэтому архитектура должна учитывать не только успешные ответы, но и неопределённые состояния. Это, пожалуй, одна из самых важных вещей в интеграциях: ошибка сетевого запроса не всегда означает ошибку бизнес-операции.
Что произойдёт после перезапуска?
Ещё один вопрос, который легко забыть в тестовом:
Что произойдёт, если worker упал?
Если очередь находится только в памяти процесса:
Go memory ↓ queue
после перезапуска состояние потеряно.
Если состояние обработки находится в БД:
DB │ ├── ready ├── sending ├── failed └── sent
после перезапуска можно определить, какие записи ещё требуют обработки.
Конечно, здесь тоже нужно отдельно продумать состояние sending: если процесс умер непосредственно во время отправки, нельзя просто слепо считать такую запись неотправленной и повторить запрос. Но само хранение состояния в БД уже позволяет переживать обычный перезапуск процесса без потери очереди.
А зачем тогда отдельная таблица событий?
Потому что текущее состояние и история решают разные задачи.
Например:
emails.status = sent
говорит только:
сейчас письмо отправлено.
А журнал событий позволяет ответить на вопросы:
created sending failed retry sending sent
Это полезно не только для отладки.
История помогает анализировать: количество ошибок, количество повторных попыток, время обработки, причины сбоев, поведение внешнего сервиса. То есть события становятся не просто логом для разработчика, а частью данных системы.
А что делать со статистикой?
Здесь я тоже старался не добавлять отдельные компоненты без необходимости. Если необходимые данные уже находятся в БД, а задача — мониторинг и статистика, отдельный API только ради Grafana может оказаться лишним.
В таком варианте:
DB │ └── Grafana
может быть вполне достаточно.
Получается ещё один простой принцип:
если существующий компонент уже решает задачу, не нужно автоматически создавать новый.
Почему Go?
И здесь важно не превратить статью в рекламу языка. Подобный сервис можно написать не только на Go. Подойдут PHP, Java, Python, Node.js и другие технологии.
Go в данном случае удобен для небольшого отдельного сервиса с: HTTP API, worker'ом, сетевыми запросами, длительно работающим процессом, небольшим количеством зависимостей. Но выбор языка здесь вторичен.
Главный вопрос был не:
«На каком языке написать микросервис?»
А:
«Нужен ли здесь вообще отдельный сервис?»
Это принципиально разные вопросы.
Когда такой сервис был бы лишним?
Например, если система: отправляет небольшое количество писем, не требует сложной обработки ошибок, допускает повторные отправки, не требует истории, не нуждается в отдельном мониторинге, может выполнять всю необходимую логику непосредственно в 1С.
Тогда схема:
1С → Yandex 360
может быть вполне нормальной. Добавлять Go только ради красивой архитектурной диаграммы смысла нет.
Где проходит граница?
Для меня она проходит примерно здесь.
Если дополнительный сервис решает конкретные проблемы:
идемпотентность + очередь + retry + восстановление + история + изоляция внешнего API
его появление можно обосновать.
Если же аргумент звучит:
«Давайте сделаем микросервис, потому что микросервисы — это современно»,
то это уже архитектура ради архитектуры. Причём проблема не в микросервисах как таковых. Проблема в отсутствии причины.
Что в итоге получилось
В моём варианте архитектура выглядит примерно так:
┌──────────────┐ │ 1С │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Go API │ └──────┬───────┘ │ ┌──────▼───────┐ │ DB │ │ │ │ emails │ │ email_events │ │ campaigns │цц │ sync_state │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Worker │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Yandex 360 │ └──────────────┘
цПри этом каждый компонент появился не потому, что его хотелось добавить в архитектурную схему. У каждого есть конкретная задача.
И главный вывод
Для меня это тестовое получилось интересным именно потому, что в нём не было готового требования:
«Добавьте сервис на Go».
Его пришлось придумать самому и затем объяснить. И это, пожалуй, одна из самых полезных вещей в архитектуре: не просто придумать сложную систему, а суметь объяснить, зачем каждый её компонент вообще существует.
Иногда подходящей архитектурой будет:
1С → сервис → очередь → worker → внешний API
А иногда:
1С → внешний API
Обе схемы могут быть оправданы в разных условиях. Вопрос не в количестве компонентов. Вопрос в том, какую конкретную проблему каждый из них решает.
