Серия «Итоги недели в мире бэкенда, обзоры новых сервисов»

Сбой Stack Overflow

В 2016 году Stack Overflow испытал 34-минутный перебой в работе. Причиной стало регулярное выражение, используемое для обработки пользовательского ввода:

^[\s\u200c]+|[\s\u200c]+$

Это выражение должно было находить пробелы в начале и конце строки. Проблема возникла, когда какой-то пользователь запостил комментарий, содержащий около 20 000 последовательных пробелов. Механизм обработки регулярных выражений начал проверять каждый пробел. Когда после 20 000-го пробела встретился другой символ, движок начал откатываться назад, пытаясь найти соответствие, начиная со второго пробела, третьего и так далее.

Это привело к катастрофическому возврату (catastrophic backtracking) – ошибке, которая возникает, когда движок регулярных выражений тратит чрезмерное количество времени на попытки найти соответствие шаблону, перебирая различные комбинации. Количество проверок начало лавинообразно увеличиваться и быстро достигло 199 990 000 – это вызвало значительную задержку и в итоге сбой системы.

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

Сбой Cloudflare

2 июля 2019 года произошел крупный сбой в работе платформы Cloudflare. Один из инженеров написал регулярное выражение, которое привело к действительно катастрофическому возврату – вызвало экстремальную перегрузку всей инфраструктуры. Использование процессоров выросло до 100%, а большинство сайтов, подключенных к Cloudflare, замедлились до крайности или вовсе оказались недоступными.

Коварная регулярка выглядела так:

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

Самую большую опасность в этом выражении представляет

.*(?:.*=.*)

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

Глобальный сбой Windows/CrowdStrike

19 июля 2024 года произошел самый массовый сбой в истории – из строя вышли около 8,5 млн Windows-компьютеров с ПО CrowdStrike. Причиной сбоя стало несоответствие между ожидаемым количеством входных параметров (21) и фактическим количеством параметров (20), которые были переданы в интерпретатор контента (этот компонент отвечает за обработку содержимого с использованием регулярных выражений). Когда система получила ввод с 21 параметром, интерпретатор контента попытался считать данные за пределами выделенной памяти, что и привело к сбою системы.

Привет!

Мы запустили еженедельную email-рассылку, посвященную последним новостям и тенденциям в мире бэкенда. В еженедельных письмах ты найдешь:

• Языки программирования и фреймворки для бэкенда

• Архитектура и проектирование серверных приложений

• Базы данных и управление данными

• Безопасность и защита данных

• Облачные технологии и DevOps

• API и интеграции

• Тестирование и отладка

• Инструменты и утилиты для бэкенд-разработчиков

• Лучшие практики и паттерны проектирования

🤵 Как не завалить собеседование в крупной ИТ-компании

Разработчик с 10-летним коммерческим опытом поделился провальным опытом прохождения технического собеседования в одной из лидирующих компаний. Из этого провала он извлек три основных урока:

• Перед собеседованием нужно освежить знания о структурах данных – и не только о списках, массивах и словарях. Не стоит игнорировать и те структуры, с которыми вы в последний раз сталкивались в университете и никогда не используете на практике – очереди, кучи и деревья. Автору попался как раз вопрос о деревьях, с которыми он с университетских времен не встречался и которые, скорее всего, на новой работе ему бы тоже не понадобились. Однако на собеседовании зачастую проверяются не только практические навыки, но и общая ИТ-эрудиция.

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

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

🛠️ Инструменты

BullMQ – библиотека для Node.js, которая реализует быструю и надежную систему очередей, основанную на Redis и предназначенную для решения всех основных задач в современных микросервисных архитектурах (сглаживание пиков нагрузки, создание надежных каналов связи между сервисами, распределение ресурсоемких задач между несколькими обработчиками и тому подобное).

Основные возможности и преимущества BullMQ:

• Точная обработка сообщений – библиотека гарантирует доставку как минимум один раз.

• Горизонтальное масштабирование – можно добавить сколько угодно обработчиков для параллельной обработки заданий.

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

• Минимальное использование CPU.

• Распределенное выполнение заданий на основе Redis.

• Поддержка очередей LIFO и FIFO.

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

• Запланированные и повторяющиеся задачи по расписанию.

• Настройка параллельности для каждого обработчика.

• Многопоточные (изолированные) функции обработки.

• Автоматическое восстановление после сбоев процесса.

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

SigNoz – опенсорсный инструмент для мониторинга и устранения неполадок в развернутых приложениях. Это отличная бесплатная альтернатива коммерческим решениям – DataDog и New Relic.

