SlideShare a Scribd company logo
1 of 27
Все пути ведут к микроСЕРВИСАМ
Сергей Тимошевский
AGENDA
1. Рано или поздно монолит становится проблемой
2. Микросервисы!
3. Так много вопросов
4. Проблемы
5. Миграция
2 слайд из 27
● Одна база данных
● Высокая связность кода
● Наращивание функциональности становится
проблемой
● Усложненный деплой и откат
● Высокий порог вхождения для новых разработчиков
РАНО ИЛИ ПОЗДНО МОНОЛИТ СТАНОВИТСЯ ПРОБЛЕМОЙ
3 слайд из 27
МИКРОСЕРВИСЫ! УРА!
4 слайд из 27
5 слайд из 27
МИКРОСЕРВИС (сервис) - независимый
компонент приложения, реализующий какую-то
одну функциональную часть бизнес-логики
6 слайд из 27
РАЗДЕЛЕНИЕ НА МИКРОСЕРВИСЫ
7 слайд из 27
ЗАКОН КОНВЕЯ
● Организации, проектирующие системы, … вынуждены
производить их, копируя структуры коммуникаций в этих
организациях
● Organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations
8 слайд из 27
ХАРАКТЕРИСТИКИ
● Отдельная кодовая база и хранилище данных
● Легковесные коммуникации
● Независимый деплой
● Stateless
● Изолированность
9 слайд из 27
CAP - ТЕОРЕМА
Выберите
два
свойства
Consistency / Согласованность
во всех вычислительных узлах в один
момент времени данные не противоречат
друг другу
Partition tolerance /
Устойчивость к разделению
расщепление распределенной системы на
несколько изолированных секций не
приводит к некорректности отклика от
каждой из секций
Availability / Доступность
любой запрос к распределенной системе
завершается корректным откликом
А
С P
10 слайд из 27
РАЗДЕЛЯЕМОСТЬ
+
ЦЕЛОСТНОСТЬ
ДОСТУПНОСТЬ
11 слайд из 27
ВЗАИМОДЕЙСТВИЯ СЕРВИСОВ, ОБМЕН ДАННЫМИ
Order Service
Customer
Service
User User
------
---
---
---
12 слайд из 27
ВЗАИМОДЕЙСТВИЯ СЕРВИСОВ, ОБМЕН ДАННЫМИ
Synchronous
Service A
Service B
call
blocked
Asynchronous
return
Service A
Service B
message
13 слайд из 27
Direct API
REST
Method Path Action Used for
GET /users index показать список пользователей
GET /users/:id show показать пользователя по ID
GET /users/new new
вернуть форму для создания нового
пользователя
POST /users create создать нового пользователя
DELETE /users/:id delete удалить пользователя по ID
PATCH /users/:id update изменение данных пользователя по ID
14 слайд из 27
Direct API
JSON-RPC
URL: /calculator/v1/calc
Method: POST
--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
--> {"jsonrpc": "2.0", "method": "foobar, "params": "bar", "baz]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message":
"Parse error"}, "id": null}
15 слайд из 27
SHARED DATABASE
+ Простота реализации
+ Быстрый доступ к
актуальным данным
- Зависимость сервисов
Microservice A Microservice B Microservice C
Database
16 слайд из 27
SHARED DATABASE
Microservice A Microservice B Microservice C
Database
DBAL DBAL DBAL
● Database Abstraction Layer
17 слайд из 27
MESSAGE BUS (EVENT-DRIVEN)
● Отправитель и получатель не знают друг о друге
● Отправитель не дожидается ответа получателя
● Получатель сам определяет интенсивность обработки сообщений
● Согласованность в конечном счете
Microservice A Microservice B Microservice C
Message Bus
18 слайд из 27
КАКУЮ ЗАДАЧУ РЕШАЕМ?
Варианты:
● Удаляем синхронно?
● Cron script?
● Ставим асинхронную задачу на удаление?
Продукт
закончился
на складе
Удалить из
списка продуктов
Удалить из
Google Shopping
19 слайд из 27
EVENT-DRIVEN ARCHITECTURE
Publisher new
event
Exchange
Queue
Consumer
Consumer
Consumer
Route ListenQueue
Queue
20 слайд из 27
СООБЩЕНИЕ
Routing Key: [entityName].[action].[componentName]
{
"version": 1.0
"dataCollection": {"1693341": {"stockData":"Out of Stock"}},
"entityName":"product",
"componentName":"availability",
"action":"update",
"id":"f1696d85-2d93-427e-8f14-d97971a57cb7",
"metaData":{"resourceName":"product.service"},
"time":1498052542
}
21 слайд из 27
ПРОИЗВОДИТЕЛЬНОСТЬ
22 слайд из 27
ПРОИЗВОДИТЕЛЬНОСТЬ
1. Все что возможно - выполняем асинхронно
2. Все что знаем - предвычисляем
23 слайд из 27
24 слайд из 27
25 слайд из 27
1. Решаем какой компонент мы будем выносить
2. Определяем как будет реализовано взаимодействие
3. Подготавливаем существующего кода
4. Выносим код и данные в сервис
5. Оставляем обратную совместимость
6. Запускаем сервис
МИГРАЦИЯ
26 слайд из 27
СПАСИБО! ВОПРОСЫ?
27 слайд из 27

