Опыт построения микросервисной архитектуры в цифровом банке

Выступление Андрея Солощака, ведущего архитектора «Бинбанка», на профессиональной встрече CUSTIS Meetup: Микросервисы в Enterprise (16 марта 2017 года, Москва).

Transcript

1. Опыт построения микросервисной архитектуры в цифровом банке Солощак Андрей, 2017 Чем старше я становлюсь, тем менее забочусь о принятии правильных технических решений, но все более меня заботит сохранение возможности изменить неправильные. (Мартин Фаулер)
2. Цифровой банкинг (бизнес) • Банковские услуги через различные каналы • Продукты (каналы обслуживания) • Интернет-Банк и мобильный банк (ф/л, ю/л), SMS-банк, Интернет-эквайринг и P2P, Пластиковые карты (+Apple Pay, Samsung Pay, Android Pay), Платежные системы (пример http://russia.wu.com), чаты и чат-боты • Высокая конкуренция • Большой поток изменений • Мотивация на перевод клиентов в каналы • Цифровая трансформация уже вопрос выживания • Цифровой банк - это уже не совсем банк, но все еще банк • Тенденции • Фокус на usability (frontend), • Переход на модель Finance as a service (backend)
3. Цифровой банкинг (IT) • Большое количество интеграций • Постоянный рост сложности • 24x7 • Относительно высокая нагрузка • Безопасность • Гетерогенная среда • Унаследованные системы • Традиционные подходы не отвечают вызовам • Monolith, Shared Library
4. Что такое микросервисы? • Автономные сервисы • Относительно небольшие • Сфокусированные • Cлабосвязанные и высокосогласованные • Предоставляют контракт (API)
5. MSA – целостный подход к архитектуре • Реализация требований архитектуры • Масштабирование принципов проектирования • Domain Driven Design • SRP, DIP, ISP • Maintainability • Повторное использование, отказоустойчивость, масштабируемость • Backend for frontend (usability) • Безопасность • Процессные и организационные изменения • DevOps – непрерывная доставка ценности • Независимое внесение изменений • Роль архитектора • Проектирование в терминах взаимодействия микросервисов • Разработка и согласование контрактов • Выявление и решение проблем проектирования
6. Основные принципы • Принципы разделения • По видам сервисов • Доменные (bounded context) • Интеграционные • Фасадные (API Gateway, Enterprise) • Гранулярность • Определяется эволюционно • Изменяется в сторону уменьшения размера • Обеспечение сквозного контекста (ambient context) • Безопасность, логирование, мониторинг • Инверсия зависимостей и отсутствие «циклов» • Управление на уровне контрактов Client Channels (Single Page Applications, Mobile Applications, SMSBank, B2B) Internal Channels (Card Processing & ATM, Branch front-office, AdminTools etc) API Gateway Services (External Facade) Enterprise Facade Services Domain Services Integration Services External Systems (ESB, Peer-to-Peer) Scheduled Jobs Authorization (OpenID Connect based) Service Context [Security, Correlation, Logging (ELK), Discovery, Monitoring (Fraud, Health etc)] Persistence HTTP HTTP
7. Разработка контрактов сервисов • Контракты разделяются сервисом (сервером) и потребителями (клиентами) • Типы (DTO) описывают доменную модель • Контракты на основе интерфейсов (.Net) • Синхронный RPC вызовы (awaitable) • Асинхронные (AMQP) • Персистентные fire-and-forget запросы (Durable очереди) • Распределенные события (Events) • RAML - описание фасадных RESTful API • Контроль архитектуры на уровне исходного кода (Git / Bitbucket) • Контроль версий по SemVer • WCF или Service Stack (для .NET)? • Service Stack – лаконичное REST-совместимое описание контрактов Контракт на основе интерфейса (WCF style): [RemoteServiceContract] public interface ICustomerService { [RemoteOperationContract] Task<Customer> GetCustomer(long customerId); [RemoteOperationContract(Durable = true)] Task SaveCustomer(Customer customer); [RemoteEventContract] event EventHandler<CustomerArgs> CustomerUpdated; }
8. Особенности дизайна и инфраструктуры • Транспорт • HTTP (RPC) • AMQP (Durable RPC and Events) • JSON-сериализация (RAML совместимая) • Event Driven Architecture over orchestration • Saga over Event Sourcing (не путаем «теплое с мягким») • Асинхронные (await) вызовы • Кэширование • Контекст • Security • Correlation • Logging: ELK (Elastic Search – Logstash – Kibana) • Service Discovery • Coordinator (e.g. Consul) over proxy (e.g. Nginx) • Мониторинг и аудит • Нужен DevOps
9. Типовые проблемы при разработке • Общая база данных (а как же LINQ и OData?) • Повод для ревью дизайна • Для некоторых случаев стоит подумать о CQRS • Усложняется отладка • Unit Tests, DevOps, logging • Поддержка Nested Exceptions • Каждый сервис в отдельном Git – репозитории • Рефакторинг требует больше времени, но всегда делается осознанно • Обновление общего Framework
10. DevOps – основные принципы • Культура (CAMS!) • Непрерывная интеграция (CI) • Управление конфигурацией • Автоматическое развертывание • Мониторинг • Автоматическое восстановление • Непрерывная доставка ценности
11. Continues… Integration – все и всегда собирается • Все – код • Каждое изменение – собирается • Обязательно используем VCS и сервер интеграции (Git + Teamcity) Delivery – автоматизированный DoD (definition of done) • Релизы всегда собираем из одной ветки (master) • Если код попал в master – DoD выполнен, master всегда готов к релизу • Следуем workflow (feature branch) в VCS, контроль качества на уровне отдельных изменений Deployment – естественное развитие в рамках DevOps • Код в master всегда соответствует бою • Покрытие автотестами достаточно для гарантии качества • Код развертывается автоматом при прохождении автоматического тестирования • Используем ПО для автоматического развертывания и управления конфигурацией (Octopus)
12. Схема процесса развертывания
13. Что получилось • ~ 70 сервисов • Архитектура • Поддержка доменной модели на уровне контрактов • Предсказуемое развитие системы • Наличие / отсутствие проблем определяется качеством проектирования • DevOps – непрерывная доставка ценности • От проектирования до развертывания • Это не бесплатно, но того стоит
14. Дальнейшие шаги • Работа с техническим долгом • Развитие DevOps • Автоматическое тестирование • Виртуализация и контейнеризация • Infrastructure as a code • Перспективы масштабирование по всей организации • Построение Open API уже тенденция • Требуется отказ от традиционных SOA / BPM подходов • Поддержка Event Driven Architecture • Использование open source (RabbitMQ, Kafka) под вопросом • Не все промышленные платформы хорошо подходят • Ориентация на SOA • Ограниченная интероперабельность • Проблемы: Закон Конвея, унаследованные системы