Привет, Хабр! Представляю вашему вниманию перевод статьи "Pattern: Saga" автора Chris Richardson.

Ситуация

Есть приложение, к которому применялся паттерн Database per Service. Теперь у каждого сервиса приложения есть своя собственная база данных. Некоторые бизнес транзакции охватывают сразу несколько сервисов, так что нужен механизм, обеспечивающий согласованность данных между этими сервисами.

Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.

Проблема

Как обеспечить согласованность данных между сервисами?

Решение

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

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

Обновившись до Spring Boot 3.3.0 (конкретно до Hibernate 6.5), мы столкнулись со 100% загрузкой процессора на БД из-за небольшого изменения в SQL коде, сгенерированного Hibernate после преобразования JPQL в SQL.

С 90% вероятностью многие из вас видели десятки, сотни и тысячи вакансий, где в требованиях был указан именно Fluent английский. Но в голове у вас идея, что нужен именно C1.

Почему так?

Есть старое и отличное исследование про внимательность, которое показывает, что мы видим то, что хотим видеть и на чём мы сфокусированы. Сейчас часто используется термин «информационный пузырь».

До 2020 года не только лишь все компании практиковали удаленный опыт работы. Таких агентств было с десяток на рынке. Но ковид многое изменил – сначала всех перевели на удаленку, как того требовала безопасность, а после как-то привыкли. Ну удобно, правда же? Не надо ехать на работу и с нее, можно подольше поспать, а в обеденный перерыв позаниматься своими делами. Или не только в обеденный? 🙂

Сегодня расскажу почему работать в офисе круче, чем только удаленно.

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

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

Но что если вы не хотите оставлять свой номер на сайте, который просто открыли? Поговорим на примере одного из таких сервисов - dmp.one. Важно: автор рекомендует открывать этот адрес во вкладке инкогнито с включённым uBlock Origin с кастомными правилами (о них ниже), иначе есть риск попадания вашего телефона в базу.

Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?

Это продолжение цикла статей про Celery. Первая часть тут.
Сегодня мы более глубоко разберем работу с Celery. Узнаем как работает Celery Beat внутри, научимся настраивать и создавать периодические задачи. И конечно же коснемся практических вопросов.

Роль Celery Beat проста: это планировщик и он запускает задачи с установленными интервалами. Эти задачи затем выполняются доступными рабочими узлами.
Для начала нам нужно разобраться с основными компонентами и названиями, которые будут использоваться в дальнейшем.

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

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

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

Мы начнём с азбучной реализации, а потом будем постепенно её оптимизировать и рассматривать, как это отразится на производительности.

От читателя поста ожидается, что он на базовом уровне понимает Rust, обычные структуры данных, а также концептуально представляет, как выделяется память (в стеке и куче).

Дополнение (14.05.2024): Я учёл поступившую обратную связь и подчеркнул, какие идеи объективно плохи, прояснил некоторые отступления и удалил идею о imbl.

Чтобы было проще прослеживать этапы реализации и исследовать код, отсылаю вас к репозиторию, сопровождающему этот пост.

Привет, Хабр! Представляю вам вторую часть из серии статей, посвященных оптимизации развертывания Kafka кластера (ссылка на первую часть). Это перевод руководства от Confluent. Сегодняшняя статья посвящена тому, как уменьшить задержку и повысить надежность и доступность. Заключительная третья часть будет посвящена мониторингу и бенчмаркингу.

Снова в колонке книга экстраординарного автора и физика. Мы уже писали о нём в другой статье на Хабре, поэтому рекомендуем ознакомиться и с нашим материалом, и с другим его произведением жизненной юмористической литературы. Книга «Вы, наверное, шутите, мистер Фейнман?» первее сегодняшней по хронологии и полнее по биографическому смыслу, хотя как автобиография не задумывалась.

Мы намерены перечитать все книги Ричарда, храни его небеса, Филлипса Фейнмана, и надеемся, что вы тоже откроете мир его мыслей вместе с нами. Если, конечно, ещё ничего не читали из трудов этого выдающегося ученого до этого момента.

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

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

Связка MetalLB, Longhorn и Kubespray позволяет обойтись меньшим количеством виртуалок и построить закрытую, высокоэффективную систему, способную удовлетворить специфические потребности вашего бизнеса.