More Related Content

Similar to CodeID - PHP Odessa Conf: Сергей Тимошевский "Все пути ведут к микросервисам"

"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,..."Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
Yandex
 
Дмитрий Дудов. Индустриальная IPS своими руками
Дмитрий Дудов. Индустриальная IPS своими рукамиДмитрий Дудов. Индустриальная IPS своими руками
Дмитрий Дудов. Индустриальная IPS своими руками
Positive Hack Days
 
654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007
ivanov1566353422
 
654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007
efwd2ws2qws2qsdw
 
Cовременный станок верстальщика
Cовременный станок верстальщикаCовременный станок верстальщика
Cовременный станок верстальщика
mcslayer
 
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только одинSECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON
 
DC/OS – больше чем PAAS, Никита Борзых (Express 42)
DC/OS – больше чем PAAS, Никита Борзых (Express 42)DC/OS – больше чем PAAS, Никита Борзых (Express 42)
DC/OS – больше чем PAAS, Никита Борзых (Express 42)
Ontico
 

Similar to CodeID - PHP Odessa Conf: Сергей Тимошевский "Все пути ведут к микросервисам" (20)

Три истории микросервисов / Игорь Беспальчук (CUSTIS)
Три истории микросервисов / Игорь Беспальчук (CUSTIS)Три истории микросервисов / Игорь Беспальчук (CUSTIS)
Три истории микросервисов / Игорь Беспальчук (CUSTIS)
 
Yandex.Frontend: complex services, complex solutions
Yandex.Frontend: complex services, complex solutionsYandex.Frontend: complex services, complex solutions
Yandex.Frontend: complex services, complex solutions
 
"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,..."Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
"Фронтенд в Яндексе: сложные сервисы, непростые решения". Елена Джетпыспаева,...
 
Дмитрий Дудов. Индустриальная IPS своими руками
Дмитрий Дудов. Индустриальная IPS своими рукамиДмитрий Дудов. Индустриальная IPS своими руками
Дмитрий Дудов. Индустриальная IPS своими руками
 
ЮНИТЕСТ. Обеспечение качества ПО для банков
ЮНИТЕСТ. Обеспечение качества ПО для банковЮНИТЕСТ. Обеспечение качества ПО для банков
ЮНИТЕСТ. Обеспечение качества ПО для банков
 
DevSecOps против восстания машин
DevSecOps против восстания машинDevSecOps против восстания машин
DevSecOps против восстания машин
 
654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007
 
654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007654.базы данных создание отчетов в субд ms access 2007
654.базы данных создание отчетов в субд ms access 2007
 
раубичи ронд
раубичи рондраубичи ронд
раубичи ронд
 
