Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 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С можно эффективно использовать и в микросервисной архитектуре.
