Макро-сервисная архитектура

Архитектура КИС (Корпоративной Информационной Системы) основанная на макро-сервисном подходе.

Почему необходимо перейти на Макросервисную архитектуру

Современные темпы развития Информационных систем и расширение бизнеса ставят перед ИТ проблему обеспечения быстрого развития, при работе 24х7. Технологические окна постоянно уменьшаются. А количество функционала, который требует автоматизации растет. Стало невозможно все задачи бизнес решить использованием только одной информационной системой (Моноархитектура).

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

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

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

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

Если проанализировать потребности FMCG, то мы видим, что многие идеи Микросервисного подхода можно использовать и тем самым решить острые задачи стоящие перед ИТ департаментом. Но в отличии от банковского сектора - в FMCG работа каждого сервиса на порядок сложнее. Поэтому был создан Макросервисный подход использующий преимущество Микросервисной архитектуры и специфику работы FMCG.

Основная идея

Как следует из названия, архитектура Макрослужб — это подход, при котором КИС (Корпоративная Информационная Система) разбивается на набор отдельных информационных систем (Макросервисов), где каждый сервис обеспечивает работу только своих бизнес-процессов и взаимодействует с остальными сервисами по четким правилам. Каждая ИС реализует специфические возможности в предметной области и свою бизнес-логику в рамках определенного ограниченного контекста, должна разрабатываться автономно и развертываться независимо. Наконец, каждая Макрослужба должна иметь собственную модель данных предметной области и логику предметной области. Макрослужбы могут иметь разный функционал, версию и быть разработаны разными производителями. Основное требование - что бы они выполняли требования к взаимодействию между системами.

Некоторые ключевые характеристики Макросервисов:

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

Порядок внедрения

1. Считаем каждую информационную систему отдельным не зависимым сервисом (Макросервисом), в некоторых случаях, Макросервисом можно рассматривать даже отдельный модуль системы.
2. Формируем принципы обмена между этими Макросервисами на основе сообщений стандартизированного формата.
3. Создаем единую систему мониторинга работы интеграционной системы.
4. Описываем правила взаимодействия между разработчиками и поддержкой

Преимущества данной архитектуры

Такой подход позволяет:

1. Повысить устойчивость работы - выход из строя одной информационной системы повлияет на работу других систем, только в части процессов затрагивающих обе системы.
2. Каждую систему обновлять, перегружать, изменять и даже заменять незаметно для остальных информационных систем.
3. Упростить взаимодействие между сотрудниками отвечающими за разные информационные системы.
4. Упрощается масштабирование. Например: открыли новый склад для запуска достаточно скопировать и перенастроить существующий сервис.
5. Гибкое перераспределение ресурсов - можно добавить или убрать ресурсы у любого сервиса не затрагивая работу других сервисов.