36-ая встреча IT talk Spb (18/02/2016) «Microservices. Как правильно делать и когда применять?» Вячеслав Михайлов, Solutions Architect, DataArt http://it-talk.dataart.ru/events/events-spb/2016/02/priglashaem-druzej-na-36-j-it-talk-v-peterburge/

1. Microservices
Pros and cons.
Speaker Vyacheslav Mikhaylov (vmikhaylov@dataart.com)
IT Talks
1

2. О чем доклад?
• Что такое микросервисы?
• Немного теории
• За и против различных типов архитектур
• Способы взаимодействия сервисов
• Когда делать монолит, а когда микросервисы?
2

3. Монолит
3

4. Монолит
4
User Interface
Business Logic Layer
Data Access Layer
DataBase

5. Монолит
5
User Interface (App1)
Business Logic Layer
Data Access Layer
DataBase
User Interface (App2)
Business Logic Layer
Data Access Layer

6. Проблемы
6
• Растет сложность системы
• Сложно поддерживать
• Не разобраться

7. Проблемы
7
• Много багов
• Мало тестов
• Дорого вносить изменения

8. Проблемы
8
• Застревание на технологиях

9. Приходит он…
9

10. Развитие системы
10
• Как сделать систему доступной из разный регионов?
• Как обеспечить согласованность данных?
• Как ускорить систем в N раз?

11. CAP “теорема”
11
Согласованность
Доступность Разделяемость

12. CA – consistency + availability
• Данные во всех узлах согласованы
• Обеспечена доступность
• Жертвуем распадом на секции
• ACID
• классические монолиты
12

13. CP – consistency + partitioning
• Данные во всех узлах согласованы
• Способна разделяться на независимые секции
• Жертвуем отсутствием отклика
(долго согласуются транзакции)
• Монолиты, которым пришлось
скалироваться.
13

14. AP – availability + partitioning
• Система доступна с предсказуемым временем отклика
• Система распределена
• Отказ от целостности результата.
• Eventually consistent
• DNS
14
- Знаете как заинтересовать идиота?
- Как?
- Завтра расскажу

15. Развитие системы
15
• Как сделать систему доступной из разный регионов?
• Как обеспечить согласованность данных?
• Как ускорить систем в N раз?
НИКАК!

16. Что же делать?
16
CA
AP
CP

17. 17

18. Scale Cube
18
Sharding
Mirroring
Microservices

19. 19

20. 20

21. Microservices & SOA
21
SOA
Microservices

22. Что такое Микросервисы?
Архитектурный паттерн в котором сервисы:
• Small
• Focused
• Loosely coupled
• Highly cohesive
22

23. Small
• Насколько маленький?
• Разрабатывается одной командой (7±2)
• Одна бизнес задача
• Один человек в состоянии понять сервис
23

24. Focused
• Что значит сфокусированный?
• Решает только одну бизнес задачу,
но решает ее хорошо
• Имеет смысл в отрыве от остальных
сервисов
24

25. Low coupled
• Что такое сильное зацепление и слабое зацепление?
• Изменения одного класса/модуля слабо влияет на необходимость
изменений другого
• IoC, DI
25

26. High cohesion
• Высокое сцепление (согласованность)
• Класс/компонент содержит все нужные
методы для решения поставленной задачи
26

27. High cohesion vs SRP
• У нас есть класс, отвечающий за управление кухней
• SRP – Класс содержит методы по управлению только КУХНЕЙ
• HC – Класс содержит ВСЕ методы по управлению кухней
27

28. Характеристики микросервисов
• Разделение на компоненты (сервисы)
• Группировка по бизнес задачам
• Сервисы имеют бизнес-смысл
• Умные сервисы & простые коммуникации
• Децентрализованное управление
• Децентрализованное управление данными
• Автоматизация развертывания и мониторинга
• Design for failure (Chaos Monkey)
28

29. Компоненты
29
Компонент
Библиотеки
Сервисы

30. Компоненты
30
Компонент
Независимо
заменяемый
Независимо
развертываемый

31. Характеристики микросервисов
• Разделение на компоненты (сервисы)
• Группировка по бизнес задачам
• Сервисы имеют бизнес-смысл
• Умные сервисы & простые коммуникации
• Децентрализованное управление
• Децентрализованное управление данными
• Автоматизация развертывания и мониторинга
• Design for failure (Chaos Monkey)
31