Cовременный станок верстальщика
Cовременный станок верстальщикаCовременный станок верстальщика
Cовременный станок верстальщика
 
Евгений Батовский, Николай Птущук "Современный станок верстальщика"
Евгений Батовский, Николай Птущук "Современный станок верстальщика"Евгений Батовский, Николай Птущук "Современный станок верстальщика"
Евгений Батовский, Николай Птущук "Современный станок верстальщика"
 
Промышленные сети в АСУТП. Начальный уровень.
Промышленные сети в АСУТП.  Начальный уровень.Промышленные сети в АСУТП.  Начальный уровень.
Промышленные сети в АСУТП. Начальный уровень.
 
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только одинSECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
 
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только одинSECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
 
Разработка безопасных веб приложений
Разработка безопасных веб приложенийРазработка безопасных веб приложений
Разработка безопасных веб приложений
 
Моделирование для NoSQL БД
Моделирование для NoSQL БДМоделирование для NoSQL БД
Моделирование для NoSQL БД
 
DC/OS – больше чем PAAS, Никита Борзых (Express 42)
DC/OS – больше чем PAAS, Никита Борзых (Express 42)DC/OS – больше чем PAAS, Никита Борзых (Express 42)
DC/OS – больше чем PAAS, Никита Борзых (Express 42)
 
DC/OS more than PAAS
DC/OS more than PAASDC/OS more than PAAS
DC/OS more than PAAS
 
Вебинар: Функциональные возможности HP ArcSight Logger \ ESM
Вебинар: Функциональные возможности HP ArcSight Logger \ ESMВебинар: Функциональные возможности HP ArcSight Logger \ ESM
Вебинар: Функциональные возможности HP ArcSight Logger \ ESM
 
Backendless BaaS. Dinosaurus for Jeeconf 2013
Backendless BaaS. Dinosaurus for Jeeconf 2013Backendless BaaS. Dinosaurus for Jeeconf 2013
Backendless BaaS. Dinosaurus for Jeeconf 2013
 

More from CODEiD PHP Community

Effective codereview | Dave Liddament | CODEiD
Effective codereview | Dave Liddament | CODEiDEffective codereview | Dave Liddament | CODEiD
Effective codereview | Dave Liddament | CODEiD
CODEiD PHP Community
 
Domain Driven Design | Артём Антоненко | CODEID |
Domain Driven Design | Артём Антоненко | CODEID |Domain Driven Design | Артём Антоненко | CODEID |
Domain Driven Design | Артём Антоненко | CODEID |
CODEiD PHP Community
 

More from CODEiD PHP Community (11)

GRASP - General Responsibility Assignment Software Principles
GRASP -  General Responsibility Assignment Software PrinciplesGRASP -  General Responsibility Assignment Software Principles
GRASP - General Responsibility Assignment Software Principles
 
The PHP developer stack for building chatbots | Christoph Rumpel | CODEiD
The PHP developer stack for building chatbots | Christoph Rumpel | CODEiDThe PHP developer stack for building chatbots | Christoph Rumpel | CODEiD
The PHP developer stack for building chatbots | Christoph Rumpel | CODEiD
 
Ioc container | Hannes Van De Vreken | CODEiD
Ioc container | Hannes Van De Vreken | CODEiDIoc container | Hannes Van De Vreken | CODEiD
Ioc container | Hannes Van De Vreken | CODEiD
 
Effective codereview | Dave Liddament | CODEiD
Effective codereview | Dave Liddament | CODEiDEffective codereview | Dave Liddament | CODEiD
Effective codereview | Dave Liddament | CODEiD
 
Contract testing | Евгений Кузьмин | CODEiD
Contract testing | Евгений Кузьмин | CODEiDContract testing | Евгений Кузьмин | CODEiD
Contract testing | Евгений Кузьмин | CODEiD
 
Running microservices successfully | Bastian Hofmann | CODEiD
Running microservices successfully | Bastian Hofmann | CODEiDRunning microservices successfully | Bastian Hofmann | CODEiD
Running microservices successfully | Bastian Hofmann | CODEiD
 
