02:04 Начало 03:50 Введение в предм область 05:56 Стратегии декомпозиции 12:39 Межпроцессное взаимодействие 18:10 Паттерны для надежности синхр взаимодействия 27:54 Паттерны для надежности асинхр взаимодействия (Messaging) 44:20 Запросы и CQRS 50:48 API Composer vs CQRS 53:18 API Gateway 55:15 BFF 55:55 Production-ready services (про надежность микросервисов) 57:40 Работа с конфигами 1:04:06 Итоги 1:06:00 Вопросы
Вот этот момент где все набивают шишки от микросервисной архитектуры всегда прикольно слушать, т.е. находишь где то монолит прогоняешь телегу что нам ну очень нужно на микросервисы а потом *пук пук среньк среньк* извините бизнес нефига не работает, ну я пошел.
Да, это частая ситуация с микросервисами - вроде в большом монолите все работало, но сложность выросла настолько, что решили разделить. И тут сложность выросла еще больше!
С чего Требования: Функциональные - системные операции Не функциональные - качества Что должна делать система? Понять, какие внешние операции будут? Разделить приложение на отдельные сервисы. (2 стратегии) По бизнес функциям (Внутри больших б.ф ест функции меньше.) Взглянув на функцию управления курьерами, мы понимаем, что она большая. Одна функция свапится на о дельный серфис/приложения. Какие гаицы сервиса и агрегаты. 1 прил - 1 бизнес функция. и по дизайну доменов Начинаем с пректирования ддд. Смотрим какие функции мапятся на большие функции. 3. Определение операций между сервисами. (Между собой обмениватся ?) (Модель запросов и ответов request/response) Запрос - синхронно и ответ ассинхронно. Клиент отправил множество запросов Как понять к какому пришёл ответ? Идентификатор к вопросу и к ответу Ассинхронное взаимодействие. Если есть несколько клиентов и взаимодействие с ними ассинхронно. Publish subscribe У ассинхронного и синхронного взаимодействия... И клиент и сервер должны быть доступны. Если они не доступны - такой запрос не обработать. Каждая система отвечает ассинхронно. Надёжность: Как вызывать сервисы? Бизнес логика - порт. Прокси. Проблемы сильной связи. И через сервисный Удаленный вызов. Месседжинг Не надо из бизнес логики Корреляционный айди. И Приёмник сообщений. Архитектура с брокером или без? Корреляция - триггер и Брокер - прмежуточное хранилище. Записывать обработанные идентификаторы сообщений в промеждуточную таблицу Дублирующиеся сообщения. У каждого серфиса есть приежуточныц буфер, куда он сохр. Сообщения перед отправкой. Чем больше серфисов в обработке запроса - тем меньше надежность системы. Избавиться от асинхронного взаимодействия. И добавляем очередь У него есть промежуточные состояния и хранилища. Если система не требует синхронного ответа. Если требует. Нет ли каких-то данных, кот. Нужны этому серфису входному? Нет и таких у зависимых сервисов? Репликация данных (подход) Какие-то запросы этот сервис может синхронно обрабатывать. Нет единого верного решения. Мы смотрим на варианты. Что мы можем сделать?
После слов что у микросервиса обязательно должен быть api и клиент, слушать его как то перехотелось... Ну и послушав еще немного, убедился, что первое впечатление не обмануло)
Александр, спасибо огромное за доклад!) Очень круто, что получилось уместить такой большой объём информации в один час. Некоторые моменты пересматривал по несколько раз и делал заметки для дальнейшего изучения) Такие обзорные лекции очень помогают в изучении МСА. И подача в целом очень лайтовая, воспринимается очень хорошо)
Это правда. Микросервисы стали хайповой темой и их пытаются натянуть на каждый глобус. Как обычно, взвешиваем все за и против, а потом принимаем решение
Шаблон проекта, по которому создаются новые сервисы. Ближайший аналог - Maven Archetype, из которого можно сразу создать проект с нужной структурой пакетов, заранее добавленными зависимостями и, например, сконфигурированными метриками.
Без обид, чисто замечания как слушателя. Названия паттернов произносится невнятно и тихо , а ведь это главное. Не хватило перевода слайда, как только я перевел текст на слайдах сразу всё становится понятно. Многие термины с англ на русский вооще не правильно перведены и донесены. Причмокивания, кашли, глотания воды, шмыгания тоже придали щепотку отвращения. Ну и самых важных паттернов микросервисов, которые спрашиваются на собезе не было показано и объяснено. Но за работу лайк.
@@konstantinchvilyov9602 С этимо корявыми переводами от каждого знатока мы получаем десяток кривых вариантов на каждое иностранное слово. По 5 названий на каждый английский термин. Что значительно усложняет поиск и сопоставление информации при изучении. Лучше уж использовать оригинальные англоязычные названия. It слишком быстро развивается чтобы успевать давать каждому новому термину общепринятый перевод. Да и развивается оно в первую очередь в англоязычной среде. Один перевод слова Model чего стоит. Образец - sample. Схема - scheme. Шаблон - template, pattern. Hierarchy - так сложно было перевести как иерархия? Заимстованные слова в языке есть и от них никуда не дется, а с текущими темпами развития технологий, только и остаётся что заимствовать и заимствовать. Transactional - Передаточный. Серьёзно? А слово транзакция куда делось? Это устоявшийся перевод и все знают что это значит. Даже в психологии транзакции есть. Тогда можно уже и дургие заимствованные словам переводить, например госпиталь - гостинная
На каждый чих придумали отдельный паттерн. Столько само собой разумеющихся стратегий или коробочных решений, под которые выделили паттерны. Составил короткий список паттернов, которые спрашивают на собесах, и их оказалось порядка 100! Идиотизм. Причем незнание термина паттерна автоматически приравнивают к незнанию самого паттерна/решения. Несколько лет вообще кодил без знания о каких-то паттернах в МСА в 2017-2019гг. Впервые столкнулся с паттернами на очередном цикле собесов. С этим мракобесием надо бороться. Более того, такой подход как будто сразу ограничивает возможности разработчика - он думает только в рамках паттерна и не пытается твочрески подойти и поискать альтернативное решение.
С другой стороны, паттерны помогают разным разработчикам понимать друг друга в разговоре - они говорят на одном языке. Кроме того, паттерны позволяют переиспользовать опыт и не изобретать решения для известных задач. Да, возможно, уменьшает возможности для творчества, однако, с другой стороны, позволяет фокусироваться именно на логике приложения, а не решении инфраструктурных задач.
Звучит странно. При постройке домов архитекторы используют готовый набор архитектурных решений. И странно слышать от строителя многоэтажки "архитекторы мешают мне творчески мыслить, вот я бы крышу совсем по другому прикрутил бы"
02:04 Начало
03:50 Введение в предм область
05:56 Стратегии декомпозиции
12:39 Межпроцессное взаимодействие
18:10 Паттерны для надежности синхр взаимодействия
27:54 Паттерны для надежности асинхр взаимодействия (Messaging)
44:20 Запросы и CQRS
50:48 API Composer vs CQRS
53:18 API Gateway
55:15 BFF
55:55 Production-ready services (про надежность микросервисов)
57:40 Работа с конфигами
1:04:06 Итоги
1:06:00 Вопросы
Вот этот момент где все набивают шишки от микросервисной архитектуры всегда прикольно слушать, т.е. находишь где то монолит прогоняешь телегу что нам ну очень нужно на микросервисы а потом *пук пук среньк среньк* извините бизнес нефига не работает, ну я пошел.
Да, это частая ситуация с микросервисами - вроде в большом монолите все работало, но сложность выросла настолько, что решили разделить. И тут сложность выросла еще больше!
Благодарю Александр, хороший доклад, теория с практическими примерами!
Благодарю за море полезной информации 🤝
Пожалуйста!
Отличный и супер-полезный доклад, спасибо огромное
Просто о сложном . Спасибо!
Рад, что нравится!
Отличный доклад!
Спасибо!
Большое спасибо за доклад
Очеь рад, что понравилось!
С чего
Требования:
Функциональные - системные операции
Не функциональные - качества
Что должна делать система?
Понять, какие внешние операции будут?
Разделить приложение на отдельные сервисы.
(2 стратегии)
По бизнес функциям
(Внутри больших б.ф ест функции меньше.)
Взглянув на функцию управления курьерами, мы понимаем, что она большая.
Одна функция свапится на о дельный серфис/приложения.
Какие гаицы сервиса и агрегаты.
1 прил - 1 бизнес функция.
и по дизайну доменов
Начинаем с пректирования ддд. Смотрим какие функции мапятся на большие функции.
3. Определение операций между сервисами. (Между собой обмениватся ?)
(Модель запросов и ответов request/response)
Запрос - синхронно и ответ ассинхронно.
Клиент отправил множество запросов
Как понять к какому пришёл ответ?
Идентификатор к вопросу и к ответу
Ассинхронное взаимодействие.
Если есть несколько клиентов и взаимодействие с ними ассинхронно.
Publish subscribe
У ассинхронного и синхронного взаимодействия...
И клиент и сервер должны быть доступны.
Если они не доступны - такой запрос не обработать.
Каждая система отвечает ассинхронно.
Надёжность:
Как вызывать сервисы?
Бизнес логика - порт. Прокси.
Проблемы сильной связи.
И через сервисный
Удаленный вызов.
Месседжинг
Не надо из бизнес логики
Корреляционный айди.
И
Приёмник сообщений.
Архитектура с брокером или без?
Корреляция - триггер и
Брокер - прмежуточное хранилище.
Записывать обработанные идентификаторы сообщений в промеждуточную таблицу
Дублирующиеся сообщения.
У каждого серфиса есть приежуточныц буфер, куда он сохр. Сообщения перед отправкой.
Чем больше серфисов в обработке запроса - тем меньше надежность системы.
Избавиться от асинхронного взаимодействия. И добавляем очередь
У него есть промежуточные состояния и хранилища.
Если система не требует синхронного ответа.
Если требует.
Нет ли каких-то данных, кот. Нужны этому серфису входному?
Нет и таких у зависимых сервисов?
Репликация данных (подход)
Какие-то запросы этот сервис может синхронно обрабатывать.
Нет единого верного решения. Мы смотрим на варианты. Что мы можем сделать?
Моделировать - создавать образ, строить схему.
Информативно, спасибо за доклад
Очень рад, что понравилось
capacity, capability - возможность, способность
Очень крутой докладб доходчиво и понятно, спасибо!!!
Service это служба, обслуживание, предоставление услуг.
Спасибо! Офигенно полезная информация!
Спасибо!
Domain Driven Design - предметно-ориентированное проектирование.
лучшее что я нашел!
Очень круто, спасибо тебе.
Очень рад, что нравится
@@ABarminя так понимаю, ты реализуешь верхушку пирамиды Маслоу, общественное признание? Очень хорошо получается. Рекомендую всем айти корешам 😀
Мапится - Map - отображается, сопоставляется, каптируется.
После слов что у микросервиса обязательно должен быть api и клиент, слушать его как то перехотелось... Ну и послушав еще немного, убедился, что первое впечатление не обмануло)
hierarchy - вертикаль, соподчинённость
Александр, спасибо огромное за доклад!) Очень круто, что получилось уместить такой большой объём информации в один час. Некоторые моменты пересматривал по несколько раз и делал заметки для дальнейшего изучения) Такие обзорные лекции очень помогают в изучении МСА. И подача в целом очень лайтовая, воспринимается очень хорошо)
Главный паттерн микросервисной архитектуры - не использовать микросервисную архитектуру, если в ней нет настоящей необходимости.
Это правда. Микросервисы стали хайповой темой и их пытаются натянуть на каждый глобус. Как обычно, взвешиваем все за и против, а потом принимаем решение
Что ж поделать
Все люто дрочат сейчас на микросервисы
Ну, ничего
Скоро отпустит
Нету никакой микросервисной архитектуры, не существует. Epam Chief executive UK... Позор бля
Model - образец, схема, шаблон
Т.е разложение по предметам или возможностям.
Главный Паттерн докладчика это чмокать в микрофон+_+. А так интересный материал и видео получилось.
Ахахах! Это точно +1!
Пересказ книги "Микросервисы" От Криса Ричардсона
лучше мне кажется ничего не придумали пока)
Service discovery - обнаружение службы.
зачем вы все это написали? вы же наверное на английском языке программируете и читаете документацию и статьи. К чему этот перевод?
@@dardev6471 Чтобы точно понимать, что это значит.
Спасибо. Полезная информация. Но часто сложно понять на каком языке вы говорите следующее слово и что оно значит.
хотел узнать, что такое паттерн Service Template, прозвучал ли он в видео?
Шаблон проекта, по которому создаются новые сервисы. Ближайший аналог - Maven Archetype, из которого можно сразу создать проект с нужной структурой пакетов, заранее добавленными зависимостями и, например, сконфигурированными метриками.
Без обид, чисто замечания как слушателя. Названия паттернов произносится невнятно и тихо , а ведь это главное. Не хватило перевода слайда, как только я перевел текст на слайдах сразу всё становится понятно. Многие термины с англ на русский вооще не правильно перведены и донесены. Причмокивания, кашли, глотания воды, шмыгания тоже придали щепотку отвращения. Ну и самых важных паттернов микросервисов, которые спрашиваются на собезе не было показано и объяснено. Но за работу лайк.
Спасибо за замечания. Надеюсь, более новые видео более хорошего качества.
37:30 Вопросы
жесть, че то слишком сложна
sub-domain - под-предмет, подобласть.
Самому не тошно от такого перевода?
@@vb7038 Нет. А что не нравится?
@@konstantinchvilyov9602 С этимо корявыми переводами от каждого знатока мы получаем десяток кривых вариантов на каждое иностранное слово. По 5 названий на каждый английский термин. Что значительно усложняет поиск и сопоставление информации при изучении. Лучше уж использовать оригинальные англоязычные названия. It слишком быстро развивается чтобы успевать давать каждому новому термину общепринятый перевод. Да и развивается оно в первую очередь в англоязычной среде. Один перевод слова Model чего стоит. Образец - sample. Схема - scheme. Шаблон - template, pattern. Hierarchy - так сложно было перевести как иерархия? Заимстованные слова в языке есть и от них никуда не дется, а с текущими темпами развития технологий, только и остаётся что заимствовать и заимствовать. Transactional - Передаточный. Серьёзно? А слово транзакция куда делось? Это устоявшийся перевод и все знают что это значит. Даже в психологии транзакции есть. Тогда можно уже и дургие заимствованные словам переводить, например госпиталь - гостинная
На каждый чих придумали отдельный паттерн. Столько само собой разумеющихся стратегий или коробочных решений, под которые выделили паттерны. Составил короткий список паттернов, которые спрашивают на собесах, и их оказалось порядка 100! Идиотизм. Причем незнание термина паттерна автоматически приравнивают к незнанию самого паттерна/решения. Несколько лет вообще кодил без знания о каких-то паттернах в МСА в 2017-2019гг. Впервые столкнулся с паттернами на очередном цикле собесов. С этим мракобесием надо бороться. Более того, такой подход как будто сразу ограничивает возможности разработчика - он думает только в рамках паттерна и не пытается твочрески подойти и поискать альтернативное решение.
С другой стороны, паттерны помогают разным разработчикам понимать друг друга в разговоре - они говорят на одном языке. Кроме того, паттерны позволяют переиспользовать опыт и не изобретать решения для известных задач.
Да, возможно, уменьшает возможности для творчества, однако, с другой стороны, позволяет фокусироваться именно на логике приложения, а не решении инфраструктурных задач.
в коммерческой разработке сайтов нет места творчеству, особенно при работе по спринтам... к сожалению
Звучит странно. При постройке домов архитекторы используют готовый набор архитектурных решений. И странно слышать от строителя многоэтажки "архитекторы мешают мне творчески мыслить, вот я бы крышу совсем по другому прикрутил бы"
Есть свист от микрофона в видео мешает слушать
Спасибо, поменял микрофон и сейчас вроде бы получше.
Комментарии про то, что спикер чавкает. Походу следующие комментарии будут про то, что он открывает рот....
Да вообще!
Много чавкает
Ой, это, видимо, случайно так получается