1

MicroservicesPros and cons.

Speaker Vyacheslav Mikhaylov (vmikhaylov@dataart.com)

IT Talks

2

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

3

Монолит

4

МонолитUser Interface

Business Logic Layer

Data Access Layer

DataBase

5

МонолитUser Interface (App1)

Business Logic Layer

Data Access Layer

DataBase

User Interface (App2)

Business Logic Layer

Data Access Layer

6

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

7

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

8

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

9

Приходит он…

10

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

11

CAP “теорема”Согласованность

Доступность Разделяемость

12

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

• ACID• классические монолиты

13

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

(долго согласуются транзакции)

• Монолиты, которым пришлось скалироваться.

14

AP – availability + partitioning• Система доступна с предсказуемым временем отклика• Система распределена • Отказ от целостности результата.

• Eventually consistent• DNS

- Знаете как заинтересовать идиота?- Как?- Завтра расскажу

15

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

НИКАК!

16

Что же делать?

CA

APCP

17

18

Scale Cube

Sharding

Mirroring

Microservices

19

20

21

Microservices & SOA

SOA

Microservices

22

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

23

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

24

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

но решает ее хорошо• Имеет смысл в отрыве от остальных

сервисов

25

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

изменений другого• IoC, DI

26

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

методы для решения поставленной задачи

27

High cohesion vs SRP• У нас есть класс, отвечающий за управление кухней

• SRP – Класс содержит методы по управлению только КУХНЕЙ• HC – Класс содержит ВСЕ методы по управлению кухней

28

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

29

Компоненты

Компонент

Библиотеки

Сервисы

30

Компоненты

Компонент

Независимо заменяемый

Независиморазвертываемый

31

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

32

Группировка по бизнес задачам

UI

BL

DB

Order Management

Order Execution

Market Data

33

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

34

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

ESB

35

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

ESB

36

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

37

Децентрализованное хранений

Service A Service B Service C Service C

38

Сетевое взаимодействие

Service A Service B Service C Service C

39

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

40

Chaos Monkey

41

Design for failure

42

Simple app

43

API Gateway

44

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

45

Service Discovery

46

Service Discovery (Server – Side)

47

Service Discovery (Client – Side)

48

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

49

Message BusЗА ПРОТИВ

Диктует архитектуру Сложно менять контракты

Легко расширять Обычно асинхронны

Построена для скалируемости Нужна хорошая квалификация

Круто звучит Сложности развертывания и поддержки

Есть готовые решения. Написано не нами

50

Event Driven Architecture

51

Event Driven Architecture

52

Event Driven Architecture

53

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

54

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

55

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

Новый домен, нет знаний домена

Прототипы, Быстрое решение

Низкая квалификация (все джуны)

Написал и забыл

Мало денег

56

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

Новый домен, нет знаний домена Точно нужно будет скалировать линейно

Прототипы, Быстрое решение Мы можете обеспечить согласованность на бизнес уровне

Низкая квалификация (все джуны) Высокая квалификация, есть опыт и пара загубленных проектов в прошлом

Написал и забыл Готовы инвестировать в инфраструктуру

Мало денег Много денег

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.

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

Thank youTo be continued…