какие бывают типы микросервисных архитектур (распределенный монолит, слои микросервисов, feature-based микросервисы) и как именно микросервисы взаимодействуют друг с другом в рамках того или иного типа.

2. Ждем всех до 19:35
2

3. Software Craftsmanship
meetup #17
Взаимодействие между
микросервисами
Павел Вейник
CEO @ Hard & Soft Skills

4. Мы снова online
●Зарегистрировались 207
человека
●Наш 17-й митап online
●При поддержке Sam Solutions
●Информационные партнеры
dev.by, tproger.ru
4

5. О митапах
● Часть проекта Hard & Soft Skills
● Поделиться и пообщаться
● Подобрать материал для курсов:
○ Технический лидер
○ От middle developer к senior
engineer, SDET, teamlead...
5

6. План митапов
16. ML Operations for engineers
17. Взаимодействие
микросервисов
17. Kafka как идеально
горизонтально масштабируемая
система
18. hardsoftskills.by/next_meetups
6

7. Сегодня не будет
Рассказа что такое
микросервисы и для чего
Критики микросервисной
архитектуры и подходов
CI/CD для микросервисов,
разбиения на сервисы
7

8. Цель этого митапа
Рассмотреть подходы к
построению взаимодействия
между микросервисами.
Шаблоны, транзакции,
целостность данных...
8

9. План этого митапа
1.Типы мс архитектур
2.Взаимодействие между мс
3.Сага и другие шаблоны
4.Event sourcing, CQRS
5.Команда и мс
6.Вопросы при регистрации
9

10. Типы мс архитектур
● распределенный монолит
● слои микросервисов
● domain-based мс
● stateles vs statefull мс
10

11. Распределенный монолит
● возникает как только вы
начинаете пилить ваш
существующий монолит
● сильная зависимость между
разными сервисами
11

12. Распределенный монолит
Все проблемы монолита:
● изменения расползаются по
сервисам
● сложно масштабировать
● во всех мс много общего кода
и понятий
12

13. Распределенный монолит
Признаки распределенного
монолита:
● болтливые сервисы
● разные сервисы пользуются
общей бд
● при изменениях одного мс
нужно редеплоить другие
13

14. Слои микросервисов
Слой domain API
Слой business API
Слой backend for fronted
Слой клиентского web-app
14

15. 15

16. Слои микросервисов
Улучшенная версия
распределенного монолита
● более управляемая
● сервисы больше
инкапсулируют
● пригодна для команды
большого размера
16

17. Feature-based ms
Каждой фиче по микросервису.
Еще более независимые
сервисы чем при слоях.
Без централизованной
архитектуры скатывается в
монолит.
17

18. Domain-based ms
Domain-driven подход
Контекст каждого мс ограничен
(bounded context)
Инструменты для разбиения:
DDD, bounded contexts, context
maps, events/commands
18

19. 19

20. Domain-based ms
Требуют формальной и более
продуманной работы при
разделении.
Все равно требуют общего кода
и общих данных, но в меньшей
степени чем распр. монолит
20

21. Stateless vs stateful ms
База нужна каждому
приложению, но state нужен не
каждому мс:
● persistent storage
● сессия
● кэши
21

22. Stateless vs stateful ms
22

23. Подходы к взаимодействию
Обмен файлами
Общая бд
Синхронные вызовы
Очередь сообщений
23

24. Оркестрация
Оркестрация - есть центр
координации всех вызовов
между мс
● Параллельная
● Последовательная
24

25. Оркестрация посл.
25

26. Оркестрация посл.
26

27. Хореография
Оркестрация - каждый мс
вызывает нужные ему мс в
нужном ему порядке
● Параллельно
● Последовательно
27

28. Хореография паралл.
28

29. Sync vs async
Оркестрация и хореография
могут быть синхронными и
асинхронными
● через HTTP, gRPC…
● через очередь сообщений
29

30. Оркестрация и wf engines
Слой domain API
CRUD + search + triggers
Слой business API
бизнес-процессы
вызовы domain API
30

31. Оркестрация и wf engines
● Сложная последовательность
вызовов domain API
● Может прерваться ошибкой или
неверным состоянием
● Нужно сохранять состояние
самой последовательности
● Много таких
последовательностей
31

32. Оркестрация и wf engines
Могут помочь wf движки:
● Декларативное описание
процесса (BPMN)
● Хранят состояние процесса
● Предоставляют мониторинг и
другие инструменты
● Подходят если много процессов
32