Основная функциональность:

• Единый интерфейс для метрик, трассировок и логов.

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

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

• Управление логами с продвинутым построителем запросов.

• Мониторинг инфраструктуры.

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

• Настраиваемые оповещения.

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

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

Infisical – опенсорсная платформа для удобного и безопасного управления секретами и конфигурационными данными. Основные возможности:

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

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

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

• Управление конфигурациями – позволяет управлять общими настройками приложений для разных сред (разработка, тестирование, продакшн).

• Безопасный доступ – предоставляет инструменты (SDK, CLI, API) для безопасного получения секретов в приложениях и инфраструктуре.

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

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

• Интеграция с инфраструктурой – легко интегрируется с популярными платформами и инструментами (GitHub, AWS, Kubernetes и т. п.).

• Управление внутренней PKI – позволяет создавать и управлять собственной инфраструктурой открытых ключей для выпуска цифровых сертификатов.

KubeAI – инструмент для развертывания и управления опенсорсными LLM-моделями в среде Kubernetes. Среди основных функций и особенностей:

• Совместимость с OpenAI. Предоставляет API, совместимый с OpenAI, что позволяет легко заменить сервисы OpenAI в любых ИИ-приложениях на локальные.

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

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

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

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

• Встроенный пользовательский интерфейс. Предоставляет чат-интерфейс OpenWebUI для взаимодействия с моделями.

• Управление серверами vLLM, Ollama и FasterWhisper.

• Интеграция с системами обмена сообщениями. Поддерживает потоковую передачу и пакетную обработку через интеграции с Kafka и другими PubSub-системами обмена сообщениями.

Zed – опенсорсный многопользовательский редактор кода, предназначенный для совместной работы над проектом в реальном времени. Основные особенности и возможности:

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

• Предусматривает интеграцию с LLM для генерации, анализа и рефакторинга кода.

• Имеет встроенный терминал.

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

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

Warp – современный высокопроизводительный терминал с ИИ-функциональностью. Основные особенности и возможности:

• Производительность. Написан полностью на Rust и использует рендеринг на GPU через Metal API, что обеспечивает высокую скорость работы (60+ FPS даже на 4K- и 8K-мониторах).

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

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

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

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

• Совместимость с популярными оболочками. Работает с Bash, ZSH и Fish, сохраняя существующие привязки клавиш.

• Кроссплатформенность. Работает на macOS и Linux, вскоре будет поддерживать Windows и WASM.

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

Автор рассылки: Наталья Кайда

• Описание конечных точек (эндпойнтов).

• Форматы запросов и ответов.

• Методы аутентификации.

• Обработку ошибок.

• Примеры использования.

Представляем подборку лучших инструментов для создания API-документации.

Swagger

Swagger – один из самых популярных инструментов: он поддерживает много языков программирования и предоставляет удобный интерфейс для проектирования и документирования API. Swagger позволяет определять конечные точки, форматы запросов и ответов, а также методы аутентификации. Кроме того, он предоставляет интерактивные инструменты для исследования и тестирования API.

Apidog

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

ReDoc

ReDoc – опенсорсный инструмент, поддерживающий спецификации OpenAPI 2.0 и 3.0. Он отлично подходит для публикации интерактивной API-документации и предлагает удобную навигацию с настраиваемым поиском, а также стильный, адаптивный дизайн с возможностью настройки тем.

DapperDox

DapperDox – опенсорсный OpenAPI-рендерер, совместимый с OAS 2.0 и 3.0. Он позволяет использовать контент в формате Markdown для создания диаграмм и предоставляет модуль исследования структуры API для практических экспериментов.

Theneo

Theneo – генератор документации, использующий ИИ для автоматического описания API. У него простой интерфейс, напоминающий Notion, и он поддерживает интеграции с Swagger, Postman и GitHub.

Sphinx

Sphinx – мощный генератор документации, широко используемый в Python-сообществе. Он поддерживает много языков и предлагает широкие возможности для настройки. Sphinx может генерировать документацию в разных форматах, включая HTML, PDF и ePub.

Javadoc

Javadoc специально разработан для документирования Java-кода. Он извлекает комментарии и аннотации из исходного кода для создания HTML-документации с подробным описанием классов, методов и полей.

DocFX

DocFX – генератор статических сайтов, разработанный Microsoft и с ноября 2022 года поддерживаемый сообществом .NET Foundation. Предлагает настраиваемые шаблоны для создания документации и лендингов.

Doxygen

Doxygen поддерживает C++, С, Objective-C, Python, Java, IDL, PHP, C# и Fortran, может генерировать документацию в разных форматах, включая HTML, PDF и LaTeX.

