Российский бизнес все более активно внедряет микросервисы. Можно выделить ряд особенностей практической разработки и внедрения микросервисов в организациях.
Микросервисы: сущность и отличия от монолита
Микросервисная архитектура – подход к разработке системы (продукта, приложения), при котором обеспечивается разделение ее компонентов на автономные составляющие — микросервисы. Они могут иметь собственную кодовую базу, обособленные базы данных, но при этом логически связаны друг с другом. В контексте того или иного корпоративного решения микросервисы могут отвечать за конкретные бизнес-задачи.
Обновление какого-либо микросервиса (изменение функционала) не влияет на работу прочих компонентов, входящих в систему. В этом заключается главное отличие микросервисной архитектуры от монолитной, при которой составляющие ее компоненты объединены преимущественно общей кодовой базой. Соответственно, изменения в одних частях монолита повлияют на функционирование всей системы.
Плюсы и минусы микросервисов
Главные преимущества использования микросервисов:
1. Введение в систему новой функции (изменение текущей) требует обновления одного компонента, в котором данная функция реализована, в то время как в монолитной системе потребуется обновлять все компоненты.
2. Каждый микросервис может разрабатываться на отдельном языке программирования, использовать свои базы данных и библиотеки.
Это позволяет применить язык, подходящий для реализации функционала конкретного компонента. У монолитной системы код и базы общие – оптимизацию отдельных участков придется осуществлять в пределах возможностей используемого языка.
Микросервисная архитектура характеризуется использованием нескольких автономных баз данных.
3. Участнику команды разработчиков, работающему с конкретным микросервисом, необязательно знать специфику других компонентов. В случае с монолитной архитектурой нужно изучать всю систему.
4. Чтобы масштабировать систему, достаточно увеличить нагрузку на базовые микросервисы, в то время как монолитную систему придется масштабировать целиком.
Есть и недостатки:
1. Риск потери контроля над работоспособностью отдельных компонентов в случае сбоев на оборудовании, где они локализованы, как и риск утраты санкционированного доступа к такому оборудованию.
2. Техническая сложность, затратность организации контроля в силу необходимости проводить большое количество транзакционных операций между распределенными компонентами.
3. Ухудшение качества кадровой политики в случае привлечения сотрудников с разнотипными компетенциями к работе с разными модулями. Формально находясь в одной команде, работники не всегда могут понимать сути поступающих запросов от коллег в силу их иного профиля деятельности.
Примеры микросервисов
На мировом и российском IT-рынке микросервисные системы активно внедряются и развиваются. В компании «Диасофт» уже разработано не одно решение на такой архитектуре. Вот некоторые примеры бизнес-процессов, которые могут быть реализованы на уровне микросервисов:
- Обслуживание клиентов в инвестиционных компаниях
Использование решений, построенных на микросервисной архитектуре, позволяют:
- организовать обслуживание 5 млн операций с финансовыми инструментами в день;
- обеспечить бесперебойность работы системы в режиме 24/7 с возможностью ее обновления и техобслуживания без остановки эксплуатации;
- сократить время вывода новых продуктов на рынок.
2. Операционное обслуживание физических и юридических лиц в банке
Специфика здесь заключается в разнотипности тематик обращения со стороны клиентов: кроме финансовых, это могут быть вопросы технического, юридического характера, требующие привлечения к диалогам сотрудников узкого профиля. Целесообразно выделить микросервисы для следующих задач:
- организации диалогов с автоматизированными чат-ботами (по типовым тематикам);
- организации диалогов с сотрудниками общего профиля (консультантами);
- ведения диалогов с экспертами узкого профиля (кредитными специалистами по конкретному виду кредита, разработчиками, юристами).
Каждый из указанных сервисов может функционировать на базе автономных интерфейсов (локальных, облачных), формировать собственные базы данных, отчетные и аналитические документы.
2. Ведение корпоративного электронного документооборота.
В рамках ЭДО осуществляется обработка разнотипных видов документов: первичных, кадровых, распорядительных, отчетных, уставных, технических, нормативно-справочных и презентационных.
В свою очередь, каждый из указанных видов документов подразделяется на различные подвиды (например, кадровыми могут быть приказы, инструкции, анкеты). Управление ими необходимо организовать на уровне специализированных микросервисов, которые могут отличаться:
- по архитектуре интерфейсов: облачные, локальные, браузерные;
- по применению разрешенных типов ЭЦП (например, в кадровом ЭДО в ряде случаев допускается использование неквалифицированных подписей, в налоговой отчетности — только КЭП);
- по уровню доступа (может быть разрешен только руководству или только определенным сотрудникам).
Принципы создания микросервисов: на что обратить внимание при разработке?
Следует, прежде всего, учесть, что:
1. Разрабатываемая архитектура будет более управляемой (как и менее затратной на стадии разработки), если составляющие ее микросервисы распределить на логические группы по специфическому критерию – перечню вероятных причин последующего внесения изменений в соответствующие компоненты.
В силу общности указанных причин применительно к конкретной группе микросервисов изменение компонентов будет возможно синхронизировать (унифицировать в допустимых пределах) и, соответственно, снизить издержки и увеличить оперативность обновлений. В свою очередь, не следует группировать микросервисы, изменяемые в силу разных факторов.
2. Некоторые элементы системы на базе микросервисов в любом случае будут общими (типичный пример – пользовательский интерфейс).
Необходимо уделить большое внимание обеспечению корректного взаимодействия каждого микросервиса с такими элементами, а также синхронизации их обновления.
3. Устойчивость функционирования архитектуры на базе микросервисов будет зависеть от условий реализации функционала на уровне каждого компонента.
Это условия, прежде всего, технологические (обеспечивающие безопасность обработки и передачи данных), и организационные (обеспечивающие своевременный мониторинг функционирования компонентов назначенными лицами).
4. При разработке системы на базе микросервисов необходимо учитывать специфику будущего управления архитектурой (осуществления оркестровки).
Все микросервисы должны быть совместимы с техническими решениями, задействуемыми в рамках оркестровки. Желательна совместимость и с альтернативными решениями, которые могу быть оперативно внедрены вместо текущих.
Переход на микросервисы – когда стоит переходить с монолита
Можно выделить ряд сценариев, при которых целесообразен переход с монолитной архитектуры на микросервисы:
1. Необходимо разграничить доступ к корпоративным данным, концентрируемым в определенных сегментах.
Например, доступ к документам, формируемым в рамках взаимодействия компании с поставщиками, потребителями или в рамках организации взаимодействия между сотрудниками. Для организации оборота каждого из соответствующих типов документации может быть задействован специализированный микросервис со своей базой данных, к которой есть доступ только у тех сотрудников, которые работают с определенным типом документов.
2. Бизнес выходит на траекторию масштабирования.
В этом случае развертывание бизнес-процессов в рамках архитектуры на микросервисах будет происходить быстрее, чем при монолитной системе. Это даст компании дополнительные конкурентные преимущества в рамках масштабирования.
3. В приоритете компании – инновации в части внедрения самых свежих методик организации бизнес-процессов.
Использование архитектуры на базе микросервисов позволит проводить тестирование новых технологий и методов управления данными с меньшими рисками, чем при применении монолита. Если тот или иной компонент в результате обновления перестанет функционировать, то остальная часть архитектуры не пострадает.
Необходимым условием для перехода с монолита на микросервисную архитектуру будет наличие у предприятия достаточных ресурсов для модернизации, для проведения которой потребуется доступ к достаточно объемному стеку технологий.
Чтобы автоматизировать создание микросервисов, компания «Диасофт» разработала технологическую low-code платформу DigitalQ.Archer, функционал которой позволяет нажатием одной кнопки сгенерировать исходный код и получить работоспособный прототип приложения, решающего конкретные бизнес-задачи (PBC, Packaged Business Capabilities). Платформа Digital Q.Archer позволяет проектировать PBC и автоматически генерировать необходимые для их работы микросервисы. PBC могут быть связаны между собой посредством API и событий и использоваться как «строительные блоки» для создания более сложных цифровых решений.
Какой стек выбрать для микросервиса
В настоящее время не разработано четких критериев (ни отраслевых, ни для IT-рынка), по которым можно было бы установить требуемое содержание стека. Однако при определении его структуры полезно учитывать, что:
1. Технологическое единство микросервисных компонентов (в части общности языка, типов баз данных, сред разработки) будет преимуществом с точки зрения:
- синхронизации запуска соответствующих компонентов;
- формирования команды разработчиков;
- последующей отладки работы системы и поддержания ее функционирования.
2. Технологии в рамках стека должны быть проверенными, доказавшими надежность (не нести «эксперимент в себе»).
Архитектура должна быть полноценно запущена и отлажена на первичной стадии. В дальнейшем возможно дополнение функционала системы на уровне автономных микросервисных компонентов.
3. Расширение перечня стека должно быть обоснованным и учитывать наличие необходимых компетенций в части практического применения инструментария для разработки системы.
Преимуществом команды разработчиков будет доступ к практическим примерам реализации функционала компонентов стека, наличие отраслевого опыта внедрения тех или иных технологических подходов. Например, соответствующий опыт имеет компания «Диасофт», которая создает и активно развивает программные продукты в микросервисной архитектуре.