«microservices. Как правильно делать и когда применять?»
Post on 21-Mar-2017
337 Views
Preview:
TRANSCRIPT
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…
top related