Graphql + Symfony | Александр Демченко | CODEiD
Graphql + Symfony | Александр Демченко | CODEiDGraphql + Symfony | Александр Демченко | CODEiD
Graphql + Symfony | Александр Демченко | CODEiD
 
Mastering message queues | Tobias Nyholm | CODEiD
Mastering message queues | Tobias Nyholm | CODEiDMastering message queues | Tobias Nyholm | CODEiD
Mastering message queues | Tobias Nyholm | CODEiD
 
Symfony4: A new way to develop applications | Antonio Peric | CODEiD
Symfony4: A new way to develop applications | Antonio Peric | CODEiDSymfony4: A new way to develop applications | Antonio Peric | CODEiD
Symfony4: A new way to develop applications | Antonio Peric | CODEiD
 
Domain Driven Design | Артём Антоненко | CODEID |
Domain Driven Design | Артём Антоненко | CODEID |Domain Driven Design | Артём Антоненко | CODEID |
Domain Driven Design | Артём Антоненко | CODEID |
 
CodeID - PHP Odessa Conf: Вячеслав Мозговой "Как сделать сайт быстрым и люб...
CodeID - PHP Odessa Conf: Вячеслав Мозговой "Как сделать сайт быстрым и люб...CodeID - PHP Odessa Conf: Вячеслав Мозговой "Как сделать сайт быстрым и люб...
CodeID - PHP Odessa Conf: Вячеслав Мозговой "Как сделать сайт быстрым и люб...
 

CodeID - PHP Odessa Conf: Сергей Тимошевский "Все пути ведут к микросервисам"

  • 1. Все пути ведут к микроСЕРВИСАМ Сергей Тимошевский
  • 2. AGENDA 1. Рано или поздно монолит становится проблемой 2. Микросервисы! 3. Так много вопросов 4. Проблемы 5. Миграция 2 слайд из 27
  • 3. ● Одна база данных ● Высокая связность кода ● Наращивание функциональности становится проблемой ● Усложненный деплой и откат ● Высокий порог вхождения для новых разработчиков РАНО ИЛИ ПОЗДНО МОНОЛИТ СТАНОВИТСЯ ПРОБЛЕМОЙ 3 слайд из 27
  • 6. МИКРОСЕРВИС (сервис) - независимый компонент приложения, реализующий какую-то одну функциональную часть бизнес-логики 6 слайд из 27
  • 8. ЗАКОН КОНВЕЯ ● Организации, проектирующие системы, … вынуждены производить их, копируя структуры коммуникаций в этих организациях ● Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations 8 слайд из 27
  • 9. ХАРАКТЕРИСТИКИ ● Отдельная кодовая база и хранилище данных ● Легковесные коммуникации ● Независимый деплой ● Stateless ● Изолированность 9 слайд из 27
  • 10. CAP - ТЕОРЕМА Выберите два свойства Consistency / Согласованность во всех вычислительных узлах в один момент времени данные не противоречат друг другу Partition tolerance / Устойчивость к разделению расщепление распределенной системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций Availability / Доступность любой запрос к распределенной системе завершается корректным откликом А С P 10 слайд из 27
  • 12. ВЗАИМОДЕЙСТВИЯ СЕРВИСОВ, ОБМЕН ДАННЫМИ Order Service Customer Service User User ------ --- --- --- 12 слайд из 27
  • 13. ВЗАИМОДЕЙСТВИЯ СЕРВИСОВ, ОБМЕН ДАННЫМИ Synchronous Service A Service B call blocked Asynchronous return Service A Service B message 13 слайд из 27
  • 14. Direct API REST Method Path Action Used for GET /users index показать список пользователей GET /users/:id show показать пользователя по ID GET /users/new new вернуть форму для создания нового пользователя POST /users create создать нового пользователя DELETE /users/:id delete удалить пользователя по ID PATCH /users/:id update изменение данных пользователя по ID 14 слайд из 27
  • 15. Direct API JSON-RPC URL: /calculator/v1/calc Method: POST --> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} <-- {"jsonrpc": "2.0", "result": 19, "id": 1} --> {"jsonrpc": "2.0", "method": "foobar, "params": "bar", "baz] <-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null} 15 слайд из 27
  • 16. SHARED DATABASE + Простота реализации + Быстрый доступ к актуальным данным - Зависимость сервисов Microservice A Microservice B Microservice C Database 16 слайд из 27
  • 17. SHARED DATABASE Microservice A Microservice B Microservice C Database DBAL DBAL DBAL ● Database Abstraction Layer 17 слайд из 27
  • 18. MESSAGE BUS (EVENT-DRIVEN) ● Отправитель и получатель не знают друг о друге ● Отправитель не дожидается ответа получателя ● Получатель сам определяет интенсивность обработки сообщений ● Согласованность в конечном счете Microservice A Microservice B Microservice C Message Bus 18 слайд из 27
  • 19. КАКУЮ ЗАДАЧУ РЕШАЕМ? Варианты: ● Удаляем синхронно? ● Cron script? ● Ставим асинхронную задачу на удаление? Продукт закончился на складе Удалить из списка продуктов Удалить из Google Shopping 19 слайд из 27
  • 21. СООБЩЕНИЕ Routing Key: [entityName].[action].[componentName] { "version": 1.0 "dataCollection": {"1693341": {"stockData":"Out of Stock"}}, "entityName":"product", "componentName":"availability", "action":"update", "id":"f1696d85-2d93-427e-8f14-d97971a57cb7", "metaData":{"resourceName":"product.service"}, "time":1498052542 } 21 слайд из 27
  • 23. ПРОИЗВОДИТЕЛЬНОСТЬ 1. Все что возможно - выполняем асинхронно 2. Все что знаем - предвычисляем 23 слайд из 27
  • 26. 1. Решаем какой компонент мы будем выносить 2. Определяем как будет реализовано взаимодействие 3. Подготавливаем существующего кода 4. Выносим код и данные в сервис 5. Оставляем обратную совместимость 6. Запускаем сервис МИГРАЦИЯ 26 слайд из 27

