Распределённые системы *

Привет, Хабр! На связи Антон, руководитель Архитектурного комитета компании SimbirSoft. Вместе с моими коллегами в прошлой статье мы рассказали про особенности применения подхода Design API First. Сегодня покажем, как реализуется этот подход на практике на примере сервиса аутентификации пользователей.

Есть и продолжение, 3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.

Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)

Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).

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

Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему  проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.

2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации

3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

В этой статье мы создадим простое приложений на основе MQTT с использованием брокера сообщений EMQX и настроим наблюдение через встроенные механизмы трассировки.

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

Данная задача в разных вариациях мне давалась на нескольких собеседованиях несколько лет назад. Хоть мой дизайн и проходил, мне стало интересно реализовать это в коде с нуля. Сыроватый и сильно урезанный по функционалу MVP готов, ссылка на github будет под катом. Пока что мной запланировано 3 статьи - эта, по бэкенду и по фронту. Будет много кода на scala, много котов (cats effect), стримов (fs2), пара lock-free техник, scala js, и постараюсь сделать так, чтобы мозг от всего этого не взорвался.

Все, кому интересно - добро пожаловать под кат.

Привет, Хабр! Меня зовут Игорь Агиевич, я специалист по безопасности распределенных реестров в компании Positive Technologies. C 2021 года занимаюсь безопасностью в области блокчейн-технологий, в сфере ИТ работаю в общей сложности 17 лет.

В статье поговорим о проблемах безопасности блокчейн-проектов, пришедших из мира Web 2.0. В этой области отсутствует сложившаяся практика, поэтому в публичной плоскости крайне мало сведений о механизмах защиты, используемых этими проектами. Статья является более подробным вариантом доклада с прошедшего киберфестиваля Positive Hack Days 12 на эту же тему.

Опыт, накопленный при проведении пентестов, и понимание сетевых технологий помогли мне провести исследование атак на блокчейн-проекты, проведенных с использованием техник DNS hijacking и BGP hijacking.

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

? разберем, как злоумышленники проводили атаки на сетевом уровне (благодаря открытым данным восстановим многие шаги атак буквально по минутам);

? декомпилируем смарт-контракты (далее — контракты) атакующих;

? выясним, какие публичные механизмы защиты внедрили пострадавшие проекты и что с ними не так;

? попробуем улучшить механизмы обнаружения рассмотренных атак и защиты от них, а также рассмотрим обозреватели блокчейнов (выясним, как найти в блокчейне контракты злоумышленника, зная только один из них);

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

Apache Kafka нередко используется как инструмент накопления истории событий или посредник для взаимодействия микросервисов, работающих с разной скоростью или ожидающих доступа к историческим данным для анализа трендов исторических данных (и в этом случае может использоваться как альтернативное решение для Time Series Database). В большинстве случаев в роли producer и consumer выступают сетевые приложения, которые взаимодействуют через драйвер с поддержкой протокола Kafka, но иногда требуется настроить интеграцию с унаследованными системами или готовыми решениями и для этого может использоваться вспомогательный инструмент Kafka Connect, представляющий большое количество готовых коннекторов. В первой части статьи мы рассмотрели способ создания коннектора для опроса REST API и анализа данных с использованием Hazelcast. В этой статье мы последовательно разберемся с созданием коннекторов для пересылки сообщений из топика во внешнюю систему (Sink Connector) для отправки данных из Kafka в TSDB базу данных TDEngine, а также обсудим, как можно выполнить нагрузочное тестирование всего стека с использованием xk6-kafka.

Поговорим сегодня про выбор, перед которым встают разработчики всех распределённых систем: обеспечивать ли консистентность данных или доступность системы при различных внешних условиях —  поломках, плановых отключениях узлов, — а также во время штатной эксплуатации. Теория нам даёт простые, но не всегда применимые на практике ответы: можно выбрать либо консистентность, либо доступность (теорема CAP), а когда проблем с сетью нет — то либо консистентность, либо низкие задержки (PACELC). За скобками остаётся вопрос о том, как делать этот выбор. Система как будто всегда должна быть CP или AP, а что происходит, если вдруг работающая CP-система должна начать вести себя как AP, или, наоборот, перейти обратно из AP в CP?

Для надежной поточной обработки данных в реальном времени и принятия решений на основе анализа данных из внешнего источника нужно обеспечить организацию конвейера обработки и хранения данных, который может быть кластеризирован и распараллелен для достижения необходимой производительности и отказоустойчивости. Кроме того, нужно обеспечить механизм своевременной доставки обновленных данных (на основе периодического опроса или использования Web Sockets/SSE) в систему анализа, которая также должна иметь доступ к истории изменений (например, для анализа тренда или получения усредненных значений по временному окну). В этой статье мы поговорим про использование Apache Kafka совместно с Hazelcast для анализа данных в реальном времени, а также разработаем коннектор для Kafka Connect для извлечения данных из внешнего источника (на примере WeatherStack API)

