Создание микросервиса // Демо-занятие курса «Архитектура и шаблоны проектирования»

• Евгений Непомнящий, Java/Kotlin-разработчик, представляет открытый урок по архитектуре и шаблонам программирования.  

• Тема урока: создание микросервисов.  

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

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

• В конце будет рассказ о курсе.  

• Цель урока: показать, как проходят занятия, и познакомить с методикой.  

• ОТУС - образовательное учреждение с образовательной лицензией.  

• Более 130 курсов, более 38 тысяч выпускников, более 600 преподавателей.  

• Курс не фокусируется исключительно на микросервисах, но включает их.  

• Монолит - это одно приложение, которое решает все задачи системы.  

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

• Сложности разработки, мержа, локальной разработки, тестирования и обновления.  

• Основная проблема монолита - большой тайм-то-маркет.  

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

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

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

• Проблемы монолита возникают при увеличении размера приложения.  

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

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

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

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

• Микросервисы можно масштабировать только те, которые требуют этого.  

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

• Микросервисы проще администрировать и поддерживать.  

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

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

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

• Микросервисы отличаются от монолита и обычных сервисов.  

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

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

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

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

• Использование TLS требует установки соединения, что увеличивает время отклика.  

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

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

• Необходимость обработки ошибок и повторов запросов.  

• Разработка микросервисов требует больше усилий из-за отсутствия подсказок IDE.  

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

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

• Обновление микросервисов может происходить не одновременно.  

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

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

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

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

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

• В микросервисах нет общей транзакции на всю систему.  

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

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

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

• Для микросервисов требуется создание стендов для тестирования, где сервисы взаимодействуют с тестовыми данными.  

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

• Для микросервисов требуются оркестраторы нагрузки, такие как Kubernetes.  

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

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

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

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

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

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

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

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

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

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

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

• Описать сценарии использования, системные действия и внешние API.  

• Построить доменную модель и сервисную модель.  

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

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

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

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

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

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

• Ключевые слова в сценариях переводятся на разные языки.  

• Фреймворки, такие как Cucumber, могут преобразовывать сценарии в функциональные тесты.  

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

• Существительные из сценариев становятся сущностями модели.  

• Модель предметной области включает сущности и их атрибуты.  

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

• Операции работают с сущностями и имеют аргументы и возвращаемые результаты.  

• Операции можно формализовать в виде карточек или таблиц.  

• Системные операции привязываются к сервисам.  

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

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

• Сервисы разбиваются по функциям пользователей.  

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

• Пример: поиск товара, просмотр каталога, добавление товара в заказ и т.д.  

• Сервисы разбиваются по глобальным бизнес-возможностям компании.  

• Пример: перевод денег от клиента к клиенту.  

• Способ реализации может меняться, но бизнес-возможность остается неизменной.  

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

• Минимизация межсервисных транзакций упрощает реализацию системы.  

• Подход ориентирован на минимизацию усилий по обеспечению атомарности.  

• Оценивается, насколько разбиение сервисов устраивает.  

• Возможные проблемы: перегруженные или недогруженные сервисы, избыточные или недостающие сервисы.  

• При необходимости разбиение корректируется для улучшения системы.  

• Разбиение сервисов позволяет понять, какой сервис за что отвечает.  

• Привязываются системные операции к конкретным сервисам.  

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

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

• Сервисы описываются формально, например, с помощью карточек в микросервисной архитектуре.  

• Описание сервисов должно быть стандартным и формальным.  

• Неформальное описание сервисов может расходиться с кодом.  

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

• На помощь приходит формальное описание, такое как IDEL.  

• IDEL использует YAML формат для описания ресурсов и методов.  

• Описываются параметры методов и их схемы.  

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

• IDEL позволяет создавать визуальное представление и отправлять запросы.  

• Существуют библиотеки для генерации кода сервера и клиента.  

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

• Описание сервисов можно сгенерировать по уже написанному коду.  

• FDD подход: сначала описание, потом разработка кода.  

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

• IDEL можно использовать для автоматических тестов и заглушек.  

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

• IDEL полезен для различных протоколов, таких как HTTP/REST.  

• Пройдите опрос о занятиях.  

• Курс состоит из двух занятий в неделю, обычно в 20:00 по Москве.  

• После занятий остаются презентации, записи и домашние задания.  

• Домашние задания проверяются и дают фидбек.  

• Со второй половины курса начинается проектная работа.  

• Есть отдельное занятие по защите проектной работы.  

• В чате можно общаться голосом или текстом.  

• Рекомендуется выделять 4-12 часов в неделю на занятия и домашнюю работу.  

• Курс стартует 25 декабря и длится 4 месяца.  

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

• Второй модуль: скорость разработки, паттерны, обработка исключений.  

• Третий модуль: масштабирование, системы обмена сообщениями, интеграция ПО.  

• Четвертый модуль: микросервисы, создание микросервисов, DIOPs.  

• Пятый модуль: финальные консультации и проектная работа.  

• Рекомендация сайта microservice.io и книги "Микросервисные паттерны" Криса Ричардсона.  

• Много литературы по микросервисам, включая "Билдинг микросервисы" Ньюмана.  

• Старт обучения 25 декабря, длительность 4 месяца.  

• Рассматриваются все паттерны проектирования.  

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

• Другие способы взаимодействия: HTTP, RPC, GraphQL.  

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

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

• В конце курса защита проектной работы с презентацией.  

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

• Пройдите опрос для завершения.