Эволюция от SOA к автономным системам: путь к снижению затрат в корпоративной веб-разработке
Не финансовые компании и предприятия, где команды разработчиков обладают более глубокими знаниями в области бэкенд-разработки, адаптация микросервисной архитектуры может выйти за рамки проектного бюджета и стать тяжелой “ношей” на этапе поддержке и развития. Возникает вопрос, каким образом можно разработать современную, отказоустойчивую информационную систему на основе веб-технологий, избегая превращения ее в неповоротливый большой монолит? Одним из решений является создание системы, основанной на принципе слабой связности компонентов, которая является эволюцией принципов Service-Oriented Architecture (SOA) и нашла свое применение в проектах крупных предприятий, где преобладают компетенции бэкенд-разработки. Данный подход получил название Self-Contained Systems (SCS), что можно интерпретировать как концепцию Автономных систем или архитектуру на основе сообщающихся монолитов.
Ключевые выводы
- Индикатор того, что ваш проект будет хорошо ложиться на SCS — наличие большого количества автономных доменов и бизнес-логики, связанной с определенной функциональностью в рамках большого проекта. Отлично подходит для крупных проектов в энтерпрайзе благодаря схожести с подходами при проектирования монолитов.
- В отличие от микросервисной архитектуры для подхода SCS характерно, что система состоит из множества автономных монолитов со своим UI, бизнес-логикой и базой данных. Для унификации клиентского опыта UI каждого монолита унифицирован в единой стилистике. Между монолитами организовано отказоустойчивое асинхронное взаимодействие.
- Каждая подсистема может быть независимо разрабатываемой и поддерживаемой командой, что способствует гибкости в управлении проектом.
- Автономные системы обеспечивают устойчивость, поскольку сбои в одной системе не влияют на остальные.
- Ускорение работы UI части может потребовать дополнительных усилий на создание дополнительного слоя на реактивных фронтенд технологиях.
Определения
Говоря простым языком, автономные системы — это «сообщающиеся монолиты» с некоторым количеством «но», заимствованных из микросервисов. Главные концепции — минимальная связанность между системами и отказоустойчивые коммуникации.
Innoq - самый большой меинтейнер в комьюнити SCS
Хотелось бы вкратце рассказать о главной акуле SCS — Innoq. Немецкая консалтинговая группа специализируется на реализации проектов заказной разработки для крупных корпоративных заказчиков, модернизации инфраструктуры и консалтинге в области цифровой трансформации. Основана в 2002 году. Представители компании регулярно выступают с докладами на технических конференциях и активно выступают против слепого “карго культа”. В реальных проектах часто случается, что ничего, кроме удорожания разработки, поддержки и эксплуатации такие решения не приносят.
Одним из ключевых факторов, который привел к появлению SCS подхода, стало то, что компании упрямо стартуют проекты на основе микросервисной архитектуры, просто следую популярным трендам. При этом команды становятся заложниками закона Конвея:
“Любая организация, которая разрабатывает систему (в широком смысле), создает проекты, структуры которых являются копией структуры связей организации.”
Попытки локально перестроить подходы к разработке в компании, которая не имеет внутри культуры самоорганизованных и автономных команд, терпят неудачу. В ответ на эти вызовы специалисты компании Innoq синтезировали SCS подход, который совмещает преимущества независимого развертывания от микросервисной архитектуры и простоту архитектуры монолитов. SCS подход имеет официальное сообщество и ссылки на ресурсы с примерами проектов.
На схеме ниже приведена архитектура e-commerce портала, выполненного компанией Innoq для международного лидера в области производства электротехнических изделий Phoenix Contact.
Как мы можем наблюдать, каждая из подсистем — это набор монолитов, разбитых на домены. Важно отметить, что на схеме присутствует дополнительная общая фронтальная система, которая собирает все разрозненные элементы UI вместе в единый веб-портал.
Следующая схема графически демонстрирует важное различие между подходами SOA, микросервисов и SCS.
Основные принципы SCS
Сообщество сформулировал ряд принципов, следуя которым можно написать хорошую систему, построенную на SCS. Ниже находится пересказ всех поинтов, описанных комьюнити и представителями компании Innoq.
- Доменное разбиение: Важнейшей составляющей SCS является разбиение системы на домены. Каждый домен представляет собой независимую подсистему, сосредотачивающуюся на своей области ответственности.
- Сосредоточенность на домене: Желательно, чтобы каждая система не выносила и не привносила свои внутренние объекты за границы ответственности своей же области.
- Минимизация оверхеда: Каждая подсистема должны выглядеть как микросервис с архитектурной точки зрения.
- Сервисность: Допускается использование микросервисов для решения доменной бизнес логики (для одной системы использование n микросервисов в бекенде).
- Отдельная база данных: Каждая система, подобно микросервисам, обязана иметь свою собственную базу данных.
- Технологическая свобода: Отсутствие ограничений в выборе технологий позволяет адаптировать подход к конкретным потребностям проекта.
- Асинхронные коммуникации: Коммуникации между системами должны быть асинхронными. Это обеспечивает более эффективное взаимодействие и гибкость. Межсистемные коммуникации должны использовать HTTP Rest или легковесный брокер сообщений.
- Сосредоточенность команд: Одна команда может работать над одной или несколькими подсистемами. Но над отдельной подсистемой может работать ТОЛЬКО одна команда.
- Минимизация связности: Уровень связности между системами должен быть минимальным, обеспечивая тем самым легкость поддержки и модификации.
- Переиспользуемость: Над всеми системами существуют проект или проекты, вобравшие в себя все общее от систем. Общие UI компоненты, общие сущности и DTO, API подсистем, которые вынесены наружу, общие вычисления, подходы. Пример — общий OpenID Connect плагин для работы с Keycloak.
- Отдельный UI: Каждая система имеет свой собственный UI, который должен синергировать по стилю с другими системами. Синергия должна достигаться по средствам общего UI Toolkit.
- Слияние: Все подсистемы с точки зрения UI/UX должны выглядеть как одно целое. Излишние сообщения между системами должны уменьшаться посредством использования Web интерфейсов, таких как hyperlink, iframe и т. д.
- Обобщенный UI: При использовании iframe должна присутствовать root-layout система, которая объединяет все подсистемы в один UI.
- Связанный UI: При использовании hyperlink-ов, они обязаны работать в обе стороны.
Все эти принципы по отдельности носят рекомендательный характер, не стоит слишком сильно подгонять свою систему под все вышесказанные поинты. Но чем меньше вы отступаете от постулатов, тем меньше проблем вы получите в перспективе.
Сильные и слабые стороны
Плюсы:
- Отказоустойчивость: Автономные системы обеспечивают устойчивость, поскольку сбои в одной системе не влияют на остальные.
- Простое разделение по командам: Каждая подсистема может быть независимо разрабатываемой и поддерживаемой командой, что способствует гибкости в управлении проектом.
- Сервисная ориентированность: SCS способствует созданию сервисно-ориентированных систем, где каждая часть выполняет конкретные функции.
- Преимущества монолитов: Архитектура сохраняет выгоды монолитов, такие как скорость разработки, возможность использования любимых фреймворков, а также наличие фуллстек UI и ORM.
- Независимый деплой: Возможность обновлять и масштабировать каждую подсистему независимо, что упрощает управление версиями и обеспечивает гибкость в развертывании.
- Предпочтительное решение для энтерпрайза: В некоторых случаях SCS может представлять собой более выгодное решение для энтерпрайза, чем микросервисы, благодаря более простому управлению и большей схожести с монолитами.
Минусы
- Разделенный UI: Необходимость долгого проектирования коммуникаций и пользовательского интерфейса между автономными подсистемами.
- Усложненные коммуникации: В сравнении с монолитом требуется более тщательное проектирование и внимание к взаимодействию между системами.
- Усложненный деплой: Процессы развертывания становятся более сложными по сравнению с монолитной архитектурой.
- Дополнительная документация и взаимодействие команд: Вводится дополнительная необходимость в документировании и согласовании работы между различными командами, что может потребовать дополнительных ресурсов.
- UI Toolkit: Необходимость выделения времени на согласование общего набора инструментов для пользовательского интерфейса.
- Невозможность ускорения UI: В отличие от выноса бизнес-логики, ускорение пользовательского интерфейса может оказаться более сложной и дорогостоящей задачей.
Однако все эти недостатки могут быть менее релевантными для B2B и E-Commerce систем, где количество пользователей вторично по сравнению с множеством бизнес-процессов и объемом бизнес-логики.
Как использовать в реальных проектах
Перенос клиентского опыта совершения покупок из B2C сегмента в В2B сегмент в России происходит очень медленно, но верно. “Пионеры” цифровой трансформации даже в самых консервативных отраслях экономики тестируют формат B2B e-commerce порталов. Порталы используются в первую очередь для презентации витрины своей продукции, выстраивании омникальных коммуникаций с покупателями и партнерами и цифровизации операций продаж. Подобные решения чаще всего относятся к категории заказной разработки, так как созданный продукт формируется под ИТ-ландшафт конкретной компании и после запуска постоянно развивается. В отличие от B2C маркетплейсов для B2B порталов характерны следующие отличительные черты:
- Личный кабинет контрагента/партнера объединяет множество учетных записей с разным набором полномочий, в отличие от единого аккаунта покупателя - физического лица для B2C маркетплейса;
- Длительная процедура контрактации, состоящая из шагов проверки контрагента, согласования условий поставки и подписания контрактов;
- Сложная система ценообразования, привязанная к набору опций продукта, конфигурации комплекта и условиям поставки;
- Объем транзакаций, выполняемых от лица одного контрагента, выше чем, в B2C. Характерны возобновляемые заказы от контрагентов по заданному расписанию;
- Разнообразие вариантов взаиморасчетов по контракту: предоплата, по согласованному графику, с отсрочкой и т.д.;
- Развернутая клиентская аналитика, нацеленная на выявление возможностей повышения лояльности и удержание в долгосрочной перспективе;
- Интеграции с множеством внутренних систем предприятия для получения информации о статусе расчетов, поставки, складских остатков и аналитики.
Создание проектов B2B порталов в парадигме микросервисной архитектуры сопряжено с высокими рисками. Так помимо риска выстроить неустойчивую архитектуру решения появляется риск “зарыться” в реализации сложной бизнес-логики клиентского взаимодействия на уровне сервисов и данных. Концепция SCS проявляет себя в данном кейсе особенно хорошо, так как все решение разбивается на множество связанных монолитов, которые для конечных пользователей выглядят как единая система за счет сквозного клиентского опыта под единой учетной записью.
Разберем на демонстрационном примере
Рассмотрим создание SCS проекта на примере простой предметной области - заказ и доставка пиццы. Изолированный от B2B области пример выбран не случайно - процессы обслуживания максимально известны и понятны каждому, кто хоть раз заказывал пиццу онлайн.
1. Определим домены и сформируем системы
Ресторан (Restaurant System):
В этом домене фокусируется вся информация о ресторанах. Здесь осуществляется регистрация и создание новых ресторанов. Администраторы ресторанов имеют возможность настраивать меню, добавлять и редактировать блюда, а также принимать заказы на готовку еды. Этот домен является ключевым для организации бизнес-процесса внутри ресторанов.
Доставка (Delivery):
Домен доставки фокусируется на управлении курьерами. Здесь происходит регистрация курьеров, назначение им роли доставщика, а также менеджмент заказов, связанных с доставкой. В этом домене осуществляется эффективное управление логистикой и выполнением заказов.
Заказы (Order System):
Центральным доменом в системе доставки еды является система заказов. Здесь пользователи начинают бизнес-процесс, создавая заказы. Интерфейс для создания заказов, наполнение корзины и все запросы, связанные с бизнес-процессом доставки еды, исходят именно из этого домена. Здесь происходит взаимодействие с другими подсистемами и интеграции для эффективного выполнения заказов.
В реальной системе количество доменов будет измеряться десятками. Например дополнительные домены для системы платежей, уведомлений, построения маршрутов и т.д. Сформированные в примере домены трансформируем в информационные системы:
- Система Заказов (Order System): Взаимодействие с пользователями.
- Система Курьеров (Courier System): Ориентирована на курьеров.
- Система Ресторанов (Restaurant System): Администрирование ресторанов.
2. Опишем бизнес-процесс
Высокоуровневое представление бизнес-процесса заказа и доставки пиццы переводим в сквозной пользовательский сценарий для создания прототипа:
- Пользователь заходит в систему заказов. Система заказов загружает список ресторанов из системы ресторанов.
- Пользователь выбирает ресторан. Система загружает из системы ресторанов список еды и меню для пользователя. Пользователь составляет корзину из предложенного и сохраняет заказ.
- Система заказов сохраняет копии заказа пользователя и запускает бизнес-процесс.
- Система заказов делает HTTP-запрос в систему ресторанов с запросом на приготовление еды. Процесс останавливается и ожидает, пока ресторан подтвердит.
- Администратор ресторана входит в систему (ресторанов), берет заказ на приготовление еды. Система ресторанов делает обратный HTTP-запрос в систему доставки еды. Система заказов продолжает бизнес-процесс.
- Система заказов делает HTTP-запрос в систему курьеров и публикует запрос на доставку.
- Курьер заходит в систему доставки, берет на себя текущий заказ. Система курьеров делает обратный HTTP-запрос в систему заказов, продолжается бизнес-процесс.
- Стартует доставка. Бизнес-процесс приостанавливается, ожидая завершения доставки.
- Курьер доставил еду. Заходит в систему и подтверждает окончание доставки. Система курьеров делает обратный HTTP-запрос в систему заказов. Бизнес-процесс продолжается.
- Финальный шаг. Заказ переводится в статус «доставлен», и бизнес-процесс завершается.
3. Выберем технологический стек
Как было сказано ранее проектируемое решение состоит из набора автономных монолитных систем. Следовательно, в качестве технологии мы можем использовать фулл-стек фреймворки под платформы .NET или Java (Axiom JDK). В реестре отечественного ПО мы можем найти отечественную open-source платформу для разработки корпоративных веб-приложений Jmix. Платформа построена на современном Spring Boot ядре, включает в себя интегрированную профессиональную среду разработки и множество готовых к использованию компонентов. Ну и самое важное - команда разработке создает веб-приложение от модели данных до UI на едином языке - Java или Kotlin.
При использовании Jmix в России рекомендуем использовать доверенный комплект разработчика Java от компании Axiom JDK - Axiom JDK Certified. Для управления учетными записями пользователей лучше использовать популярную open-source технологию Keycloak. Для оркестрации асинхронного взаимодействия между системами рекомендуем использовать open-source BPM движок Flowable, который входит в комплект поставки Jmix.
4. Спроектируем системное взаимодействие
В демонстрационном примере сознательно упрощены некоторые аспекты реализации системного взаимодействия при реализации пользовательского сценария. Рассмотрим подробнее:
- При посещении пользователями страницы заказа мы предоставляем ему все объекты передачи данных(DTO), полученные от ресторанов. Это гарантирует, что до начала процесса и формирования заказа мы не вмешиваемся в консистентность данных:
- Согласно контракту, установленному до момента запроса списка блюд и до его завершения, цены не будут изменяться. В начале процесса, когда пользователь еще не создал корзину от нас ничего не требуется.
- Следовательно, неблокирующие асихронные запросы не требуются, поскольку у пользователя нет объектов для просмотра, и он все равно должен ожидать загрузки данных и отображения элементов меню.
- При создании заказа пользователем мы сохраняем копии выбранных им блюд, обеспечивая, таким образом, надежность в случае изменения или удаления элементов из меню ресторана.
- Все взаимодействия остаются в контексте бизнес-процесса. Асинхронное взаимодействие между системами полностью на стороне BPM движка:
- Асинхронная отправка запросов в другие системы в рамках задачи в бизнес-процессе;
- Приостановка последовательности задач по процессу на задаче ожидания сигнала подтверждения от другой системы;
- При получении ответа от другой системы BPM движок возобновляет движение по процессу.
Описанный подход позволяет решить множество проблем, связанных с устойчивостью системы в целом, и решить задачу минимизации межсистемных коммуникаций. Бизнес-процесс в нотации BPMN 2.0 приведен на отдельной схеме.
5. Подходы к созданию единого UI
Каждая из разработанных в рамках демонстрационного примера систем полностью автономна и эффективно функционирует независимо от других. Из-за высокой степени автономии не требуется создавать отдельную единую фронтальную систему, которая выполняла функцию корневой для всех подсистем и предоставляла контент в унифицированном виде. Тем не менее, каждая система использует единый дизайн kit и унифицированные веб-компоненты для реализации пользовательского взаимодействия. При переходе между системами пользователь может даже не заметить факт переключения. Такой подход дает нам гибкость и свободу в разработке каждой подсистемы, а также упрощает управление проектом в целом. Каждая система может разрабатываться и внедряться независимо от остальных.
Что получилось
В рамках демонстрационного примера реализована система, выполненная в соответствии с ключевыми принципами SCS:
- Доменное разбиение и изоляция на уровне домена: Предметная область задачи структурирована на три автономных системы.
- Минимизация оверхеда: С архитектурно точки зрения каждая из трех систем реализует только свои доменные сервисы.
- Отдельная база данных: Для каждой системы спроектирована собственная база данных на единой СУБД.
- Технологическая свобода: При выборе технологического стека остановились на фулл-стек Java платформе - Jmix, но можно применить и альтернативы.
- Асинхронные коммуникации: Асинхронные коммуникации реализованы посредством HTTP запросов, которые оркестрирует BPM движок Flowable.
- Сосредоточенность команд: Каждая из трех систем может разабатываться самостоятельными командами.
- Переиспользуемость: Для реализации переиспользуемого для всех систем сервиса идентификации и аутентификации пользователь использована технология управления учетными записями пользователей Keycloak.
- Отдельный UI: Каждая система имеет свой собственный UI, выполненный с использованием единого дизайн кита.
- Слияние: Пользователь не ощущает границу между системами во время работы за счет унифицированного UI и переключениями между приложениями на уровне гиперссылок.
Вы можете найти больше масштабных примеров реализации проектов использования SCS на сайте сообщества https://scs-architecture.org.
Продуктивная разработка B2B веб-приложений на Java
Если вопросы продуктивности при разработки B2B веб-приложений входят в Вашу зону интересов, то вероятно ценности, разрабатываемой нами платформы Jmix, будут вам близки. Платформа ориентирована на два основных сегмента разработчиков - независимые команды разработки и инсорсинговые команды корпоративного сектора. Независимые команды получают готовый поддерживаемый вендором open-source стек разработки, который обеспечит стандартизацию архитектурного подхода и прекрасную документацию за 0 руб. Особенность лицензирования платформы такова, что все разработанные командами приложения не содержат лицензионных ограничений вендора и представляют собой обычные Spring Boot приложения. Корпоративные команды разработки получают существенный прирост производительности при создании однотипных enterprise приложений, при этом не надо заботиться о регулярных обновлениях своего “домашнего” фреймворка. Разработанные корпоративные приложения становятся цифровыми активами предприятия, которые можно внести в реестр МинЦифры и поставить на баланс. Примеры таких решений уже есть в реестре. Просто погуглите. Для быстрого знакомства с технологией воспользуйтесь материалами на нашем сайте www.jmix.ru и бесплатным курсом обучения на платформе Stepik. Подключайтесь и будьте продуктивными!