Slate

Slate фокусируется на простоте и удобстве использования, предоставляя удобный, современный, адаптивный интерфейс для API-документации. Он поддерживает Markdown, подсвечивает синтаксис больше 100 языков и предлагает интерактивную консоль для тестирования API-эндпойнтов.

Docusaurus

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

Приглашаем вас на вебинар «Как меняется математика в разных индустриях: от мобильных игр к фондовым рынкам», который состоится 22 августа в 20:00 по МСК. Там вы сможете:

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

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

• Изучить реальные кейсы применения математики в GameDev и финансах.

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

Стать участником вебинара

😎 Автоматизация слепых SQL-инъекций на основе логических значений

Слепая SQL-инъекция на основе логического значения (Boolean-Based Blind SQL Injection) – тип SQL-инъекции, где атакующий не видит прямого вывода SQL-запроса, но может делать выводы на основе логических (истина/ложь) ответов от приложения (эти ответы могут проявляться в виде разных кодов состояния HTTP, разного содержимого ответа или реже разных заголовков).

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

• Простейший метод – извлекать данные по одному символу, используя функции SUBSTRING() и ASCII() в MySQL. Это позволяет узнавать значение каждого символа в строке путем сравнения с ASCII-кодами.

• Оптимизированный подход – использовать алгоритм бинарного поиска. Это сокращает количество запросов для определения одного символа с 96 до 7, что значительно ускоряет процесс и делает атаку менее заметной.

• Дополнительные приемы для извлечения разных типов данных включают использование подзапросов для выбора данных из произвольных таблиц, объединение значений из нескольких строк в одну строку с помощью GROUP_CONCAT и преобразование разных типов данных (числа, даты и т. д.) в строки, которые легче извлечь.

Для дальнейшего ускорения процесса можно использовать многопоточность с помощью ThreadPoolExecutor из библиотеки concurrent.futures.

📶 Паттерны коммуникации в распределенных системах

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

Запрос-ответ с HTTP

Этот синхронный паттерн коммуникации предполагает, что один сервис отправляет запрос другому сервису и ожидает ответа или ошибки, блокируя свою работу до получения результата. REST, наиболее популярный архитектурный стиль для этой модели коммуникации, использует методы протокола HTTP – GET, POST, PUT и DELETE.

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

Общие данные

Этот паттерн часто остается незамеченным, поскольку разработчики не всегда воспринимают его как модель коммуникации. В рамках этого подхода один компонент записывает данные в определенное место, а другой компонент считывает и обрабатывает эти данные. Например, один сервис может загрузить файл в облачное объектное хранилище (например, в корзину Amazon S3), а другой сервис затем извлекает этот файл для дальнейших действий.

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

Асинхронный запрос-ответ

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

Основная сложность здесь — корреляция между запросом и ответом: экземпляр сервиса, отправивший запрос, может отличаться от экземпляра, получающего ответ, поэтому требуется способ отслеживания запросов.

Коммуникация на основе событий

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

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

🛠️ Инструменты

Postgres Sandbox – ИИ-песочница для работы с PostgreSQL в браузере. Проект реализован на PGlite – легковесной версии PostgreSQL, скомпилированной в WebAssembly и упакованной в клиентскую библиотеку TypeScript. Это позволяет запускать базу данных PostgreSQL непосредственно в браузере, Node.js и Bun без необходимости устанавливать другие зависимости. Размер PGLite – всего 3 Мб после сжатия Gzip, при этом база поддерживает многие расширения PostgreSQL, включая pgvector.

textual-plotext – виджет-обертка библиотеки для построения графиков Plotext. Визуализирует данные из Python-скриптов прямо в терминале.

BunkerWeb – опенсорсный веб-фаервол (WAF), созданный на основе NGINX. Предназначен для защиты веб-сервисов – делает их безопасными по умолчанию. Легко интегрируется в существующие среды (Linux, Docker, Swarm, Kubernetes и т. д.), полностью адаптируется под ваши специфические требования. Предоставляет удобный веб-интерфейс и систему плагинов.

Kardinal – фреймворк для создания сверхлегких временных сред разработки внутри общего кластера Kubernetes. Позволяет быстро и эффективно создавать и удалять рабочие пространства для разработки, тестирования и демонстраций, минимизируя затраты ресурсов и стоимость эксплуатации.

Viking – инструмент для управления удаленными серверами (и группами серверов) через SSH.