32. Группировка по бизнес задачам
32
UI
BL
DB
Order
Management
Order
Execution
Market Data

33. Характеристики микросервисов
• Разделение на компоненты (сервисы)
• Группировка по бизнес задачам
• Сервисы имеют бизнес-смысл
• Умные сервисы & простые коммуникации
• Децентрализованное управление
• Децентрализованное управление данными
• Автоматизация развертывания и мониторинга
• Design for failure (Chaos Monkey)
33

34. Умные сервисы & простые коммуникации
34
ESB

35. Умные сервисы & простые коммуникации
35
ESB

36. Характеристики микросервисов
• Разделение на компоненты (сервисы)
• Группировка по бизнес задачам
• Сервисы имеют бизнес-смысл
• Умные сервисы & простые коммуникации
• Децентрализованное управление
• Децентрализованное хранение
• Автоматизация развертывания и мониторинга
• Design for failure (Chaos Monkey)
36

37. Децентрализованное хранений
37
Service A Service B Service C Service C

38. Сетевое взаимодействие
38
Service A Service B Service C Service C

39. Автоматизация развертывания и
мониторинга
39

40. Chaos Monkey
40

41. Design for failure
41

42. Simple app
42

43. API Gateway
43

44. Разные типы архитектур
• Service Discovery (RPC Style)
• Message Bus (Event Driven)
• Hybrid
44

45. 45
Service Discovery

46. 46
Service Discovery (Server – Side)

47. Service Discovery (Client – Side)
47

48. Message Bus
• Нужно уметь готовить
• Нужно поддерживать
• Снижение производительности за счет появления брокера
48

49. Message Bus
49
ЗА ПРОТИВ
Диктует архитектуру Сложно менять контракты
Легко расширять Обычно асинхронны
Построена для скалируемости Нужна хорошая квалификация
Круто звучит  Сложности развертывания и поддержки
Есть готовые решения. Написано не нами 

50. Event Driven Architecture
50

51. Event Driven Architecture
51

52. Event Driven Architecture
52

53. Переход от монолита к микросервисам
• Ограниченный бизнес контекст
• Частота изменений
• Структура команды (Conway’s law)
• Меняем то, что сильнее болит
53

54. Как выбрать?
54
Монолит Микросервисы

55. Как выбрать?
55
Монолит Микросервисы
Новый домен, нет знаний домена
Прототипы, Быстрое решение
Низкая квалификация (все джуны)
Написал и забыл
Мало денег

56. Как выбрать?
56
Монолит Микросервисы
Новый домен, нет знаний домена Точно нужно будет скалировать линейно
Прототипы, Быстрое решение Мы можете обеспечить согласованность на бизнес уровне
Низкая квалификация (все джуны)
Высокая квалификация, есть опыт и пара загубленных
проектов в прошлом
Написал и забыл Готовы инвестировать в инфраструктуру
Мало денег Много денег

57. За и против
57
Микросервисы дают преимущества… За счет…
Strong Module Boundaries
Микросервисы усиливают модульную структуру, что
особенно важно для больших команд разработчиков.
Distribution
Тяжелее разрабатывать. Нужен опыт и хороший опыт.
Аvailability
Сервисы могут работать не все
Eventual Consistency
придется иметь дело со слабой (отложенной) целостностью
Technology Diversity
Легко менять технологии, пробовать что-то действительно
подходящее. Правильные инструменты
Operational Complexity
Опытная команда Devop’ов
Independent Deployment
Простые сервисы проще деплоить
Меньше вероятность отказа системы

58. Jeff Bezos Manifesto
• All teams will henceforth expose their data and functionality through
service interfaces.
• Teams must communicate with each other through these interfaces.
• no direct linking
• no direct reads of another team’s data store
• no shared-memory model
• no back-doors whatsoever.
• The only communication allowed is via service interface calls over the network.
• It doesn’t matter what technology they use.
• All service interfaces, without exception, must be designed from the
ground up to be externalizable.
• No exceptions.
58

59. Источники
• https://www.nginx.com/blog/
• https://www.nginx.com/blog/introduction-to-microservices/
• https://www.nginx.com/blog/building-microservices-inter-process-communication/
• http://plainoldobjects.com/presentations/decomposing-applications-for-deployability-and-scalability/
• http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html
• https://lostechies.com/gabrielschenker/2016/01/27/service-discovery/
• http://microservices.io/
• http://martinfowler.com/articles/microservices.html
59

60. Thank you
To be continued…