Презентация доклада Сергея Тимошевского на CodeID - PHP Odessa Conf о процессе перехода с монолитной структуры приложений на микросервисную архитектуру.
25 июня прошла первая встреча одесского PHP сообщества на конференции CodeID - PHP Odessa Conf.
Больше о конференции и сообществе:
http://codeid.com.ua/
https://www.facebook.com/codeidua/
https://twitter.com/Code_ID_UA
Группа для общения в LinkedIn:
https://www.linkedin.com/groups/13535615
Чат в Telegram:
https://t.me/codeidua
2. AGENDA
1. Рано или поздно монолит становится проблемой
2. Микросервисы!
3. Так много вопросов
4. Проблемы
5. Миграция
2 слайд из 27
3. ● Одна база данных
● Высокая связность кода
● Наращивание функциональности становится
проблемой
● Усложненный деплой и откат
● Высокий порог вхождения для новых разработчиков
РАНО ИЛИ ПОЗДНО МОНОЛИТ СТАНОВИТСЯ ПРОБЛЕМОЙ
3 слайд из 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
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
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
26. 1. Решаем какой компонент мы будем выносить
2. Определяем как будет реализовано взаимодействие
3. Подготавливаем существующего кода
4. Выносим код и данные в сервис
5. Оставляем обратную совместимость
6. Запускаем сервис
МИГРАЦИЯ
26 слайд из 27
как мы решили, что пора переходить на микросервисы и почему монолит перестал нас устраивать
что такое микросервисы
какие были первые шаги - с чего начали мы, с какими проблемами столкнулись и как мы их решили
что в итоге у нас получилось, какие плюсы/минусы
Данный подход предусматривает разделение приложения на независимые (мало-зависимые) компоненты и вынесение их в отдельные микросервисы.
Общее представление разницы монолитного приложения от микро-сервисного можно представить в следующем виде.
Когда у вас уже зрелый монолит вы уже примерно представляете из каких функциональных компонентов он состоит.
К тому же, как правило, в крупных компаниях разделение на компоненты происходит эволюционным путем само по себе по закону Конвея.
В компаниях с большим монолитом в команде разработчиков вряд ли найдется человек который знает абсолютно все участки кода. Особенно если над монолитом работает большое количество человек. Обычно вся команда разработчиков со временем делиться на подкоманды, каждая их которых занимается своей частью монолита: это импорт данных, каталог, процессинг заказов, оплаты и т.п.
Вот вам первый указатель как делить на компоненты. Дальше возможна более глубокая декомпозиция.
Каждый микросервис отвечает за свою часть бизнес-логики и знает минимум о существовании других сервисов. Поинт в том, чтоб сервис только знал какие доступны у него АПИ-вызовы, для получения необходимых для его работы данных и не имел представления о том, кому его данные могут понадобиться.
Основной подход - ивенты: когда продукт -> промо-блок, каталог, серч, feeds
Исключение - диспетчер: пеймент -> ордер -> thx page
Написать +/-
Написать +/-
Схема
Механизм exchange
Типы сообщений с данными и без
Очередь на стороне Паблишера