Similar presentations:
Микросервисная архитектура, подходы и технологии
1.
Микросервисная архитектура,подходы и технологии
Ветчинкин Кирилл
https://www.facebook.com/k.vetchinkin
[email protected]
2. О себе
Руководитель разработки,
архитектор
Практикую:
IT strategy
Agile
DevOps
Микросервисы
3. О компании
• Финтех-проекты• Платежные системы
• Крупные интеграции
4. О чем доклад?
• Вспомним кратко идею подхода• Нужны ли вам микросервисы?
• Архитектура системы
• Паттерны/антипаттерны
• Проблемы и решения
• Развертывание и технологии
5. Проблематика больших монолитных систем
• Плохое горизонтальное масштабирование• Плохая отказоустойчивость
• Сложность внедрения новых технологий
• Сложность рефакторинга legacy
• И т.п.…
6. Суть микросервисоного подхода
7. Плюсы и минусы
Плюсы• Горизонтальное
масштабирование
• Отказоустойчивость
• Масштабирование команд
• Переиспользование
• Гибкость стека
Минусы
• Сложно
• Дорого
• Не согласованные данные
8. Вам не нужны микросервисы, если
• Вы делаете стартап (MVP)• Нет или не предполагается рост нагрузки
9. Вам нужны микросервисы, если
• Высокая нагрузка• Система растет
• Команда растет
• Нужна отказоустойчивость
• Необходимо сократить TTM
10. Разрез на сервисы
КонтрактЛогика
Платежи
История платежей
Акции
Sms
Отчеты
Dal
OLTP
OLAP
11. Разрез на сервисы
Не разрезайте по слоям, разрезайте по бизнес-контекстамПлатежи
История
платежей
Контракт
Контракт
Логика
Логика
DAL
DAL
Акции
Sms
Контракт
Отчеты
Контракт
Контракт
CRUD
QUERY
12. Размер сервиса
• На основе бизнес-контекста• На основе сетевых запросов
• На основе транзакций
Платежи
Акции
Sms
13. Один VCS/CI/CD на сервис
• Один сервис – один репозиторий• Один сервис – один CI-конвейер
• Один сервис – один CD-конвейер
14. База данных
• Один сервис – одна база• Выбор типа базы данных
зависит от задачи
Платежи
История
платежей
Контракт
Контракт
Логика
Логика
DAL
DAL
15. Events или RPC
Events(AMQP, MSMQ и т.п)RPC(HTTP REST)
• Асинхронное
взаимодействие
• Синхронное
взаимодействие
16. Выбор протокола обмена сообщениями
• Специфические дляплатформы (JMS, MSMQ)
• Независимые от платформы
стандарты (AMQP и прочие)
17. Брокер сообщений
ApiGateway18
18. ApiGateway
• Единая точка входа для клиента• Нет логики
• Делается под клиента
19. ApiGateway
API Gateway20
20. ApiGateway
BFFAPI Gateway
21
21. BFF
PublicAPI
Private
API
Admin
API
22
22. BFF
HTTP Proxy(Ocelot)https://github.com/ThreeMammals/Ocelot
23
23. HTTP Proxy(Ocelot)
[GET] api/v1/card/{id}Public
API
[GET] api/v1/card/{id}
Private
API
[GET] api/v1/card/{id}
Admin
API
[GET] api/v1/card/{id}
Card
service
24
24. HTTP Proxy(Ocelot)
[GET] api/v1/card/{id}Private
API
[GET] api/v1/card/{id}
Card
service
25
25. HTTP Proxy(Ocelot)
[GET] api/v1/card/{id}Public
API
[GET] api/v1/card/{id}
Private
API
[GET] api/v1/card/{id}
Admin
API
[GET] api/v1/card/{id}
Card
service
26
26. HTTP Proxy(Ocelot)
Платеж с дефолтной картыPublic
API
Private
API
Card
service
Payment
service
27
27. Платеж с дефолтной карты
Сильная связанностьPublic
API
Card
service
Private
API
Payment
service
28
28. Сильная связанность
AggregatePublic
API
Private
API
Payment
aggregate
Card
service
Payment
service
29
29. Aggregate
Архитектура сервиса30.
Умный - глупыйPayment
service
Sms
service
CQS
DDD
Repository
Domain events
30 строк кода
прямо в
Consumer
31
31. Умный - глупый
Структура умного сервисаREST API
Payment
service
Consumers
Query
Command
Domains
Infrastructure
32
32. Структура умного сервиса
Структура простого сервисаREST API
Simple
service
CRUD
33
33. Структура простого сервиса
REST APIConsumers
Simple
service
Simple code
34
34. Структура простого сервиса
Умные и простыеUser
service
Report
service
Quartz
service
Payment
service
Acceptcode
service
Identification
service
Autopayment
service
Notification
service
Reconciliation
service
Sms
service
35
35. Умные и простые
Переиспользуемые• Сервис решает типовые задачи
• В идеале это контейнер
36. Переиспользуемые
ПримерUser
service
Report
service
Quartz
service
Payment
service
Acceptcode
service
Filebeat
service
Autopayment
service
Notification
service
Identification
service
Reconciliation
service
Sms
service
Ocelot
API
Push
service
37
37. Пример
Общий код• Нарушение DRY – нормально
• Nuget для того, что фундаментально и не меняется
38. Конфигурация через окружение
Общий код41
39. Общий код
Проблемы и решения40. Общий код
ПроблемыMobileApi
WebApi
Платежи
Sms
История
платежей
Брокер сообщений
Отчеты
41. Общий код
Несогласованность данных• Нет ACID-транзакций
• Возможна
несогласованность
Платежи
История
платежей
+1
0
Брокер сообщений
42.
Отложенная согласованность насобытиях
CRON
Local transaction
Платежи
Id
Amount
Id
Data
State
1
1000
1
{…}
New
+1
История
платежей
+1
Брокер сообщений
43. Проблемы
Идемпотентность• Повторы неизбежны
• Делайте методы идемпотентными
• Регистрируйте уже принятые ID событий
• Игнорируйте более давние события
44. Несогласованность данных
Трассировка• Единый ID на бизнес-запрос
• Можно использовать ActivityId
• Можно воспользоваться http://opentracing.io/
45. Отложенная согласованность на событиях
ТрассировакаApiGateway
ActivityId
Платежи
Sms
ActivityId
ActivityId
Брокер сообщений
ActivityId = “1234”
GSMОператор
46. Идемпотентность
ТрассировкаActivityId
1234
1234
1234
1234
ServiceName
ApiGateway
Платежи
Sms
GSM Оператор
Logs
Exception
500
47. Трассировка
Версионирование• Необходимо для поддержания обратной совместимости
• Позволяет развивать сервисы
48. Трассировака
ВерсионированиеREST
v1
ApiGateway
v2
Платежи
v1
v2
AMQP
v1
Sms
v1
v2
v2
49. Трассировка
ТестированиеПлатежи
v1
Unit
Integration
End-to-end
Sms
Unit
v1
v2
v5
v9
Integration
v2
50. Версионирование
TestContainersСервис 1
Код
Unit
Сервис 3
Intergration
Зависимости
51. Версионирование
Развёртывание52. Тестирование
Проблема• Развертывать >25 сервисов
• А если с 6-кратным дублированием
• И 50 сборок в день
• А с тестированием что?
• Релизы >1 релиза в день
53. TestContainers
Решение• DevOps
• DevOps
• И..
• Конечно, DevOps
54.
VM or ContainerVM
Container
• Долго поднимается
• Инфраструктура
настраивается
• Медленно «переезжает»
• Быстро поднимается
• Инфраструктура внутри
• Легко «переезжает»
55. Проблема
VM или (Container + Оркестрация)VM
Container + оркестрация (k8s)
• AutoScaling – вручную
• AutoDescovery – вручную
• Supervising – вручную
• Blue/Green deploy – вручную
• Балансировка – в ручную
• AutoScaling – из коробки
• AutoDescovery – из коробки
• Supervising – из коробки
• Blue/Green deploy – из
коробки
• Балансировка – из коробки*
56. Решение
Гибкость16.00 – 21.00
vm2
vm1
X1
X2
Отчеты
Акции
Акц
X3
Платежи
X1
X1
Sms
История
платежей
X2
X1
Sms
Платежи
История
платежей
cloud
Отчеты
X3
X2
Платежи
57. VM or Container
ВопросыВетчинкин Кирилл
https://www.facebook.com/k.vetchinkin
[email protected]