Паттерны микросервисной архитектуры часть 1| Microservices architecture patterns part 1

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

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

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

• Первый подход предлагает разделить монолит на отдельные микросервисы, соответствующие каждому бизнес-функционалу или роли.  

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

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

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

• Подход о под доменом: декомпозиция на домены, обучение людей из бизнеса.  

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

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

• Важность: если команда вносит изменения, она отвечает за все, что происходит с сервисом.  

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

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

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

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

• Однако, это может привести к проблемам, если микросервис должен получить данные из другой базы данных.  

• В этом случае, микросервис должен обращаться к базе данных через интерфейс прикладного программирования (ИП), что позволяет ему выполнять полезную логику и валидацию данных.  

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

• Однако, это также имеет свои недостатки, такие как сложность организации доступа к данным и большие объемы данных, которые могут быть сложно анализированы.  

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

• Это позволяет микросервисам обращаться к данным друг друга, но может привести к проблемам с эволюцией и сложностью.  

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

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

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

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

• Это позволяет системе отслеживать и анализировать события, происходящие в реальном времени, и строить аналитику на основе этих событий.  

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

• Однако, этот подход может быть полезен для оптимизации и расширения логики системы.  

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

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

• Оркестрация - это подход, при котором есть единая точка управления, которая следит за процессом создания заказа.  

• Хореография - это подход, при котором каждый микросервис знает только свою часть процесса и взаимодействует с другими микросервисами через сообщения.  

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

• Минусы: сложность реализации, отладки и тестирования, возможность неконсистентности данных в разных микросервисах.  

• Агрегация логов: все логи со всех микросервисов записываются в один лок агрегатор.  

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

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

• Холс чек: мониторинг и запись о том, что микросервис запустился и может работать.  

• Какие паттерны микросервисов использовали в прошлых проектах?  

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

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

• Мониторинг и отладка: опыт работы с трейсом и сбор логов.  

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

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

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

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

• Эвенсорсинг - сложный паттерн, который требует дополнительных решений и задач.  

• Он применяется в системах, где требуется лок событий для проведения аудита.  

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

• Есть готовые решения для оркестрации, такие как кондуктор от Netflix.  

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

• Лучше использовать опенсорс решения, которые уже написаны и переиспользуемы.  

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

• Также обсуждаются балансировщики нагрузки, публичные и закрытые контуры, ипиаги и их функции.  

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

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

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

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