Terminus – опенсорсная ОС на базе Kubernetes, которая позволяет создать домашнее облако на собственном сервере. Подходит для любых задач – локального хостинга LLM, хаба по управлению IoT-девайсами, персонального репозитория или рабочего пространства.

DeltaDB – легковесная, быстрая и масштабируемая база данных, созданная на основе polars и deltalake. Предназначена для разработчиков и организаций, которым нужно эффективное, простое и гибкое решение для обработки больших объемов данных с высокой скоростью и масштабируемостью.

emval – супербыстрый валидатор email-адресов для Python-приложений, написанный на Rust.

RustPython – интерпретатор Python, написанный на Rust.

Автор рассылки: Наталья Кайда

• API Gateway обычно предоставляет единую точку входа для всех клиентов, а BFF создает отдельные шлюзы для каждого типа клиента (веб, мобильный и т. д.).

• BFF более специализирован и ориентирован на конкретные нужды разных типов фронтендов, а API Gateway более универсален и может обслуживать разные клиенты без специфической оптимизации.

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

Как работает BFF:

• API Gateway перенаправляет запросы на соответствующий BFF.

• BFF взаимодействует с нужными микросервисами (например, Products, Orders, Cart).

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

Паттерн появился в 2015 году, приобрел широкую известность к 2021-му и с тех пор остается одним из самых популярных подходов в разработке микросервисов. На это есть веские причины:

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

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

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

• Упрощение фронтенд-разработки – BFF предоставляет именно те данные, которые нужны конкретному интерфейсу, избавляя от лишней обработки на клиенте.

• Упрощение поддержки и модификации API для каждого отдельного фронтенда.

Когда стоит использовать BFF:

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

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

Например, BFF будет оптимальным выбором для:

• E-commerce платформ – отдельные BFF для веб-сайта, мобильных приложений и умных устройств будут обрабатывать специфические потоки данных и действия пользователей.

• Финансовых сервисов – специализированные BFF для веб- и мобильного банкинга обеспечат более удобное и безопасное использование сервиса.

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

✍️ Как написать HTTP-сервер на Go

Платформа CodeCrafters предлагает практичный подход к обучению – разработчики там учатся и совершенствуют навыки в процессе создания реальных, готовых к использованию приложений. Например, одно из заданий – разработка HTTP-сервера. Студент успешно выполнил задание на Go без использования сторонних библиотек и рассказал о процессе работы в этом пошаговом туториале.

Основные характеристики и функциональность сервера:

• Базовый TCP-сервер, слушающий порт 4221.

• Обрабатывает HTTP-запросы и отправляет соответствующие ответы.

• Поддерживает разные маршруты и HTTP-методы.

• Обрабатывает параметры URL и заголовки запросов.

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

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

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

☢️ Почему не стоит использовать as в Rust

Оператор as используется для приведения типов: позволяет преобразовывать значения одного типа в другой. Но, как пишет опытный Rust-разработчик, использование as может привести к неожиданному поведению при преобразовании в меньший тип данных: если значение не помещается в целевой тип, происходит усечение без предупреждения – это приводит к появлению трудноотслеживаемых ошибок в больших проектах. Например, у нас есть число 288, которое мы хотим преобразовать в тип u8 (8-битное беззнаковое целое число). Тип u8 может хранить значения от 0 до 255. Очевидно, 288 не помещается в этот диапазон. При использовании as для преобразования вместо ожидаемой ошибки или предупреждения Rust выполняет усечение значения. В этом случае результат будет равен 32:

• 288 в двоичном виде: 100100000.

• При преобразовании в u8 Rust берет только 8 младших битов (справа налево): 00100000.

• 00100000 в десятичной системе равно 32.

Это поведение станет полной неожиданностью для программистов, переключившихся на Rust с языков высокого уровня, где подобные преобразования всегда вызывают ошибки или предупреждения. Лучшее решение этой проблемы – использовать трейт TryFrom вместо as. Этот подход требует чуть больше кода, но это один из тех немногих случаев, когда отказ от стандартного приема действительно оправдан:

🐍 Как создать инвертированный индекс на Python

Инвертированный индекс – это структура данных, которая позволяет быстро находить документы, содержащие определенное слово или фразу. Главные преимущества инвертированного индекса:

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

• Эффективность для больших объемов данных – индекс позволяет эффективно обрабатывать большие коллекции документов.

Вместо того, чтобы просматривать каждый документ целиком, индекс хранит информацию о том, в каких документах встречается каждое слово. Для этого он использует хэш-таблицу (словарь в случае Python), где ключами являются слова, а значениями – списки идентификаторов документов, содержащих эти слова. Общий принцип построения индекса выглядит так:

