Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 1С.

В этой статье мы поговорим о преимуществах и недостатках каждой из архитектур и о том, как можно использовать микросервисы при работе с конфигурациями 1С.

Микросервис или монолит

Два распространённых способа структурирования программного обеспечения называются монолитной и микросервисной архитектурой. Давайте рассмотрим, чем отличаются эти два подхода и когда стоит выбрать один из них.

Программное обеспечение традиционно разрабатывается с использованием монолитной архитектуры (продукты 1С не исключение), в которой вся программа представляет собой единое неделимое целое. Это означает, что любые изменения или обновления приложения требуют модификации и повторного развертывания всего монолита. Монолитные архитектуры часто характеризуются простотой и лёгкостью разработки, особенно для небольших и средних приложений. Однако по мере роста размера и сложности приложения они могут становиться сложными и трудными в обслуживании.

Микросервисная архитектура предполагает разработку приложения в виде набора небольших независимых сервисов. Каждый из них представляет собой отдельную бизнес‑функцию. Сервисы слабо связаны друг с другом и взаимодействуют по сети, обычно используя лёгкие протоколы, такие как HTTP или очереди сообщений. Каждый сервис отвечает за отдельную функцию или функцию приложения и может разрабатываться, развертываться и масштабироваться независимо. Архитектура микросервисов оказывает существенное влияние на взаимодействие приложения и базы данных.

Достоинства и недостатки

Существенным недостатком монолита является то, что внесение изменений в одном месте монолитной программы, может вызвать повреждения в каких‑то других ее частях. Все дело в том, что компоненты в монолите могут иметь не всегда очевидные связи. Не всегда можно понять, чем это дальше при изменении может обернуться.

В связи с этим внесение изменений в коде может занять массу времени и иметь далеко идущие последствия в плане долгой отладки и разбирательства — почему так произошло. От разработчика требуется глубокое понимание внутреннего устройства кода. Для этого необходимо либо глубокое погружение специалистов в проект, либо не менее долгое изучение документации на данное решение.

При этом важно понимать, что падение монолитного приложения зачастую приводит к полной остановке бизнес‑процессов всей компании.

С течением времени бизнес растет, у него появляются какие‑то новые требования, и иногда приходится переиспользовать текущие наработки в каких‑то других проектах или системах. В монолите с этим возникают определенные проблемы — это только дублирование кода решения.

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

Теперь поговорим о недостатках микросервисов. Да, у микросервисной архитектуры множество преимуществ. Мы можем реализовать отдельные сервисы на разных языках с использованием различных библиотек. Но чем больше сервисов, тем сложнее их мониторить, особенно, когда речь заходит о сотнях и тысячах сервисов, то уже начинаются интересные проблемы.

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

Усложняется управление инфраструктурой. Каждый сервис принято запускать на отдельном сервере — это может быть Docker‑контейнер, виртуальная машина или какое‑то железо. Это может усложняться еще и тем, что используются сборки разных дистрибутивов Linux.

Кроме этого, здесь, как и в монолитной архитектуре важно понимать принципы, по которым осуществляется обмен данными между микросерсивами, так как в данной архитектуре также возможны ситуации, когда изменение в одном микросервисе может сказать на работе других компонентов приложения.

Таким образом, у каждого подхода есть свои преимущества и недостатки. Далее давайте поговорим о том, как можно реализовать микросервисную архитектуру с помощью продуктов 1С.

Гонец и агрегатор сервисов

Как известно: Что мертво, умереть не может!

Готовя материал для этой статьи я набрел на пару репозиториев, в которых были интересные проекты, связанные с использованием 1С для построения микросервисной архитектуры. Но один проект последний раз обновлялся 7–8 лет назад, а в описании другого проекта прямо сказано, что он больше не поддерживается.

Однако, я все равно расскажу о каждом из них. Проект Гонец:Микросервисы создан для решения программистами 1С задач, связанных с высокопроизводительными распределенными вычислениями, создания микросервисов, веб‑сервисов и веб‑порталов для работы тысяч пользователей, работы с высокоэффективными базами данных, с использованием синтаксиса языка, похожего, но не ограниченного возможностями языка 1С. Для этого интерпретатор встраивается в решения на языке Go.

Язык Гонец расширяется путем изменения правил синтаксиса в формате YACC, а так же написания библиотек структур и функций на Go, которые могут быть доступны как объекты метаданных в языке Гонец.

Несмотря на довольно интересную задумку, идея не стала популярной и последняя публика на VK странице проекта датируется 2020 годом.

И второй проект это Агрегатор микросервисов.

Агрегатор должен собирать микросервисы (расширения, дополнительные отчеты и обработки) из доступных источников: msrv.tech, infostart.ru, github.com. Также он позволяет искать микросервисы подходящие для вашей конфигурации, устанавливать, обновлять непосредственно из информационной базы.

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

Агрегатор создан в виде дополнительной обработки для управляемых форм 1С и совместим с основными конфигурациями платформы. Важное преимущество — открытый исходный код, что позволяет разработчикам адаптировать и дорабатывать его под свои нужды. Для работы агрегатора используется API от msrv.tech, что обеспечивает стабильную интеграцию с внешними сервисами.

Несмотря на то, что последние изменения в репозитории были выполнены менее года назад, в настоящий момент данный проект не поддерживается. Возможные причины закрытия проекта можно узнать в обсуждении.

А что же есть?

А теперь давайте обсудим те архитектурные решения, которые реально используются при интеграции 1С в микросервисную архитектуру. Здесь прежде всего можно вспомнить использование 1С:Шины, о которой мы писали совсем недавно.

Еще один вариант это использование Python и FastAPI для взаимодействия компонентов. В микросервис, представляющий собой «по классике» контейнер Docker помещается веб сервер, который взаимодействует с 1С. В нем реализована асинхронная функция для обработки post запросов из 1С, которая получает данные и проводит их валидацию.

Далее, наш контейнер через FastAPI взаимодействует с 1С, получая и отправляя данные.

Еще один вариант построения микросервисной архитектуры это использование Apache Kafka для обмена данными с 1С. Здесь общая логика взаимодействия между компонентами будет следующая: У нас из начально участники информационного обмена подписаны на события из Kafka. Когда 1С генерирует сообщение, оно передается Kafka, который в свою очередь отправляет эти данные всем, кто подписан на это событие. В результате потребители получают необходимую информацию. Обратный обмен данными также возможен, то есть 1С тоже может получать данные от других участников информационного обмена.

Заключение

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

Если вам близка тема архитектуры и вы хотите глубже понять, как проектировать сложные системы на базе 1С, обратите внимание на курс «Функциональный архитектор 1С». На странице курса можно записаться на бесплатные уроки.

Рост в IT быстрее с Подпиской — дает доступ к 3-м курсам в месяц по цене одного. Подробнее