Привет, Хабр! Сегодня поговорим о нюансах разработки событийно-ориентированных микросервисов на Python. Я расскажу, почему считаю Python подходящим для разработки микросервисов, и на что стоит обращать внимание при разработке таких микросервисов. Меня зовут Алексей Некрасов, я лидер направления Python в МТС и программный директор курсов по Python в Skillbox. А материал — под катом.

Python, я выбираю тебя! Почему?

У языка есть сразу несколько преимуществ, которые делают его подходящим для разработки микросервисов:

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

Богатая экосистема. У языка просто огромная экосистема библиотек и фреймворков, которые могут помочь в разработке микросервисов. Например, фреймворки вроде Flask и FastAPI позволяют быстро и эффективно создавать веб-сервисы, а библиотеки вроде Celery помогают в обработке асинхронных задач.

Поддержка асинхронного программирования. Python поддерживает асинхронное программирование с помощью модулей asyncio и aiohttp. Это позволяет эффективно обрабатывать большое количество параллельных запросов, что является общей задачей для микросервисов.

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

Конечно, можно выбрать и другой язык. Например, могу порекомендовать Golang. Его достоинства — производительность и встроенная поддержка конкурентности. Сам по себе выбор ЯП для микросервисов зависит от большого количества факторов. Требования к производительности, навыки команды разработчиков и специфика задачи — одни из наиболее критичных. 

А что такое событийно-ориентированные микросервисы? 

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

В событийно-ориентированной архитектуре микросервисы общаются друг с другом, отправляя и принимая события, а не через прямые запросы по API. Это может быть реализовано с помощью системы обмена сообщениями или брокера событий, такого как Kafka или RabbitMQ.

Отличие событийно-ориентированных микросервисов от других подходов к микросервисам включает в себя:

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

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

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

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

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

При разработке таких микросервисов разработчику нужно уделить особое внимание нескольким аспектам: 

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

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

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

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

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

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

Избегаем ошибок в разработке

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

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

Вдобавок к этому события могут быть еще слишком сложными. Допускать подобное тоже нельзя, я рекомендую простые и информативные события. Они должны содержать лишь ту информацию, которая нужна для обработки события. Если же оно становится слишком сложным, это может затруднить обработку, увеличив вероятность ошибок.

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

Какие знания и опыт требуются для разработки микросервисов 

Здесь знанием одного языка программирования не обойтись. Нужны и другие скиллы:

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

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

• Работа с API. Здесь все логично, поскольку микросервисы взаимодействуют друг с другом посредством API. Соответственно, разработчику нужно знать принципы проектирования RESTful API и/или GraphQL, gRPC/RPC, а также HTTP и WebSocket.

• Хорошее знание выбранного для работы над микросервисами языка программирования. Если брать Python, то это включает в себя знание основных конструкций языка, стандартных библиотек и популярных фреймворков, таких как Flask, FastAPI, Django и т. д.

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

И это еще не все: для развертывания микросервисов и управления ими понадобятся хотя бы базовые знания и опыт в DevOps и контейнеризации. Важным является знание таких технологий, как Docker и Kubernetes, а также принципов CI/CD.

Ну и последнее — это безопасность, ведь разработчик должен знать и понимать безопасности веб-приложений, включая защиту от основных видов атак, таких как SQL-инъекции, XSS и CSRF.

Все это означает, что разработка микросервисов — задача для middle- и senior-разработчиков. А начинающие разработчики могут подключаться к выполнению конкретных задач в рамках существующего микросервиса.