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

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)
ServiceContext
[Security,Correlation,Logging(ELK),Discovery,Monitoring(Fraud,Healthetc)]
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
• Ограниченная интероперабельность
• Проблемы: Закон Конвея, унаследованные системы