gifts2017

Использование service discovery в 1С

Опубликовал Евгений Сосна (pumbaE) в раздел Администрирование - Системное

Использование service discovery в 1С и как победить рассылки пользователя из тестовой базы.

Дисклаймер

Если у вас нет возможности изменять конфигурации (то есть дорабатывать), то вряд ли вам пригодится данная статья на практике.  

Service dicovery, в контексте данной статьи, подразумевает под собой «управление сервисами».

А есть ли проблема?

Давайте рассмотрим на примере типовой конфигурации УТ 11 (Управление торговлей редакция 11), какие службы, внутренние или же внешние, используются в данной конфигурации.  Навскидку сразу же приходят на ум такие сервисы:

  1. Обмена данными, условно, назовем их внутренними:
    1. Обмен с БП.
    2. Обмен РИБ.
  2. Сервис отправки СМС.
  3. Обмен данными с сайтом, сайтами.
  4. Выгрузка различной отчетности поставщикам, покупателям.
  5. Рассылка отчетов, для внутреннего пользования и внешнего.
  6. Интеграция с документооборотом.
  7. Обмен электронными документами.
  8. Отправка/прием электронной почты.

Настройка всех этих сервисов предполагает сохранения настроек подключения прямо в базе. Для конечного пользователя это, конечно же, очень удобно. Все меняется, когда мы с вами в стадии разработки, хотим сделать копию базы данных и оттестировать необходимый новый функционал или же начинаем разработку на копии базы данных (примечание: ЕБД-шники (Единая База Данных) с терабайтными базами могут с такими проблемами не встречаться).

Копия базы данных с запущенными фоновыми заданиями может сломать вам обмен, может разослать недостоверную информацию клиентам и т. д. Конечно же, это накладывает на нас с вами ограничения «Не забудь отключить фоновые задания, а если я вручную запущу рассылку рекламных СМС в виде теста?» (в моей практике одна из подобных ошибок привела к отсылке 900 тестовых страховок в сторону реального провайдера страховых полисов). Каждый раз, когда запускаем копию базы данных на другом сервере 1С предприятия, мы с вами должны помнить об отключении всех фоновых заданий, необходимо на всякий случай пройтись по всем настройкам и изменить их или же удалить, т. к. случайное нажатие или тест может нам все испортить в реальной работе.


В каком окружении мы в этот момент находимся

Проблема в том, что, работая с базой данный в 1с, мы с вами не знаем, в каком же окружении мы в этот момент находимся, в development или production или же testing (stage).

Но даже если мы определили, что находимся в разработке, как определить, что нам не надо отослать тестовое сообщение или проверить правильность обмена данными?  

Для еще большего понимания возможных коллизий добавим:

  • может иметься три различных окружения (и четвёртое - если мы тестируем производительность, или пятое — если мы создали пилотный контур);
  • количество сервисов/служб/интегрируемых систем может быть N, и каждая имеет вышеуказанные 5 различных окружений;
  • если еще добавить, что каждый разработчик имеет свое development окружение, а разработчиков может быть M.

Тогда количество возможных сочетаний N×M×5.


Решение в лоб №1 - константа Self

 Устанавливаем в константе текущее имя базы данных и в случае работы фонового задания на обмен, отправку сообщений и т. д., при несоответствии строки подключения с записанной константой делать исключение. Строка подключения рабочей базы чаще всего отличается от строки подключения development или тестовой базы. Проблема данного решения в том, что при необходимости протестировать или доработать один из сервисов, изменяя константу, мы автоматом запускаем все остальные сервисы в работу.


Решение в лоб №2 - Песочница

Полностью дублируем инфраструктуру, а для внешних сервисов запрашиваем адреса контуров типа sandbox. Такой подход еще называется “Поиграем в магазин” или “Интеграционное тестирование”. Проблем здесь тоже достаточно - автоматизировать такое долго, ресурсы дублирующие рабочее окружение дорогие, да и внешние провайдеры иногда даже не имеют контуров для тестирования. Добавьте к этому еще и сокращение сроков выпуска функциональности - так как каждый релиз требует сбора всей команды и полную проверку. Я уже не говорю, что обновление production тоже должно происходить массово, как только одно из обновлений ошибочно, откатывать придется все системы/сервисы.

А может, попробовать аккумулировать все настройки в едином месте?

Внутреннее централизованное хранилище

Создать справочники «Настройки обменов» и для каждой строки подключения создать элемент справочника и поместить туда сериализированное значение настроек. Потом, конечно, захочется добавить так называемый роутинг, иерархическую структуру, в зависимости от вида настройки, потому как все настройки хранить в одной структуре неудобно и так далее.

Использовать внешние по отношению к 1с сервисы

Можно использовать мировой опыт по управлению сервисом, например, опыт того же google. У них даже еще  большая проблема, чем в 1с, т. к. сразу пытаются решить проблему использования сервисов в различных дата-центрах, балансировки и т. д. Если поискать понятие service-discovery, то найдем довольно много информации из мира docker/OpenStack, там тоже сталкиваются с тем, что различные микро-сервисы должны связываться друг с другом, при этом в различных вариантах работы (production, development, testing).

Основной принцип service-discovery — различные сервера регистрируют свои сервисы в центральном хранилище, чаще простое key-value хранилище. При этом доступ к параметрам этих сервисов можно получить с помощью dns запроса, а так же простым HTTP запросом и в ответ получить JSON. Например, настройка сервиса обмена с документооборотом сводится к тому, что вместо адреса «docflow.demo.1c.ru/docflow_trade/» мы указываем базовый адрес «docflow.consul.local» и для запроса добавляем уже имя базы данных из строки подключения, в итоге у нас с вами будет «http://ut11.docflow.prod.skydns.local», а для базы разработки будет «ut11_dev.docflow.prod.skydns.local», но т. к. в службе сервисов по данному DNS имени не будет зарегистрировано ни одной службы, то и ошибочного обмена у нас с вами никакого не произойдет.

