Три истории микросервисов
TRANSCRIPT
ПРОГРАММА ВСТРЕЧИ| Максим Смирнов, свободный эксперт, ex: Вымпелком, Банк России
Барьеры микросервисной архитектуры
| Юрий Веретельников, Solit CloudsПочему в нашем решении никогда не появятся микросервисы
| Андрей Солощак, БинбанкОпыт построения микросервисной архитектуры в цифровом банке
Wi-Fi: CUSTIS | Public@CUSTIS | Facebook.com/CUSTIS.Russia1 | 30
ТРИ ИСТОРИИ МИКРОСЕРВИСОВ
Игорь БеспальчукРуководитель проектов
CUSTIS Meetup 16 марта 2017 года
МОЕ ЗНАКОМСТВО С ТЕМОЙ| Ноябрь 2012 – первые упоминания:
“Micro Services: Java, the Unix Way”, QCon, Джеймс Льюис| 2014 – большая статья “Microservices” на сайте Мартина Фаулера| 2014–2015 – попытки найти живой опыт в российском
корпоративном секторе| 2016 – «что-то» начало находиться
3 | 30
ИНТЕРЕС В СЕТИВставка рисунка
4 | 30
КОНФЕРЕНЦИИ И КНИГИВставка рисунка
5 | 30
6 | 30
ИСТОРИЯ ПЕРВАЯEnterprise и Web как два мира
7 | 30
Вставка рисунка
8 | 30
Вставка рисунка
9 | 30
ПУТИ РАЗВИТИЯ| Enterprise – из классического бизнеса с предоставлением
товаров и услуг через автоматизацию все большего числа внутренних функций
| Web – из предоставления чисто цифровых услуг или с существенной долей цифровых услуг
10 | 30
ЭВОЛЮЦИОННОЕ ДАВЛЕНИЕ В WEB| Отсутствие физических ограничений на рост| Взрывной рост новых видов услуг| Жесткая конкуренция за неограниченный объем клиентов| Требования к UI/UX, нагрузке и масштабированию, развиваемости| Частая смена технологий, не успевает сформироваться устойчивая
инфраструктура и архитектурный стиль (мало: LAMP)| Волна развития Open Source, не сформирован культ тяжелого вендора| Результат: некоторые выжили, породив ряд технических
и организационных паттернов, помогающих отработать требования
11 | 30
Вставка рисунка
Web-scale architecture
Micro-services
CQRS
Event Driven
Event Sourcing
Actor Model
Polyglot Persistence
NoSQL
Domain Driven Design
12 | 30
Вставка рисунка
Microservices?
13 | 30
ИСТОРИЯ ВТОРАЯАрхитектурные стили ПО предприятия
14 | 30
РАЗВИТИЕ АРХИТЕКТУРНЫХ СТИЛЕЙ| От проблемы к проблеме| Через решение (паттерн)| От более простого к более сложному
* Сложность никогда не уменьшается, как иногда может показаться, она «выпадает в осадок» в виде инфраструктуры
15 | 30
All-in-onecomputer
Хранение Логика UI
Аппаратура
ОС, файлы
Вставка рисунка
16 | 30
Client PCFile server Client PC
Хранение Логика UI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Хранение и доступ к данным
Вставка рисунка
17 | 30
Client PCRDBMS Client PC
SQL Логика UI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Схемы данных
Хранение данных Доступ к данным
SP Вставка рисунка
18 | 30
App ServerRDBMS Client PC
ЛогикаUI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Хранение данных
Схемы данных SPSQL UI
UI-компоненты
HTML-браузер
Логика
Аппаратура
ОС, файлы
Сетевой доступ
Доступ к данным
Интеграция
Вставка рисунка
19 | 30
App ServerRDBMS Client PC
Логика
UI
Хранение данных
SQL
UI-компоненты
HTML-браузер
Логика
Доступ к данным
Интеграция
Web Server
Логика UI
ESB
Сообщения
BPMS
Workflow
Аппаратура + VM
ОС, файлы Сетевой доступ
Маршрутизация
… …
Схемы данных SP
Вставка рисунка
20 | 30
ПРИЧИНЫ РАЗДЕЛЕНИЯ ФУНКЦИЙ| Децентрализация| Повышение автономности| Масштабирование по производительности| Специализация| Интеграция разделенного
21 | 30
Custom App ServiceБД (разные) Client Device
Логика UI
Хранение данных
Схемы данных SP
Composite UI
Логика
Доступ к данным
Интеграция
App Gateway
Представление
Messaging BPMS
Workflow
Аппаратура (+VM)
ОС, файлы, clouds, distributed FS Сетевой доступ
Discovery Monitoring HA Logging Auto scaling …
Common App Services
Common App Services
Common App Services
Маршрутизация
22 | 30
Service 3
RDBMS Service 2
Пользователь
Fast DB
Rich Browser
Service 1Big DB App Gw 1
App Gw 2
Doc DB
Пользователь
Mobile DeviceApp Gw 3
Spec DB
23 | 30
РЕЗЮМЕ О СТИЛЯХ| MSA – очередной шаг в развитии архитектурных стилей
сложных программных систем предприятия| MSA продолжает общее движение в сторону специализации,
грануляризации и выделения общих инфраструктур| Как и все предыдущие шаги, MSA решает часть проблем, которые
возникают (обычно) в предшествующих стилях, и порождает ряд новых
* Появляющиеся новые инфраструктуры могут подталкивать к переходу к новым архитектурным стилям, даже если реальной потребности еще не возникло
24 | 30
ИСТОРИЯ ТРЕТЬЯРоль и специализации архитектора
Вставка рисунка
25 | 30
SW
DevArch
Mgr
А
26 | 30
Информационная архитектураИнтеграция приложений
Инфраструктура (техническая архитектура)
Вставка рисунка
27 | 30
Информационная архитектура
Решение
Архитектура сервиса
Инфраструктура
Технологический каркас
28 | 30
ТРИ ИСТОРИИ РАЗВИТИЯ| Рыночных потребностей в мирах Web и Enterprise| Архитектурных стилей программных систем предприятия| Специализаций роли архитектора
…подводящие к появлению микросервисной архитектуры?
29 | 30