33. Оркестрация и wf engines
● Camunda
● KissFlow
● Netflix conductor
● Workflowy
● Tallyfy
● Luigi
● ...
33

34. Шаблоны
● Message bus
● Saga
● Transactional outbox
● Retry, timeout, circuit breaker…
● API gateway, reverse proxy
● Load balancer
● CQS, CQRS
● Service per team
34

35. Шаблоны
35
https://www.enterpriseintegrationpatterns.com/

36. Message bus
● Зависимость только по формату
сообщений
● Удобно когда много сервисов
могут реагировать на триггер
● Требует общей
модели/формата данных
36

37. Saga
● “транзакция”,
распространяющаяся по
многим мс
● последовательность локальных
транзакций
● когда 2pc не вариант
● sequence id
37

38. Transactional outbox
38

39. 39

40. Retry, timeout, circuit breaker
www.slideshare.net/veinik/software-
craftsmanship-15-online-reliability-
and-resiliency
40

41. API Gateway
41

42. Вопросы при регистрации
42

43. CQS vs CQRS
● Command-Query Separation
○ get-set
● Command-Query Responsibility
Segregation
○ архитектурный подход в
распределенных системах
○ иногда с event sourcing
43

44. CQRS
44

45. Service per team
45

46. Service per Team
● закон Конвея
○ архитектура повторяет
оргструктуру
● поэтому строить оргструктуру
так, чтобы она индуцировала
хорошую архитектуру
46

47. Контракты
● req-res: Владеет контрактом
запроса тот, кто предоставляет
“сервер”
○ параметры, заголовки, тело
○ валидации
○ формат ответа, HTTP коды
47

48. Контракты
● command (prod-cons, queue):
Владеет контрактом команды тот,
кто предоставляет сервис,
который ее выполняет
○ очередь команд (кому)
○ формат команды
48

49. Контракты
● event (pub-sub): Владеет
контрактом команды тот, кто
генерирует событие
○ тема (подписка) (кому)
○ формат события
49

50. Пример взаимодействия
50

51. Поддержание контракта
Владелец контракта:
● документация (код, swagger,
спеки)
● версии (breaking vs non-breaking
changes)
● способ деплоя (stoppage)
● service discovery
51

52. Поддержание контракта
52

53. Поддержание контракта
Пример контракта:
● https://opensource.zalando.com/r
estful-api-guidelines
53

54. Поддержание контракта
Contract testing:
● pact.io
● Postman
54

55. Курс microservices foundations
● Основы
● Шаблоны и подходы
● Взаимодействие
● Мониторинг и ops
● 3 месяца по 2р в неделю
hardsoftskills.by/microservices
55

56. Ссылки
общее
● https://techrocks.ru/2019/11/13/micro-service-architecture/
● http://agilemindset.ru/%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%80-
%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%B0/
● https://habr.com/ru/post/249183/
● https://martinfowler.com/articles/microservices.html
● https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-
microservice-architecture
распределенный монолит
● https://habr.com/ru/company/piter/blog/453470/
● https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/
● https://blog.newrelic.com/engineering/distributed-monolith-vs-microservices/
слои микросервисов
● https://medium.com/microservices-in-practice/microservices-layered-architecture-88a7fc38d3f1
domain-driven микросервисы
● https://medium.com/walmartglobaltech/building-domain-driven-microservices-af688aa1b1b8
● https://eng.uber.com/microservice-architecture/
stateless vs stateful
● https://www.proud2becloud.com/stateful-vs-stateless-the-good-the-bad-and-the-ugly/
56

57. Ссылки
шаблоны
● https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBus.html
● https://microservices.io/patterns/data/saga.html
● https://microservices.io/patterns/data/transactional-outbox.html
● https://dzone.com/articles/implementing-the-outbox-pattern
● https://microservices.io/patterns/apigateway.html
команда
● https://microservices.io/patterns/decomposition/service-per-team.html
контракты
● https://www.cognizantsoftvision.com/blog/managing-service-contracts-in-microservice-architectures/
● https://cloud.google.com/appengine/docs/standard/java/designing-microservice-api
● https://www.redhat.com/en/blog/achieving-promise-microservices-one-contract-time
contract testing
● https://docs.pact.io/
● https://saucelabs.com/blog/intro-to-contract-testing-getting-started-with-postman
57

58. Задайте мне вопрос
58