Привет, Хабр!

Задумывались ли вы когда-нибудь, что вашему коду стоило бы пройти сеанс психотерапии? В C++ это возможно благодаря такой замечательной штуке, как рефлексия. Она позволяет вашему коду буквально видить в зеркале себя и понимать свои ошибки и достоинства.

Итак, рефлексия — это процесс, при котором программа может инспектировать и изменять структуру и поведение во время выполнения.

Рефлексия в C++ бывает двух основных типов: компиляционная и рефлексия времени выполнения. Оба типа имеют свои особенности и применяются в различных сценариях.

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

Я Иван Протченко, инженер из команды Cloud.ru, и сегодня я расскажу, как немного нестандартное использование Foreman помогло нам оптимизировать процесс установки и настройки операционных систем на серверное оборудование в облачной инфраструктуре. Даже отсыплю немного кода для тех, кто тоже хочет накатить ось на сотню-другую серверов и не сойти с ума. Очень пригодится всем, кто имеет дело с территориально распределенной инфраструктурой или масштабируется за счет аренды bare metal серверов.

Привет, Хабр! Меня зовут Александр Митин, я работаю в Т1 на проектах одного крупного банка. Занимаюсь развитием продкутовых сервисов компании (проект по обслуживанию и проведению ЧДП/ПДП клиентов). Опыт разработки 13 лет, последние 5 лет — в финтехе.

Сегодня микросервисная архитектура используется во многих проектах. Зачастую в таких системах применяют журналирование, авторизацию и прочие служебные сервисы, общие для всех приложений. А при разработке возникает огромное желание не дублировать одну и ту же логику, а вынести её в отдельную библиотеку, тем самым переиспользовав код. Что мы имеем в итоге? В лучшем случае одну библиотеку «common», которая разрастается до огромных размеров и становится ядром распределённого монолита. В дальнейшем новые версии этой библиотеки теряют обратную совместимость, а каждое её обновление в проектах сильно осложняет поддержку. Более того, становится невозможным разобраться, где и какие классы используются, что делает архитектуру хрупкой и уязвимой.

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

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

Почему так сложно понять asyncio?

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

Но будь я автором самого толстого в мире учебника по python, я бы рассказывал читателям про асинхронное программирование уже с первых страниц. Вот только написали "Hello, world!" и тут же приступили к созданию "Hello, asynchronous world!". А уже потом циклы, условия и все такое.

Привет, Хабр! Хочу поделиться самодельной питонской библиотекой, существенно упрощающей взаимодествие с базами данных.

«Написать свой собственный ORM» – неплохая задачка для тех, кто решил поглубже изучить некоторые языковые особенности Питона, но в данном случае задача была другая – написать не ORM, а не-ORM. Механизм, упорядочивающий и облегчающий доступ к базам данных, но который сам по себе ни в коей мере не является ORM-ом.

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

Это не самая большая моя статья (так я думал, начиная ее), над которой я работал, пожалуй, дольше и больше, чем над другими. Но это точно первая моя статья, в которой автоматы и ВКПа не будут главной темой. Тема потоков для меня достаточно необычна, т.к. я совсем не фанат многопоточного программирования. Но,  тем не менее, занимаясь параллельным программированием, время от времени возвращаюсь к теме многопоточности. И вот, чтобы добыть какие-то аргументы для критики и одновременно попробовать найти практическое применение потокам, я решил в этот очередной раз более плотно заняться потоками. А что из этого получилось,  читайте далее.

GraphQL — невероятная технология, привлёкшая много внимания с тех пор, когда я начал в 2018 году использовать её в продакшене. Вам не придётся долго листать мой блог, чтобы увидеть, как я раньше продвигал её. После создания множества React SPA поверх путаницы нетипизированных JSON REST API технология GraphQL показалась мне глотком свежего воздуха. Я искренне поддерживал хайп вокруг GraphQL.

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

В статье для примеров я буду использовать код на Ruby с превосходной библиотекой graphql-ruby, но я уверен, что многие из перечисленных проблем не зависят от выбора языка/библиотеки GraphQL.

Если вы знаете более качественные решения или способы, напишите мне комментарий.