Предлагаем вашему вниманию проектную работу Джамшеда Якубова, выпускника курса «Enterprise Architect«.
Цели итогового проекта:
- разделить монолит на сервисы
- обеспечить масштабируемость и качество
- обеспечить стабильность при переходе
- нормализовать данные
- запустить новые сервисы
Проблематика: технологические ограничения роста СУБД
Бизнес-стратегия компании подразумевает кратный рост. Но из-за технологических ограничений и технического долга, СУБД монолитной системы не сможет обеспечить высокий уровень отказоустойчивости. Необходимо разделить монолит на отдельные сервисы.
Риски
| Фактор риска | Вероятность | Цель и последствия | Величина риска | Меры |
| Падение базы данных из-за роста продаж, технологические ограничения хранения | 75% через 1 год 100% через 2 года | Рост продаж (невозможность достижения целей компании) | 50 млрд.руб | Разбить монолит на отдельные сервисы: ЭДО, финансовый учёт, регламентированный учёт, хранение файлов, перенос интеграций на событийный брокер (160 млн. руб.) |
| Репутация (задержки выплат курьерам, отчётность бенефициарам, взаиморасчеты с контрагентами) | 100 млн.руб. | |||
| Своевременная налоговая и регламентированная отчетность (штрафы) | 5 млн.руб. | вынести регламентированный учёт в отдельную базу (1 млн. руб.) |
Технический долг
| Технический долг | Решение |
| Хранение бинарных файлов ЭДО по каждой операции в СУБД | Запустить сервис S3, вынести «бинарники» из СУБД |
| Все сервисы в одной СУБД (монолит) | Разбить на отдельные сервисы |
| Разнородные интеграции | Перейти на брокер (Kafka) |
Бизнес-модель и мотивация компании
Выбор ERP-системы
В длинном списке было 14 систем. В короткий попало 5.
Инфраструктура ERP-системы
Центральную архитектуру решения необходимо строить на базе технологической платформы
«1С: Предприятие 8.3». Можно использовать несколько конфигураций 1С: Предприятие 8.3, а также вспомогательные решения на других платформах.
Имеется в виду использование только облачных ресурсов.
Отказоустойчивость
- Система относится к второму уровню критичности.
- Доступность: 95%.
- Среда тестирования должна быть идентична продуктивной среде.
- Продуктовая среда «отсечена» от остальных сред на сетевом уровне.
- Постоянный мониторинг продуктовой и тестовой сред с оповещением ответственных команд по следующим показателям для серверов: «СУБД», «Приложения», «Веб».
Производительность
- Количество одновременно работающих пользователей: 250.
- Общее количество пользователей: 500.
- Общее количество транзакций: до 2 млн в день.
- Максимальное количество транзакций на пике: до 5 млн в день. Допустимо отложенное отражение в учёте в течение 24 часов.
Стейкхолдеры
Механизм архитектурного надзора
- Формализация функциональных требований в Confluence.
- Согласование функциональных требований с группой функционального контроля: руководителем проекта, бизнес-аналитиком, системным аналитиком.
- Формирование проектных решений на основе функциональных требований в Confluence
- Согласование проектных решений в архитектурном комитете: с архитектором, ИТ-директором, девопсом, руководителем проекта, системным архитектором
- Проектирование интерфейсов и формирование технических заданий на основе проектных решений в Confluence
- Согласование технических заданий с группой технического контроля: системным архитектором, системный аналитиком, разработчиком
- Разработка и тестирование MVP-решений
- Архитектурный контроль
- Реализация и запуск стабильного решения
Интеграционная модель
В интеграционный ландшафт входят:
- Событийные паттерны и «точка-точка»
- Асинхронные и синхронные взаимодействия
План действий и дорожная карта
Вывод
- Некоторые требования к системе не давали уложиться в сроки.
Эти требования будут выполнены на следующих стадиях развития системы - Обеспечены масштабируемость и устойчивость системы
- Обеспечены быстрый деплой, независимость компонентов и гибкость в выборе технологий
- Технический долг погашен, удалось избежать рисков
- Удалось достичь поставленных целей (с допустимой погрешностью)