Пользовательский опыт напрямую зависит от скорости выполнения запросов к данным. Мы привыкли, что SQL базы данных строят оптимальный план запроса за нас. В случае многих NoSQL баз данных, оптимизация запроса ложится на разработчика. Меня зовут Жора и вместе с @yngvar_antonsson мы провели много времени за аудитом запросов у наших заказчиков. Сегодня мы расскажем про перфоманс, оптимизации и про тяжелые запросы на примере Tarantool. Будет интересно всем, кто уже работает или только собирается работать с Tarantool, а также тем, кто строит кластерные системы поверх своих БД.

Привет! Меня зовут Евгений Иванов, я разработчик YDB. Мне очень нравится заниматься задачами, связанными с производительностью: бенчить, анализировать, оптимизировать. И в YDB мы придаем очень большое значения тому, чтобы быть эффективными. В этом посте я хочу представить Вашему вниманию перевод нашей свежей статьи "YCSB performance series: YDB, CockroachDB, and YugabyteDB".

Реализовать распределённую систему управления базами данных (СУБД), высокопроизводительную, масштабируемую и консистентную, — настоящий вызов. В YDB успешно с ним справились, и наши пользователи могут это подтвердить. Мы ещё не делились показателями нашей производительности на широкую аудиторию, но понимаем их значимость. Поэтому сегодня мы расскажем о результатах нашего исследования производительности.

YDB — это распределённая реляционная СУБД. Производительность распределённых транзакций в TPC-C и других сложных бенчмарках во многом зависит от реализации хранения данных по ключу. В этом посте посте мы сравним результаты тестов YCSB для YDB и двух других известных распределённых SQL-баз данных — CockroachDB и YugabyteDB. Спойлер: YDB превзойдёт конкурентов по многим нагрузкам YCSB.

Привет. Меня зовут Владимир Салыкин, я директор по продукту Tarantool. Мы выпустили Tarantool 2.11 LTS — стабильный релиз с долгим циклом поддержки. Работа над ним началась в мае 2022 года, и сейчас релиз включает в себя более тысячи коммитов от 42 авторов. Мы все много работали над решением основных проблем с обслуживанием и администрированием, с которыми ранее сталкивались наши пользователи. 

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

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

В материале я расскажу именно об Apache Cassandra: какие ошибки можно совершить при ее использовании, на что стоит обратить внимание и чем лучше не пренебрегать.

За последние несколько лет машинное обучение сильно изменилось. В обиход вошли так называемые Fundation model. Вы обучаете одну огромную общую модель, которая умеет делать почти всё одинаково. Это как вырастить огромное дерево. Однако для небольшой такой модели из 3 млрд параметров вам потребуется 400 GPU и обучение в течение 5 дней.  Поэтому необходимо переходить на Machine Learning-кластера.

Дальнейшее повествование пойдет от имени Дмитрия Монахова, он занимался разработкой ядра Linux в Яндексе. Мне посчастливилось стать участником революции в Machine Learning, которая произошла за последние несколько лет.  А именно модели выросли до такого размера, что они уже не влезают ни в один сервер, ни в несколько серверов, ни даже в одну стойку. Стали строить что-то огромное, но вдруг вспомнили, что был какой-то чудак, который имел опыт работы с распределёнными файловыми системами, а машинное обучение — это и есть использование распределённых алгоритмов.

Речь пойдет о библиотеки для работы с AMPQ - aio-pika. Она имеет всего в районе 1К звёзд на GitHub (по сравнению с 20К+ у Celery). Я рассмотрел абсолютно все популярные (500+ звёзд) решения и остановился именно на этом из-за активной (на текущий момент) разработке и соответствии всем моим требованиям.

Стек, который вы увидите в статье: FastAPI, RabbitMQ, aio_pika и docker. Статья будет полезна тем кто использует Celery в своих проектах, а так же тем, кто только слышал о том, что такое очереди и RabbitMQ.

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

Всем привет! Меня зовут Александр Кленов, и я работаю в Tarantool. Любой серьезный продукт в промышленной эксплуатации требует инструментов observability. «Проверка пульса» продукта стоит на всем известных китах: логирование, трейсинг, мониторинг.

Мне всегда было интересно, как устроена внутренняя кухня больших компаний, как и какими инструментами observability пользуются сотрудники больших проектов. Сегодня я поделюсь руководством по практическому применению модуля метрик Tarantool, которое подготовил для своих коллег. Статья будет интересна как тем, кто использует Taranool в своей практике, так и всем, кто отвечает за observability и мониторинг в своих проектах. Приглашаю под кат!

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а еще предоставляем оптимальную конфигурацию для системы, которая передана в эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.