CodeID - PHP Odessa Conf: Сергей Тимошевский "Все пути ведут к микросервисам"
Download as PPTX, PDF0 likes111 views
Документ описывает переход от монолитной архитектуры к микросервисам, подчеркивая проблемы монолита, такие как высокая связность кода и сложности с масштабированием. Микросервисы рассматриваются как независимые компоненты, которые позволяют улучшить гибкость и производительность приложений за счет легковесных коммуникаций и отдельных кодовых баз. В документе также обсуждаются вопросы миграции на микросервисы и важные теоретические концепции, такие как CAP-теорема.
![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](https://image.slidesharecdn.com/codeid-170717125901/85/CodeID-PHP-Odessa-Conf-15-320.jpg)
![СООБЩЕНИЕ
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](https://image.slidesharecdn.com/codeid-170717125901/85/CodeID-PHP-Odessa-Conf-21-320.jpg)
CodeID - PHP Odessa Conf: Сергей Тимошевский "Все пути ведут к микросервисам"
- 1. Все пути ведут к микроСЕРВИСАМ Сергей Тимошевский
- 2. AGENDA 1. Рано или поздно монолит становится проблемой 2. Микросервисы! 3. Так много вопросов 4. Проблемы 5. Миграция 2 слайд из 27
- 3. ● Одна база данных ● Высокая связность кода ● Наращивание функциональности становится проблемой ● Усложненный деплой и откат ● Высокий порог вхождения для новых разработчиков РАНО ИЛИ ПОЗДНО МОНОЛИТ СТАНОВИТСЯ ПРОБЛЕМОЙ 3 слайд из 27
- 4. МИКРОСЕРВИСЫ! УРА! 4 слайд из 27
- 5. 5 слайд из 27
- 6. МИКРОСЕРВИС (сервис) - независимый компонент приложения, реализующий какую-то одну функциональную часть бизнес-логики 6 слайд из 27
- 7. РАЗДЕЛЕНИЕ НА МИКРОСЕРВИСЫ 7 слайд из 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
- 20. EVENT-DRIVEN ARCHITECTURE Publisher new event Exchange Queue Consumer Consumer Consumer Route ListenQueue Queue 20 слайд из 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
- 24. 24 слайд из 27
- 25. 25 слайд из 27
- 26. 1. Решаем какой компонент мы будем выносить 2. Определяем как будет реализовано взаимодействие 3. Подготавливаем существующего кода 4. Выносим код и данные в сервис 5. Оставляем обратную совместимость 6. Запускаем сервис МИГРАЦИЯ 26 слайд из 27
- 27. СПАСИБО! ВОПРОСЫ? 27 слайд из 27
Editor's Notes
- #3: как мы решили, что пора переходить на микросервисы и почему монолит перестал нас устраивать что такое микросервисы какие были первые шаги - с чего начали мы, с какими проблемами столкнулись и как мы их решили что в итоге у нас получилось, какие плюсы/минусы
- #5: Данный подход предусматривает разделение приложения на независимые (мало-зависимые) компоненты и вынесение их в отдельные микросервисы. Общее представление разницы монолитного приложения от микро-сервисного можно представить в следующем виде.
- #7: Когда у вас уже зрелый монолит вы уже примерно представляете из каких функциональных компонентов он состоит. К тому же, как правило, в крупных компаниях разделение на компоненты происходит эволюционным путем само по себе по закону Конвея.
- #9: В компаниях с большим монолитом в команде разработчиков вряд ли найдется человек который знает абсолютно все участки кода. Особенно если над монолитом работает большое количество человек. Обычно вся команда разработчиков со временем делиться на подкоманды, каждая их которых занимается своей частью монолита: это импорт данных, каталог, процессинг заказов, оплаты и т.п. Вот вам первый указатель как делить на компоненты. Дальше возможна более глубокая декомпозиция.
- #10: Каждый микросервис отвечает за свою часть бизнес-логики и знает минимум о существовании других сервисов. Поинт в том, чтоб сервис только знал какие доступны у него АПИ-вызовы, для получения необходимых для его работы данных и не имел представления о том, кому его данные могут понадобиться. Основной подход - ивенты: когда продукт -> промо-блок, каталог, серч, feeds Исключение - диспетчер: пеймент -> ордер -> thx page
- #17: Написать +/-
- #18: Написать +/-
- #21: Схема Механизм exchange Типы сообщений с данными и без Очередь на стороне Паблишера
- #25: Рассмотрим кейс добавления продукта в корзину.