Микросервисы. Проектирование API

Рет қаралды 27,018

4 жыл бұрын

Как собрать данные для модуля отчётности или UI?
В микросервисной архитектуре данные одного процесса размазаны по нескольким сервисам, при этом могут храниться в разных хранилищах (SQL, NoSQL, ...)
В этом видео рассказывается как можно собрать данные, не перестраивая бизнес сервисы.
Рассмотрены подходы:
1. Объединение API
2. CQRS-представления (витрины)
Рассмотрены способы использования подходов и недостатки каждого из подходов.
* Что почитать
Книга
Крис Ричардсон "Микросервисы. Паттерны разработки и рефакторинга", главы 6-7

Пікірлер: 35

@user-of8fm9py9b 3 жыл бұрын

Хороший контент, не ожидал от такого небольшого канала. Сразу же подписываюсь и буду ожидать новых видео. Спасибо за материал!

@levdubrov9522 Жыл бұрын

Джавистка - БРАВО! Отличная подача, продолжайте и не останавливайтесь.

@uknow2908 3 жыл бұрын

Спасибо за видос! Очень интересно. Что-то новое для себя почерпнул, что редко, потому что про микросервисы обычно говорят одно и то же. А тут прям новое и с хорошей подачей.

@user-lj4jy5pd6m 2 жыл бұрын

Спасибо, очень приятно))

@mr.robespierre 9 ай бұрын

Вау! Вот это уровень! После просмотра ролика мой телефон вышел покурить)

@VkusnyashkaMMM Жыл бұрын

Это очень хороший контент ! Спасибо большое.

@GalievDen1s Жыл бұрын

Спасибо Вам за Ваш труд и пояснение информации, надеюсь будут еще ролики по данной тематике

@alex331911 2 жыл бұрын

Супер материал! Ждем продолжения!

@user-pc5ph7ym7w 3 жыл бұрын

Отличное практико-ориентированное объяснение!

@ivankarash2646 Жыл бұрын

Прекрасный урок, спасибо

@Goga_Furt 9 ай бұрын

Прекрасное объяснение!

@nielsbohr7322 2 жыл бұрын

очень хорошая подача материала!

@javastream9414 3 жыл бұрын

Спасибо, очень помогло.

@user-tj5gt5vg2o 2 жыл бұрын

Повысить качество звука, сделать презентации динамическими и желательно показывать курсором предмет обсуждения. Дополнительно можно добавить анимации и тогда будет самый крутой контент.

@aggretsuko6794 3 жыл бұрын

да, спасибо. первое о чем я подумал после твоего вопроса (3:31) это создание промежуточного сервиса, где данные будут обрабатываться и передаваться клиенту в нужном виде.

@user-lj4jy5pd6m 3 жыл бұрын

микросервисы дают большое поле для идей и различных реализаций. Ну и как следствие, предоставляют много возможностей "выстрелить себе в ногу". Поэтому нет одного правильного ответа на вопрос "как делать", в каждой ситуации нужно анализировать, что лучше подходит, при этом учитывая требования к нагрузке и быстроте выполнения. Я к тому, что можно пробовать другие решения, и эти другие решения тоже могут быть рабочими

@geghamkocharyan9172 3 жыл бұрын

Класс 👍

@Jekklo 3 жыл бұрын

класс. Просто ащще огонь.

@protiv_bio 2 жыл бұрын

Расскажите пожалуйста о разнице микросервисной архитектуры и акторной модели

@arenmkhoyan 4 ай бұрын

Оч круто🎉🎉

@user-uv3uo7cv3c 3 жыл бұрын

Спасибо

@user-wb5dh1ps4x Жыл бұрын

От микросервисов до cqrs)

@mclotos 2 жыл бұрын

есть такая штука как graphQL, которой можно слать запросы, формировать ответы и т.д., у graphql есть такая штука как graph subscribe, которая может уведомлять подписчика о том, что в каком-то сервисе изменились данные. нафига еще какая-то прослойка, которая, о ужас, тоже может уйти в отказ, если есть брокер сообщений (например rabbitmq), который внезапно умеет уведомлять клиента о том, что данные изменились или запрос обработался - оформил подписку и жди сообщения. В итоге имеем rabbit, у которого поднята куча каналов; микросервисы, которые читают/пишут в эти каналы; клиент, который слушает эти события и все они общаются через graphql.

@Deletedeletedelete 9 ай бұрын

А что по кешированию и n+1 у graphql?

@mclotos 9 ай бұрын

@@Deletedeletedelete ну кеширование есть и на серверной стороне и на клиентской, а по n+1 нуу как бы так же как и с rest -- криворукость будет заметна не сразу. Но я об этом не парюсь -- у меня кролик есть и в случае, если какой-то сервис зависнет, то вместо него поднимается новый, а может даже несколько и они какое-то время будут работать вместе, пока нагрузка не упадёт, а потом резервные сервисы опять уйдут в спячку. Можно и без кролика, например через Apollo Gateway, но там не знаю как он балансирует нагрузку и распределяет запросы по сервисам, у меня на кролике дикая маршрутизация настроена

@andreikashin 2 жыл бұрын

нету никаких "коммандных запросов". есть комманды (запись) и запросы (чтение) - вот их и разделяют [CQRS]

@mqtrade5743 3 жыл бұрын

Пару слов для продвижения ролика

@user-jl3cs6gu8r Жыл бұрын

Очень недооцененное полезное видео. Пишу для его продвижения)

@LAV451 Жыл бұрын

Всё классно пока не разарвётся соединение с брокером сообщений. К сожелению в реальности схема будет немного сложнее.

@user-dd3cq7jx8g Жыл бұрын

Кажется, что не правильно api gateway раскрыт, он должен быть максимально простым, а тут на этому уровне предлагают логику накручивать

@user-bu7gb1kf7z 3 жыл бұрын

Тема брокера сообщений не раскрыта. Почему его ввели? Почему он есть во 2 и 3 примерах и нет в 1?

@user-lj4jy5pd6m 2 жыл бұрын

Не удалось объяснить чем отличается подход 1 от подхода 2? Предполагается, что в системе есть брокер. В видео рассказывается, как можно собрать данные в одном месте: в одном случае используется информация, передаваемая через брокера; в другом - идëт обращение к самим сервисам. Если я не ошибаюсь, о надобности брокера в микросервисах рассказывается в более ранних видео, возможно даже в первом видео про микросервисы

@nexsmith8276 9 ай бұрын

Так CQRS - это по сути кэш?

@vladzh2639 Жыл бұрын

Я так понимаю это называется хореография и оркестрация?

@AK-bc4ls Жыл бұрын

Всё бы хорошо, но качество звука... Звонкий и с эхом, будто бы просто с ноутбука в пустой комнате записывали. Для подачи хорошего материала однозначно нужен хороший микрофон, хотя бы петличка для интервью, но никак не удалённые микрофоны в ноутбуках и вебкамерах!