В 2016 году «1С» презентовала Систему взаимодействия (СВ). Этот платформенный механизм передает информацию между клиентскими приложениями и серверами 1С:Предприятия.
Онлайн-сервис СВ запустили весной 2017 года, а осенью того же года вышел отдельный продукт. Теперь разработчики раскрыли, как создавали Систему взаимодействия от постановки задачи до деталей реализации.
Для чего нужна система взаимодействия
Система взаимодействия предназначена для автоматизации бизнес-процессов предприятия или помощи в их осуществлении. Взаимодействия могут быть программными и интерактивными. К последним относится обмен сообщениями между пользователями 1С:Предприятия, тематические обсуждения, аудио- и видеозвонки другим пользователям.
СВ отличает отказоустойчивость и гарантированная доставка сообщений. Пользователям она доступна и как онлайн-сервис, и как тиражный продукт, развертываемый на серверных мощностях предприятия. При этом разработчики советуют небольшим компаниям пользоваться сервером СВ из облака, чтобы избежать лишних расходов. Крупным предприятиям рекомендуют установить собственный сервер СВ.
Обмен сообщениями в СВ
Постановка задачи
На этапе постановки задачи разработчики учитывали принципы создания бизнес-приложений 1С. Такие приложения на базе «1С:Предприятия» работают в клиент-серверной архитектуре: «СУБД – сервер приложений – клиент». Написанный на встроенном языке 1С код может выполняться на сервере приложений или на клиенте.
Только на сервере выполняется вся работа с прикладными объектами, там же реализована функциональность форм и командного интерфейса. На клиенте выполняются полученные формы, небольшие отчеты и работа с локальными файлами. Поэтому в прикладном коде обязательно указывать, где именно он будет выполняться.
Но здесь есть ряд ограничений: из клиентского кода вызвать серверный код можно, а из серверного кода клиентский – нет. Это значит, что передать сообщение (например, о готовности отчета) с сервера в клиентское приложение нельзя. Чтобы решить эту проблему, приходилось периодически опрашивать сервер и загружать систему лишними вызовами.
На помощь пришел механизм СВ и разработанный на его базе мессенджер. Он также необходим, если понадобится при поступившем телефонном SIP-звонке оповестить об этом клиентское приложение. После оповещения оно по номеру звонящего нашло его в базе контрагентов и показало пользователю информацию о звонящем контрагенте. Систему проектировали горизонтально масштабируемой, когда производительность увеличивается за счет разделения данных на множество серверов.
Вызов серверной процедуры с клиента сработает, вызов клиентской процедуры с сервера — нет
Elasticsearch и Hazelcast в СВ
При реализации механизма серверную часть СВ решили не встраивать в платформу «1С:Предприятие», создав отдельный продукт. В этом случае его интерфейс можно вызывать из кода прикладных решений 1С, обмениваясь сообщениями в рамках разных приложений (Управления Торговлей и Бухгалтерией, например).
Мессенджеру необходимы поисковый движок (если понадобится найти сообщение) и распределенное хранилище. При создании СВ разработчики отдали предпочтение платформе Hazelcast и поисковой системе Elasticsearch.
Hazelcast – платформа со встроенной памятью данных с открытым исходным кодом. Она поддерживает автоматическое обнаружение узлов и интеллектуальную синхронизацию. Среди положительных характеристик – масштабируемость, отказоустойчивость и распределенность. Разработчики «1С» использовали его в качестве хранилища пользовательских сессий, за которыми не нужно будет обращаться к базе, и в качестве кэша, где можно будет отыскать пользователя или нужное сообщение.
Поисковой системой выбрали Elasticsearch: подобные движки используются при сложном поиске по базе документов. В СВ Elasticsearch обеспечила быстрый и гибкий поиск с учетом морфологии. В индекс поисковой системы внесли корни слов и N-граммы. Пока пользователь набирает текст для поиска, Elasticsearch ищет его среди N-грамм. Так, поиск слова «тексты» в СВ будет осуществляться по любой из его частей, благодаря дроблению на N-граммы [те, тек, текс, текст, тексты, ек, екс, екст, ексты, кс, кст, ксты, ст, сты, ты].
Архитектура системы взаимодействия
Выбор СУБД
В качестве системы управления базой данных для СВ выбрали PostgreSQL, аргументируя выбор большим и успешным опытом работы с ней. Это ПО используется для структурированного хранения данных и получения доступа к этим данным с помощью SQL-запросов. Основные преимущества PostgreSQL – бесплатность и высокая скорость работы.
PostgreSQL необходимо масштабировать: для этого выбрали стратегию шардинга, в рамках которой информация из общей БД делится на блоки и распределяется по разным серверам. У СВ есть главная БД: она хранится в таблице роутинга с информацией о локации всех абонентских баз данных.
Распределение базы данных
Чтобы сообщения пользователей не терялись, базу данных поддерживают репликами: синхронной и асинхронной. В этом случае сообщения потеряются, только если произойдет одновременный отказ основной БД и ее синхронной реплики.
Тесты и эксплуатация
Перед выпуском каждый релиз СВ проходит нагрузочное тестирование. Команда разработчиков считает его успешно пройденным, когда:
- тест после нескольких суток работы не дает отказов;
- время отклика по ключевым операциям не превышает комфортного порога;
- производительность по сравнению с предыдущей версией не ухудшается более чем на 10%.
Тестовая база наполняется данными, а само тестирование проводится в трех конфигурациях:
- стресс-тест;
- только подключения;
- регистрация абонентов.
За год эксплуатации разработчики не выявили серьезных проблем в работе онлайн-сервиса. Дистрибутив сервера Системы взаимодействия поставляется в виде нативных пакетов, а для Windows «1С» предоставляет единый инсталлятор. Он устанавливает сервер, Hazelcast и Elasticsearch на одну машину.