Подготовка данных

• Определяется структура документов (например, название и текст статьи).

• Создается список документов.

Для каждого документа:

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

• Обработанный текст разбивается на слова.

Для каждого слова:

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

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

Алгоритм поиска по индексу включает в себя:

Преобразование запроса

• Запрос приводится к нижнему регистру и очищается от знаков препинания.

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

Поиск по индексу

Для каждого слова в запросе:

• Находится список документов для этого слова в индексе.

• Объединяются списки документов для всех слов запроса.

Получение результатов

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

Пример реализации простейшего инвертированного индекса на Python подробно описан здесь.

🛠️ 18 основных паттернов микросервисной архитектуры

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

1. Service Registry (Реестр сервисов)

Этот паттерн решает проблему обнаружения сервисов в распределенной системе. Каждый микросервис регистрирует себя в центральном реестре (например, Netflix Eureka или Consul). Когда одному сервису нужно взаимодействовать с другим, он обращается к реестру, чтобы узнать текущий адрес нужного сервиса. Это позволяет сервисам динамически обнаруживать друг друга без жесткой привязки к конкретным адресам.

2. API Gateway (API-шлюз)

API Gateway действует как единая точка входа для всех клиентских запросов. Он принимает запросы от клиентов и перенаправляет их соответствующим микросервисам. API Gateway может также выполнять такие задачи, как аутентификация, авторизация и балансировка нагрузки. Это упрощает взаимодействие клиентов с системой, скрывая сложность внутренней архитектуры.

3. Circuit Breaker (Предохранитель)

Этот паттерн предотвращает каскадные сбои в системе. Когда один сервис начинает давать сбои, Circuit Breaker временно блокирует запросы к этому сервису, предотвращая перегрузку и позволяя системе восстановиться. Это повышает устойчивость системы и помогает избежать полного отказа всей системы из-за проблем с одним сервисом.

4. Bulkhead (Отсек)

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

5. Saga Pattern (Сага)

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

6. Event Sourcing (Источник событий)

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

7. Command Query Responsibility Segregation (CQRS, Разделение команд и запросов)

CQRS разделяет операции чтения и записи в приложении. Используются разные модели для обновления информации (команды) и чтения информации (запросы). Это позволяет оптимизировать каждую сторону независимо, что может значительно улучшить производительность и масштабируемость.

8. Data Sharding (Шардинг данных)

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

9. Polyglot Persistence (Многовариантное хранение)

Этот подход позволяет использовать разные технологии баз данных для разных микросервисов, исходя из их конкретных потребностей. Например, один сервис может использовать реляционную БД, другой – NoSQL, третий – графовую БД. Это оптимизирует хранение, извлечение и обработку данных для каждого сервиса.

10. Retry (Повторная попытка)

Обеспечивает повторение операции при возникновении временного сбоя – вместо немедленного отказа. Может применяться на разных уровнях: от взаимодействия между сервисами до работы с базой данных. Помогает справиться с кратковременными проблемами в сети или сервисах.

11. Sidecar (Вспомогательный сервис)

Этот паттерн предполагает присоединение вспомогательного сервиса (sidecar) к основному микросервису для обеспечения дополнительной функциональности, такой как логирование, безопасность или коммуникация с внешними сервисами. Позволяет основному сервису сосредоточиться на своей основной функции.

12. Backends for Frontends (BFF, Бэкенды для фронтендов)

BFF предполагает создание отдельных бэкенд-сервисов для каждого типа клиента (веб, мобильный и т. д.). Это позволяет оптимизировать API под конкретные нужды каждого клиента, улучшая производительность и упрощая разработку клиентской части.

13. Shadow Deployment (Теневое развертывание)

Этот паттерн предполагает отправку копии (тени) производственного трафика к новой версии микросервиса без влияния на реальный пользовательский опыт. Это позволяет проверить производительность и корректность новой версии в реальных условиях, не подвергая риску текущих пользователей.

14. Consumer-Driven Contracts (Контракты, определяемые потребителем)

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

15. Smart Endpoints, Dumb Pipes (Умные конечные точки, глупые каналы)

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

16. Database per Service (База данных для каждого сервиса)

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

17. Async Messaging (Асинхронный обмен сообщениями)

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

18. Stateless Services (Сервисы без состояния)

Проектирование микросервисов как stateless (без сохранения состояния) упрощает масштабирование и повышает устойчивость. Каждый сервис обрабатывает запрос независимо, не полагаясь на сохраненное состояние – это облегчает горизонтальное масштабирование.

Автор рассылки: Наталья Кайда