Комментарий к архитектурной схеме Synplity
Комментарий к архитектурной схеме Synplity
Платформа имеет микросервисную архитектуру. Все микросервисы запускаются через Docker. Кластер Docker-микросервисов администрируется через Kubernetes. Физические сервера в любом количестве на OS Linux включаются в этот кластер. Набор готовых микросервисов для обеспечения работы архитектуры:
Service Discovery / Config-server (sp-eureka) (не обязателен, может замещаться функционалом Kubernetes);
API Gateway (sp-backend);
Authorization Server (sp-uaa).
Также в платформу включены микросервисы для обеспечения работы бизнес-логики:
sp-core и sp-workbench - для запуска и работы с бизнес-процессами;
sp-messaging - для real-time взаимодействий фронтовым приложением;
sp-scheduler - для выполнения задач по таймерам и расписаниям;
sp-audit - для создания, регистрации, хранения и просмотра событий согласно бизнес-процессам;
sp-storage - для работы с файловым хранилищем;
sp-reference - для создания и оперирования простыми key-value справочниками в бизнес-процессах.
Межсервисное взаимодействие происходит по http для синхронных вызовов, для асинхронных вызовов - через Kafka. Все микросервисы свободно масштабируются под нагрузку либо через увеличение количества инстансов, либо выделением бОльших ресурсов памяти и процессоров.
В платформу могут быть включены любые новые микросервисы для реализации требуемого функционала, будь то сложные интеграции с внешними системами и отдельные БД или сервисы собственной разработки с новым функционалом. Процесс создания новых микросервисов максимально упрощён, для этого используются готовые библиотеки, разбитые по техническим аспектам работы платформы:
1) dependency management;
2) утилиты;
3) security;
4) многопоточная разработка;
5) логирование;
6) мониторинг/метрики;
7) веб;
8) межсервисное взаимодействие REST/Kafka;
9) обработка ошибок;
10) cloud config & service-discovery;
11) кеширование;
12) тестирование;
13) шаблоны адаптации внешних REST/SOAP/MQ;
14) api-contract для использования sp-core;
15) аудит;
16) batch-операции.
Все библиотеки используют open source фреймворк Spring, большая часть из них являются Spring Boot компонентами, т.н. starter'ы. Это позволяет запустить микросервис в платформе со всем нужным функционалом без написания дополнительных конфигураций, просто подключив библиотеки. Благодаря доступным компонентам, предоставляющим часто используемые и общепринятые инструменты на Java, можно сосредоточиться на реализации бизнес-логики быстро и эффективно, снижая порог вхождения для программистов. Кроме этого, библиотеки и open source компоненты позволяют унифицировать кодовую базу, что само по себе хорошо, но также позволяет обновлять и изменять платформу под специфичные требования с минимальными трудозатратами на обновление компонентов, тестирование и переписывание конфигураций во всех микросервисах.
Основной упор в платформе сделан на гибкость и скорость разработки. Библиотеки - побочная часть, затрагивающая низкоуровневую разработку на java. Основная часть платформы — это движок бизнес-процессов и микросервисы sp-core, sp-workbench.
Sp-core предоставляет REST-api для веб-приложений, состоящий из трёх методов: начать бизнес-процесс, получить бизнес-процесс, перейти на другой шаг бизнес-процесса. Этого api хватает для реализации интерфейса бизнес-процесса любой сложности, в т.ч. покрывает потребности и по простому выводу информации на экран. Таким образом снижается необходимость обновлять/перезапускать web-приложение из-за необходимости вызывать новые или изменённые api сторонних сервисов, могут использоваться билдеры интерфейса. Из REST api sp-workbench разработчик front-приложения может получить описание бизнес-процесса, в котором указаны шаги бизнес-процесса, атрибуты каждого шага, возможные переходы в другой шаг, переходы обычно привязываются к кнопкам на интерфейсе. Входной точкой для экрана интерфейса в веб-приложении может служить специальный тип бизнес-процесса - системный. Такой бизнес-процесс часто служит индивидуальным стартовым рабочим экраном пользователя и доступен по умолчанию, с него можно перейти в любые другие бизнес-процессы или начать новые.
Разработка бизнес-процесса состоит из двух частей - создания модели графа бизнес-процесса и написания groovy-скриптов с логикой для вершин и ребер графа. Обе части могут изменяться в рантайме, без перезапусков sp-core, что ускоряет разработку, тестирование и исправления. Любая часть легко заменяется, временные моки для данных позволяют обходить проблемы с ожиданием нужного api от внешних систем или внутренней разработки.
Использование groovy позволяет создавать DSL, снижая при необходимости порог вхождения для изменений в процессах до людей незнакомых с программированием. Вплоть до того, что можно разработать бизнес-процесс, позволяющий разрабатывать новые бизнес-процессы. Для разработчиков groovy позволяет с лёгкостью реализовывать рутинные операции, упрощая и сокращая код - проверки данных, создание объектов, маппинг и агрегацию данных. Также, для разработчиков доступен фреймворк поддержки работы в любой IDE, позволяющий с удобством разрабатывать и тестировать скрипты, использовать версионирование через Git, а также плагин для Maven, позволяющий реализовывать CI/CD для разрабатываемых бизнес-процессов.
В контексте скриптов бизнес-процесса для разработчика доступны инструменты для управления текущим и сторонним бизнес-процессами. Бизнес-процесс может создавать другие бизнес-процессы, обращаться к существующим, переходить в них, ожидать их завершения, запускать параллельные процессы, автоматически совершать переходы. Таким образом, не все бизнес-процессы требуют интерфейса, и могут быть полностью автоматизированными, что часто используется для реализации сценариев RPA. Скрипты могут быть не только для бизнес-процессов, но и в виде утилит, что позволяет переиспользовать код в разных бизнес-процессах, упрощая разработку с ростом кодовой базы.
Благодаря перечисленным возможностям api, моделей бизнес-процессов, использования groovy-скриптов и java-библиотек достигается максимальная гибкость и скорость разработки.
Платформа имеет микросервисную архитектуру. Все микросервисы запускаются через Docker. Кластер Docker-микросервисов администрируется через Kubernetes. Физические сервера в любом количестве на OS Linux включаются в этот кластер. Набор готовых микросервисов для обеспечения работы архитектуры:
Service Discovery / Config-server (sp-eureka) (не обязателен, может замещаться функционалом Kubernetes);
API Gateway (sp-backend);
Authorization Server (sp-uaa).
Также в платформу включены микросервисы для обеспечения работы бизнес-логики:
sp-core и sp-workbench - для запуска и работы с бизнес-процессами;
sp-messaging - для real-time взаимодействий фронтовым приложением;
sp-scheduler - для выполнения задач по таймерам и расписаниям;
sp-audit - для создания, регистрации, хранения и просмотра событий согласно бизнес-процессам;
sp-storage - для работы с файловым хранилищем;
sp-reference - для создания и оперирования простыми key-value справочниками в бизнес-процессах.
Межсервисное взаимодействие происходит по http для синхронных вызовов, для асинхронных вызовов - через Kafka. Все микросервисы свободно масштабируются под нагрузку либо через увеличение количества инстансов, либо выделением бОльших ресурсов памяти и процессоров.
В платформу могут быть включены любые новые микросервисы для реализации требуемого функционала, будь то сложные интеграции с внешними системами и отдельные БД или сервисы собственной разработки с новым функционалом. Процесс создания новых микросервисов максимально упрощён, для этого используются готовые библиотеки, разбитые по техническим аспектам работы платформы:
1) dependency management;
2) утилиты;
3) security;
4) многопоточная разработка;
5) логирование;
6) мониторинг/метрики;
7) веб;
8) межсервисное взаимодействие REST/Kafka;
9) обработка ошибок;
10) cloud config & service-discovery;
11) кеширование;
12) тестирование;
13) шаблоны адаптации внешних REST/SOAP/MQ;
14) api-contract для использования sp-core;
15) аудит;
16) batch-операции.
Все библиотеки используют open source фреймворк Spring, большая часть из них являются Spring Boot компонентами, т.н. starter'ы. Это позволяет запустить микросервис в платформе со всем нужным функционалом без написания дополнительных конфигураций, просто подключив библиотеки. Благодаря доступным компонентам, предоставляющим часто используемые и общепринятые инструменты на Java, можно сосредоточиться на реализации бизнес-логики быстро и эффективно, снижая порог вхождения для программистов. Кроме этого, библиотеки и open source компоненты позволяют унифицировать кодовую базу, что само по себе хорошо, но также позволяет обновлять и изменять платформу под специфичные требования с минимальными трудозатратами на обновление компонентов, тестирование и переписывание конфигураций во всех микросервисах.
Основной упор в платформе сделан на гибкость и скорость разработки. Библиотеки - побочная часть, затрагивающая низкоуровневую разработку на java. Основная часть платформы — это движок бизнес-процессов и микросервисы sp-core, sp-workbench.
Sp-core предоставляет REST-api для веб-приложений, состоящий из трёх методов: начать бизнес-процесс, получить бизнес-процесс, перейти на другой шаг бизнес-процесса. Этого api хватает для реализации интерфейса бизнес-процесса любой сложности, в т.ч. покрывает потребности и по простому выводу информации на экран. Таким образом снижается необходимость обновлять/перезапускать web-приложение из-за необходимости вызывать новые или изменённые api сторонних сервисов, могут использоваться билдеры интерфейса. Из REST api sp-workbench разработчик front-приложения может получить описание бизнес-процесса, в котором указаны шаги бизнес-процесса, атрибуты каждого шага, возможные переходы в другой шаг, переходы обычно привязываются к кнопкам на интерфейсе. Входной точкой для экрана интерфейса в веб-приложении может служить специальный тип бизнес-процесса - системный. Такой бизнес-процесс часто служит индивидуальным стартовым рабочим экраном пользователя и доступен по умолчанию, с него можно перейти в любые другие бизнес-процессы или начать новые.
Разработка бизнес-процесса состоит из двух частей - создания модели графа бизнес-процесса и написания groovy-скриптов с логикой для вершин и ребер графа. Обе части могут изменяться в рантайме, без перезапусков sp-core, что ускоряет разработку, тестирование и исправления. Любая часть легко заменяется, временные моки для данных позволяют обходить проблемы с ожиданием нужного api от внешних систем или внутренней разработки.
Использование groovy позволяет создавать DSL, снижая при необходимости порог вхождения для изменений в процессах до людей незнакомых с программированием. Вплоть до того, что можно разработать бизнес-процесс, позволяющий разрабатывать новые бизнес-процессы. Для разработчиков groovy позволяет с лёгкостью реализовывать рутинные операции, упрощая и сокращая код - проверки данных, создание объектов, маппинг и агрегацию данных. Также, для разработчиков доступен фреймворк поддержки работы в любой IDE, позволяющий с удобством разрабатывать и тестировать скрипты, использовать версионирование через Git, а также плагин для Maven, позволяющий реализовывать CI/CD для разрабатываемых бизнес-процессов.
В контексте скриптов бизнес-процесса для разработчика доступны инструменты для управления текущим и сторонним бизнес-процессами. Бизнес-процесс может создавать другие бизнес-процессы, обращаться к существующим, переходить в них, ожидать их завершения, запускать параллельные процессы, автоматически совершать переходы. Таким образом, не все бизнес-процессы требуют интерфейса, и могут быть полностью автоматизированными, что часто используется для реализации сценариев RPA. Скрипты могут быть не только для бизнес-процессов, но и в виде утилит, что позволяет переиспользовать код в разных бизнес-процессах, упрощая разработку с ростом кодовой базы.
Благодаря перечисленным возможностям api, моделей бизнес-процессов, использования groovy-скриптов и java-библиотек достигается максимальная гибкость и скорость разработки.