Можно выделить два программных продукта по управлению сервисами, первый consul и второй etcd в связке с skydns.  У consul содержит в себе уже и dns сервер и key/value хранилище, во втором примере etcd выступает как key/value хранилище, а skydns сервером dns, берущего настройки из etcd.

Принцип работы с данным службами прост и описан в документации, но хотелось бы выделить некоторые особенности.


Consul - Service discovery и 1С

Все настройки сервисов в Consul хранятся в JSON файлах, можно данные файлы хранить в системах контроля версий.

consulconfig.png

Честного роутинга не получилось добиться в consul , т.е. указать адрес для “ut11.docflow.service.consul” и для “ut11_dev.docflow.service.consul” не получилось, поэтому при использовании consul пользуюсь объединением без точки ut11_devdocflow.service.consul.

consuldemo.png

В то же время, у Consul приятный web интерфейс, что позволяет быстрее увидеть красивую картинку.

SkyDNS+ETCD - особенности

Основное неудобство, по сравнению с consul, - это необходимость запуска сервисов в строгой последовательности и отсутствие в etcd поддержки 32-битных систем, но позволяет более красиво оформлять путь к сервисам, для регистрации такого сервиса  ut11.docflow.services.skydns достаточно выполнить команду

etcdctl set /skydns/services/docflow/ut11 ‘{“host”:”docflow.1c.ru’}

У Skydns основное преймущество, по сравнению с Consul, это поддержка PTR записей в dns-службе.

Выводы

Использовать или нет, это вам решать. Надеюсь, на данном примере я смог показать, как будет больно, если вся наша автоматизация сработает, но с неправильными или устаревшими данными. Необходимость создания страховки от несчастного случая заставляет нас с вами делать дополнительные телодвижения и добавлять еще один сервис, который необходимо поддерживать. Поддержка заключается в описании дополнительных служб, которые мы используем, и даже это позволяет нам заявлять о документировании используемых служб. Что, поверьте, не бесполезно.

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Дмитрий Г (Дмитрий74Чел) 06.02.15 11:47
Контратака Хабра на Инфостарт? Я ничего не понял. :-(
2. Евгений Сосна (pumbaE) 06.02.15 12:00
(1) Дмитрий74Чел, вы разве никогда не сталкивались с ошибочной работой фоновых заданий или даже пользователей из копии базы?
Один из вариантов решения данной проблемы, это подмена путей, адресов по которым будет происходить работа. Для удобства администрирования этих путей можно поднять свой dns сервер, но т.к. не всегда все настройки можно впихнуть в одну строку, то дополнительно хотелось бы и какое-то нестандартизированное хранилище иметь.

p.s.: никто не мешает, вам в конфигурации создать свою константу, свой справочник с настройками и закрыть вопрос полностью 1с.
3. Евгений Ванжула (minimajack) 06.02.15 12:25
(2) pumbaE, отличное решение проблемы.
4. Сергей (necropunk) 06.02.15 17:40
Интересное решение, да. На досуге подумаю над возможностями..
5. rtnm rtnm (rtnm) 06.02.15 21:36
Мы делаем так http://infostart.ru/public/280357/. Это простое решение похожее на "Решение в лоб №1". Но с помощью него мы можем контролировать запуск каждого механизма по отдельности и при необходимости перенастроить и разрешить запуск только нужного нам.
6. Евгений Ванжула (minimajack) 06.02.15 21:49
(5) rtnm, перенастраивать и запускать не путь джедаев.
По идее будет достаточно один раз прописать заглушку для демо базы и забыть...
в вашем случае придется контроллировать "что-можно" постоянно.
7. rtnm rtnm (rtnm) 06.02.15 21:52
(6) minimajack, контролировать постоянно ничего не придется, придется перенастраивать в случае необходимости протестировать, но эту цену мы осознаем.
8. Евгений Ванжула (minimajack) 06.02.15 21:58
(7) rtnm, фраза перенастраивать совсем не вяжется с демоконфигурацией, где фактически все необходимо тестировать на заглушках...
если вы тестируете на реальных сервисах мне жаль...для этого существуют мокапы
9. Евгений Сосна (pumbaE) 06.02.15 22:31
(6), (7) риск переустановки/переезда сервера vs риск забыть отключить фоновые задания(убрать настройки) и все это умножить на затратры, или же сложность установки/поддержки vs реализации на родном 1с (легко и просто). Это выбор каждого.
Изначально я тоже пользовался решением "в лоб", после появления 2х контуров (тест, 3 разработчика каждый со своей базой) понял, что надо искать альтернативу.
10. Евгений Ванжула (minimajack) 06.02.15 22:37
(9) pumbaE, полностью с вами согласен. Возможно это решается проще - с внедрением DI(динамическим конфигурированием), но это уже за гранью обсуждения, хотя и близко с публикацией.
11. ффф ыыы (zqzq) 22.04.15 08:20
Есть ещё один путь - за выполнение заданий отвечает отдельная база. Связь с другими базами, например, через com. У меня так обмены работают. Плюсы: всё в одном месте для нескольких баз (включая логи обменов и отправку сообщений об ошибках), не нужно менять конфигурации баз, при РИБ можно ещё прописать обновление конфигурации БД. Минусы: базы должны быть доступны через com, должен быть программный интерфейс для com (обычно есть).
Вот ещё более сложный пример (не работал с этим): http://infostart.ru/public/145983/
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа