Python

Как мы кодили no code - рецепты сервисов со свежим Редисом.

Опыт разработки продукта с масштабируемой архитектурой на примере Платформы ботов общения с клиентами с no-code конструктором сценариев и средой их исполнения.

Задача, вставшая перед командой - полный рефакторинг имеющихся сервисов ботов. Причины - настройки были доступны только разработчикам, и потребовалось повышение масштабируемости. Фактически требовалось в короткие сроки разработать масштабируемую no-code платформу с визуальным конструктором сценариев, работающую с голосовыми и текстовыми ботами различных бизнес-заказчиков одновременно, к тому же поддерживающую большой спектр внешних интеграций.

Краткий рассказ о получившейся Платформе - иллюстрация с точки зрения UX.

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

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

В том числе обосновывается выбор различных способов коммуникации между сервисами, от классики REST до асинхронной коммуникации без API через общее хранилище, а так же применение элементов паттернов API Gateway, canary deployment и других.

В результате последовательных шагов получится архитектурная схема с адаптерами внешних сервисов, Event driven воркерами, in-memory хранилищем состояний и Event sourcing сохранением результатов для мониторинга и аналитики. Небольшое количество примеров на Python, но сам рассказ от языков и фреймворков не зависит.

Цель доклада: показать применение алгоритмов и технологий Python для автоматизации проектирования линейных протяжённых объектов.

#### **1. Введение**

- О себе.

- Краткий обзор задач, которые решает программный комплекс «Горизонт».

- Python vs C++?

#### **2. Решение задачи распознавания данных геодезической съёмки**

- Парсинг DWG и DXF-файлов.

- Семантическая сегментация данных:

- Распознавание условных обозначений и объектов инфраструктуры.

- Применение алгоритмов компьютерного зрения на Python.

- Алгоритмы сопоставления:

- Задача о назначениях для сопоставления объектов и технической информации.

- Использование R-деревьев для быстрого поиска ближайших геометрических объектов.

- Методы пространственной интерполяции для высотных отметок.

#### **3. Построение графа для проектирования**

- Использование Python для работы с графами:

- Библиотеки: NetworkX, SciPy и другие для оптимизации маршрутов.

- Применение OpenCV для анализа изображений и карт.

#### **4. Поиск оптимального маршрута**

- Модификация классических алгоритмов поиска путей:

- Постобработка маршрутов:

- Исправление дефектов из-за недостаточной точности исходных данных.

- Удаление избыточных точек и оптимизация поворотов.

- Использование эволюционных алгоритмов.

Выбор Python-фреймворка — непростая задача. FastAPI и Django по звёздочкам в гитхабе затмевают внимание Python-разработчиков. Но всегда ли это правильный выбор? А что ещё есть в прострах opensource? Что на самом деле скрывается за популярностью web фреймворков? И что скрывают за собой сами фреймворки?

В своём докладе я честно и без прикрас расскажу о плюсах и минусах монолитной и микросервисной архитектуры, поделюсь личным опытом и покажу, почему иногда популярные решения не оправдывают ожиданий в реальной Python-разработке. Вас ждёт подробный сравнительный бенчмарк таких популярных Python-фреймворков как FastAPI, LiteStar, Django, BlackSheep и новичков, о которых мало кто слышал. Мы вместе увидим, кто лидирует в гонке за скоростью, удобством и производительностью, а кто остаётся позади.

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

Также мы рассмотрим крутые и удобные возможности популярных Python-фреймворков, разберём практические примеры кода и обсудим тренды будущего развития Python-экосистемы в контексте микросервисов, монолитов и фреймворков. Я расскажу о том, куда движется Python-разработка и какие инструменты стоит использовать уже сегодня, чтобы оставаться на шаг впереди.

Довольно часто backend-разработчикам приходится проектировать микросервисную архитектуру. Тут много непонятного: непонятно, где проходит грань между «как организовать файлы» и «как сервис А и Б взаимодействуют друг с другом»; не ясно, какие паттерны стоит использовать, а какие нет; неизвестно, кто источник основных знаний по проектированию; не ясно, какие протоколы стоит брать и какие есть с ними сложности; не всегда ясно, как проектировать микросервисы.

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

Наш корпоративный чат-бот построен на микросервисной архитектуре и активно взаимодействует с клиентами через чат. В ходе разработки мы столкнулись с нетривиальной задачей: нам нужно было не только получать входящие сообщения, отправляя их в MQ (RabbitMQ) для обработки DS-ядром, но и правильно маршрутизировать ответы обратно в нужный процесс.

Ключевая сложность — долгоживущий процесс внутри микросервиса, который собирает сообщения в обоих направлениях:

— От клиента — для корректной обработки фраз, составленных из нескольких сообщений («привет», «как», «дела»).

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

В условиях распределенной системы на Kubernetes процессы могут находиться на разных серверах (нодах), что делает задачу обратной маршрутизации особенно сложной. Как доставить ответ в тот же процесс, который отправил запрос, если сервисы динамически масштабируются и мигрируют между узлами?

Ранее наши коллеги рассказывали, как маршрутизация устроена в чат-системах (https://speakerdeck.com/xfenix/dvustoronnii-websocket-routingh). В этом докладе мы поделимся нашим опытом:

— Как мы решали проблему обратного роутинга в микросервисной среде.

— Как эволюционировали наши архитектурные решения и какие ошибки мы допустили.

— Какие существуют методы решения проблемы обратной маршрутизации (название придумали сами, так как тема ранее не была освещена).

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