Editor's Notes

  1. как мы решили, что пора переходить на микросервисы и почему монолит перестал нас устраивать что такое микросервисы какие были первые шаги - с чего начали мы, с какими проблемами столкнулись и как мы их решили что в итоге у нас получилось, какие плюсы/минусы
  2. Данный подход предусматривает разделение приложения на независимые (мало-зависимые) компоненты и вынесение их в отдельные микросервисы. Общее представление разницы монолитного приложения от микро-сервисного можно представить в следующем виде.
  3. Когда у вас уже зрелый монолит вы уже примерно представляете из каких функциональных компонентов он состоит. К тому же, как правило, в крупных компаниях разделение на компоненты происходит эволюционным путем само по себе по закону Конвея.
  4. В компаниях с большим монолитом в команде разработчиков вряд ли найдется человек который знает абсолютно все участки кода. Особенно если над монолитом работает большое количество человек. Обычно вся команда разработчиков со временем делиться на подкоманды, каждая их которых занимается своей частью монолита: это импорт данных, каталог, процессинг заказов, оплаты и т.п. Вот вам первый указатель как делить на компоненты. Дальше возможна более глубокая декомпозиция.
  5. Каждый микросервис отвечает за свою часть бизнес-логики и знает минимум о существовании других сервисов. Поинт в том, чтоб сервис только знал какие доступны у него АПИ-вызовы, для получения необходимых для его работы данных и не имел представления о том, кому его данные могут понадобиться. Основной подход - ивенты: когда продукт -> промо-блок, каталог, серч, feeds Исключение - диспетчер: пеймент -> ордер -> thx page
  6. Написать +/-
  7. Написать +/-
  8. Схема Механизм exchange Типы сообщений с данными и без Очередь на стороне Паблишера
  9. Рассмотрим кейс добавления продукта в корзину.