Шаблоны проектирования для микросервисов

• Приветствие участников первой сессии первого модуля.  

• Важные организационные моменты: использование чата, вопросы и ответы, реакция на сессию.  

• Представление докладчика Александра Бармина.  

• Александр Бармин, инженер в компании EPAM, рассказывает о проектировании микросервисов.  

• Дисклеймер: нет единственно правильного решения для проектирования микросервисов.  

• Важность разнообразия подходов и паттернов.  

• Проблемы, возникающие при переходе от монолитного приложения к микросервисам.  

• Трудности в разделении приложения на микросервисы и их взаимодействии.  

• Введение в стратегии декомпозиции и паттерны.  

• Сервис включает запросы, команды, публикации и ивенты.  

• Важность определения системных операций и требований.  

• Начало проектирования с чтения требований и определения системных операций.  

• Три шага: чтение требований, разделение на сервисы, определение взаимодействия между сервисами.  

• Стратегии разделения по бизнес-функциям и саб-доменам.  

• Важность разделения по бизнес-побити для одного сервиса.  

• Организация надежного взаимодействия между сервисами.  

• Классический request-response и асинхронное взаимодействие.  

• Примеры и паттерны для организации взаимодействия.  

• Синхронное взаимодействие требует уникального идентификатора для каждого запроса.  

• Пример: запрос баланса у мобильного оператора.  

• Недостаток: все клиенты и серверы должны быть доступны одновременно.  

• Асинхронное взаимодействие использует очереди или промежуточные хранилища.  

• Пример: клиенты отправляют запросы в очередь, а серверы забирают их по мере необходимости.  

• Плюсы: масштабируемость и независимость от доступности всех сервисов.  

• Минусы: усложнение обработки ошибок и непредсказуемость времени обработки запросов.  

• Гексагональная архитектура использует прокси для вызова удаленных процедур.  

• Прокси позволяет обрабатывать частичные отказы и реализовывать паттерны.  

• Пример: обработка заказов и повторные попытки при недоступности сервиса.  

• Масштабирование: запуск нескольких экземпляров сервиса для обработки запросов.  

• Паттерн сервис Discovery: регистрация сервисов на уровне приложений или инфраструктуры.  

• Application Level Service Discovery: балансировка нагрузки и тестирование.  

• Platform Level Service Discovery: избавление от головной боли, но ограниченные возможности.  

• Асинхронное взаимодействие предпочтительнее синхронного.  

• Используйте готовые решения, такие как Spring Cloud Streams или Quarkus.  

• Важно не изобретать велосипеды и использовать проверенные решения.  

• Архитектура с брокером позволяет сервисам не знать друг о друге.  

• Брокер буферизирует сообщения и может временно хранить их.  

• Брокер добавляет сложность и может стать узким местом.  

• Архитектура без брокера позволяет сервисам отправлять сообщения быстрее.  

• Сервисы должны знать друг о друге для отправки сообщений.  

• Брокер не гарантирует стопроцентную надежность и может привести к повторной доставке сообщений.  

• Для решения проблемы повторной доставки используйте транзакции или записывайте идентификаторы обработанных сообщений.  

• Сообщения должны отправляться в промежуточное хранилище для надежности.  

• Синхронное взаимодействие снижает доступность системы.  

• Используйте очереди для асинхронного взаимодействия с внешними сервисами.  

• Клиенты могут быть недовольны длительным ожиданием ответов.  

• Используйте репликацию данных для снижения нагрузки на внешние сервисы.  

• Репликация может привести к дополнительным затратам и проблемам с лагами.  

• Service Discovery полезен при миграции приложений и для обработки запросов.  

• Spring Cloud предоставляет множество стратегий для выбора подходящего клиента.  

• Используйте стратегии деградации производительности или возвращайте заготовленные значения из кэша.  

• Подбирайте стратегии, подходящие для вашей конкретной ситуации.  

• Репликация может не успевать за изменениями данных.  

• Транзакционная отправка сообщений позволяет мониторить таблицы и базы данных.  

• Разделение запросов на получение и изменение данных помогает повысить доступность.  

• В монолитной архитектуре запросы обрабатываются контроллером.  

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

• Паттерн пей композитор объединяет ответы от разных сервисов.  

• Пей композитор может не справляться с запросами на получение списков.  

• Разделение запросов на CRUD и поиск помогает оптимизировать работу.  

• Использование текстовых баз данных для поиска улучшает производительность.  

• Пей композитор прост, но усложняет архитектуру.  

• Секвест позволяет разделить запросы, но добавляет дополнительные базы данных.  

• Репликация данных остается важной проблемой.  

• Внешние клиенты могут быть мобильными приложениями.  

• P2P-гейтплей решает проблему множественных запросов.  

• P2P может кэшировать запросы, выполнять аутентификацию и логирование.  

• Использование паттерна BF для разработки P2P-гейтплей.  

• Каждая команда разрабатывает P2P для своих клиентов.  

• Общий слой обеспечивает взаимодействие между командами.  

• Команды разделяются и работают независимо.  

• Надежность микросервисов зависит от управления конфигурациями и обермобилити.  

• Важно понимать, как сделать микросервисы надежными.  

• Внешние сервисы, такие как Kafka, рассматриваются как ресурсы.  

• Для подключения к внешним сервисам нужны параметры, зависящие от окружения.  

• Управление конфигурациями помогает определить, где живут сервисы.  

• Первый подход: инфраструктура предоставляет переменные окружения.  

• Второй подход: использование сторонних сервисов для управления конфигурациями.  

• Spring Cloud Config и Amazon Parameter Store помогают реализовать этот подход.  

• Мониторинг помогает отслеживать состояние сервисов.  

• Трассировка помогает понять, как запросы проходят через систему.  

• Метрики позволяют оценить производительность и ресурсы.  

• Важно обеспечить надежность коммуникаций и обработки запросов.  

• Необходимо учитывать проблемы, такие как Middleware, Discovery, и разделение данных.  

• Рекомендуется использовать шаблоны для генерации микросервисов.  

• Вопросы можно задавать по почте или в телеграме.  

• Рекомендована книга "12 факторов для построения мобильных приложений".  

• Для конфигурации в разных фреймворках стоит изучить Google Books.