Введение и организационные моменты 0:03 Приветствие участников первой сессии первого модуля. Важные организационные моменты: использование чата, вопросы и ответы, реакция на сессию. Представление докладчика Александра Бармина.
Введение в доклад 1:00 Александр Бармин, инженер в компании EPAM, рассказывает о проектировании микросервисов. Дисклеймер: нет единственно правильного решения для проектирования микросервисов. Важность разнообразия подходов и паттернов.
Проблемы монолитного проектирования 3:56 Проблемы, возникающие при переходе от монолитного приложения к микросервисам. Трудности в разделении приложения на микросервисы и их взаимодействии. Введение в стратегии декомпозиции и паттерны.
Определение сервиса 5:53 Сервис включает запросы, команды, публикации и ивенты. Важность определения системных операций и требований. Начало проектирования с чтения требований и определения системных операций.
Стратегии декомпозиции 9:48 Три шага: чтение требований, разделение на сервисы, определение взаимодействия между сервисами. Стратегии разделения по бизнес-функциям и саб-доменам. Важность разделения по бизнес-побити для одного сервиса.
Взаимодействие между сервисами 12:42 Организация надежного взаимодействия между сервисами. Классический request-response и асинхронное взаимодействие. Примеры и паттерны для организации взаимодействия.
Синхронное взаимодействие 13:41 Синхронное взаимодействие требует уникального идентификатора для каждого запроса. Пример: запрос баланса у мобильного оператора. Недостаток: все клиенты и серверы должны быть доступны одновременно.
Асинхронное взаимодействие 14:40 Асинхронное взаимодействие использует очереди или промежуточные хранилища. Пример: клиенты отправляют запросы в очередь, а серверы забирают их по мере необходимости. Плюсы: масштабируемость и независимость от доступности всех сервисов. Минусы: усложнение обработки ошибок и непредсказуемость времени обработки запросов.
Гексагональная архитектура 18:32 Гексагональная архитектура использует прокси для вызова удаленных процедур. Прокси позволяет обрабатывать частичные отказы и реализовывать паттерны. Пример: обработка заказов и повторные попытки при недоступности сервиса.
Масштабирование и сервис Discovery 21:29 Масштабирование: запуск нескольких экземпляров сервиса для обработки запросов. Паттерн сервис Discovery: регистрация сервисов на уровне приложений или инфраструктуры. Application Level Service Discovery: балансировка нагрузки и тестирование. Platform Level Service Discovery: избавление от головной боли, но ограниченные возможности.
Асинхронное взаимодействие 27:22 Асинхронное взаимодействие предпочтительнее синхронного. Используйте готовые решения, такие как Spring Cloud Streams или Quarkus. Важно не изобретать велосипеды и использовать проверенные решения.
Архитектура с брокером 28:22 Архитектура с брокером позволяет сервисам не знать друг о друге. Брокер буферизирует сообщения и может временно хранить их. Брокер добавляет сложность и может стать узким местом.
Архитектура без брокера 30:19 Архитектура без брокера позволяет сервисам отправлять сообщения быстрее. Сервисы должны знать друг о друге для отправки сообщений. Брокер не гарантирует стопроцентную надежность и может привести к повторной доставке сообщений.
Надежность и повторная доставка 32:18 Для решения проблемы повторной доставки используйте транзакции или записывайте идентификаторы обработанных сообщений. Сообщения должны отправляться в промежуточное хранилище для надежности.
Синхронное взаимодействие и его недостатки 34:16 Синхронное взаимодействие снижает доступность системы. Используйте очереди для асинхронного взаимодействия с внешними сервисами. Клиенты могут быть недовольны длительным ожиданием ответов.
Репликация данных 36:12 Используйте репликацию данных для снижения нагрузки на внешние сервисы. Репликация может привести к дополнительным затратам и проблемам с лагами.
Service Discovery 37:12 Service Discovery полезен при миграции приложений и для обработки запросов. Spring Cloud предоставляет множество стратегий для выбора подходящего клиента.
Рекомендации при недоступности сервиса 40:05 Используйте стратегии деградации производительности или возвращайте заготовленные значения из кэша. Подбирайте стратегии, подходящие для вашей конкретной ситуации.
Репликация и транзакционная отправка сообщений 42:03 Репликация может не успевать за изменениями данных. Транзакционная отправка сообщений позволяет мониторить таблицы и базы данных. Разделение запросов на получение и изменение данных помогает повысить доступность.
Запросы в распределенном приложении 44:00 В монолитной архитектуре запросы обрабатываются контроллером. В микросервисной архитектуре запросы могут быть сложными и требуют разделения. Паттерн пей композитор объединяет ответы от разных сервисов.
Проблемы пей композитора 45:57 Пей композитор может не справляться с запросами на получение списков. Разделение запросов на CRUD и поиск помогает оптимизировать работу. Использование текстовых баз данных для поиска улучшает производительность.
Сравнение пей композитора и секвест 50:51 Пей композитор прост, но усложняет архитектуру. Секвест позволяет разделить запросы, но добавляет дополнительные базы данных. Репликация данных остается важной проблемой.
Внешние клиенты и P2P 51:50 Внешние клиенты могут быть мобильными приложениями. P2P-гейтплей решает проблему множественных запросов. P2P может кэшировать запросы, выполнять аутентификацию и логирование.
Организационные паттерны 54:45 Использование паттерна BF для разработки P2P-гейтплей. Каждая команда разрабатывает P2P для своих клиентов. Общий слой обеспечивает взаимодействие между командами.
Организационные паттерны и надежность микросервисов 55:45 Команды разделяются и работают независимо. Надежность микросервисов зависит от управления конфигурациями и обермобилити. Важно понимать, как сделать микросервисы надежными.
Внешние сервисы и управление конфигурациями 56:42 Внешние сервисы, такие как Kafka, рассматриваются как ресурсы. Для подключения к внешним сервисам нужны параметры, зависящие от окружения. Управление конфигурациями помогает определить, где живут сервисы.
Подходы к управлению конфигурациями 57:41 Первый подход: инфраструктура предоставляет переменные окружения. Второй подход: использование сторонних сервисов для управления конфигурациями. Spring Cloud Config и Amazon Parameter Store помогают реализовать этот подход.
Важность мониторинга и трассировки 59:40 Мониторинг помогает отслеживать состояние сервисов. Трассировка помогает понять, как запросы проходят через систему. Метрики позволяют оценить производительность и ресурсы.
Проблемы и решения в микросервисных приложениях 1:01:34 Важно обеспечить надежность коммуникаций и обработки запросов. Необходимо учитывать проблемы, такие как Middleware, Discovery, и разделение данных. Рекомендуется использовать шаблоны для генерации микросервисов.
Вопросы и рекомендации по литературе 1:05:31 Вопросы можно задавать по почте или в телеграме. Рекомендована книга "12 факторов для построения мобильных приложений". Для конфигурации в разных фреймворках стоит изучить Google Books.
