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

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

Идею этой системы я изложил в прошлой статье. Компания Xona планирует вывести около 300 небольших спутников на низкую орбиту. Каждый спутник будет снабжен приемником сигналов глобальных навигационных систем (ГНСС), по их сигналам спутники будут определять свои траектории движения и синхронизироваться. Из-за удаленности от поверхности земли и ориентации антенны, спутники будут оставаться вне досягаемости наземных постановщиков помех.

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

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

И если обычно программа Hydra делилась на два больших блока «concurrency» и «distributed», то в этом году получился ещё и третий: про «внутренности» баз данных.

Но главное остаётся прежним:

— Конференция посвящена разработке параллельных и распределенных систем

— На ней сходятся вместе IT-индустрия и академический мир (тут можно познакомиться и со свежими теоретическими результатами, и с «историями из продакшна»)

— Доклады на английском

О чём именно расскажут в этот раз? Хотя на сайте описания докладов на английском, для хабрачитателей перевели их на русский.

От переводчиков. Эту коротенькую статью Дейкстры, которой уже 57 лет, Лесли Лампорт назвал «работой, которая начала всю область конкурентных и распределенных алгоритмов». Но на Хабре её до сих пор вроде бы не переводили. Поскольку мы скоро проведём конференцию Hydra, которая посвящена именно этой области, решили восполнить этот пробел. Кстати, как думаете, как лучше переводить на русский слово concurrent? Мы выбрали вариант «конкурентный», но консенсуса тут вроде бы нет.

Эдсгер В. Дейкстра
Технический университет Эйндховена, Нидерланды

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

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

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

Успех Starlink проложил дорогу молодым компаниям, претендующим на заполнение низкой околоземной орбиты своими малыми и не очень спутниками. Производить аппараты на конвейере, запускать сотнями и тысячами, разрабатывать и разворачивать группировку за десятки месяцев - всё это "New Space". Теперь HawkEye360 следит за пожарами лесными и людскими, Spire собирает данные о погоде, OneWeb догоняет Маска, SatelliteVU запускает в космос тепловизоры...а Xona Space Systems готовит для нас новую навигационную систему Pulsar!

Нашёл очень интересный документ, который был подготовлен госкорпорацией «Ростех» в рамках соглашения с правительством и утвержден президиумом Правительственной комиссии по цифровому развитию, использованию ИТ для улучшения качества жизни и условий ведения предпринимательской деятельности в 2019 году. Однако с тех пор про реализацию дорожной карты ничего не слышно.

Что интересного в документе?

На мой взгляд, из данного документа можно попробовать придумать идею для блокчейн-проекта. Для этого предлагаю изучить подготовленные на базе дорожной карты мероприятия по развитию ТРР.

Привет, Хабр! В общем работаю я значит Архитектором Программных Решений. Мы тут монолиты на микросервисы переводим поэтому я решил для наших разработчиков написать пример проекта с сагой и за одно может оно и вам понадобиться поэтому выложил сюда. Статья будет дополняться по мере поступления вопросов от вас и от наших разработчиков

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

Monolite or MicroService ?

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

Давайте для начала разберём что такое монолит и его преимущества и недостатки.

31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа (копия 1, копия 2) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122.

В долгих и жарких спорах удалось выработать стандарт высокого качества. Можно надеяться, что этот стандарт заменит многочисленные «самоделки» энтузиастов и отдельных компаний: ULID, KSUID, CUID и т.д., а в СУБД будут встроены генераторы UUID новых форматов, предназначенных для ключей высоконагруженных систем.

Привет! Меня зовут Денис Васин, я технический директор Waves Enterprise, и мы занимаемся блокчейн-проектами для бизнеса. Благодаря метавселенным, технология недавно снова оказалась на волне популярности. Множество крупных компаний, начиная с Meta, объявили, что планируют создавать подобные проекты с поддержкой распределенных реестров и NFT-токенов. Можно утверждать, что блокчейн в целом постепенно выходит на плато продуктивности — самое время трезво оценить его и понять, когда он вообще нужен. Постараюсь сделать это далее в посте.

Привет! Меня зовут Павел Агалецкий, я старший инженер в команде архитектуры. Одна из областей ответственности нашей команды — синхронное (RPC) и асинхронное взаимодействие между сервисами. 

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

Архитектура сети данных (data mesh) распределяет владение данными среди команд из разных предметных областей, с федеративным управлением и децентрализованными продуктами по обработке данных. Сеть данных отличается от других аналогичных архитектур именно своей высокой децентрализацией: она распределена, а не централизована.

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

SSB - это децентрализованная offline-first социальная сеть. Децентрализованная - это значит, что в ней нет сервера, который можно заблокировать, или на котором админ может закрыть вам доступ. Offline-first означает, что всё происходит в первую очередь на вашем устройстве.

Интернет-шатдаун ломает SSB не так сильно, как, например, Facebook. Вы можете продолжать читать и писать без доступа в интернет. Для синхронизации достаточно нескольких минут.

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

Я верю в "частичные идеи". Бывает, человек крутит в голове половину чего-то важного. А у кого-то есть вторая половина. Чтобы мысли встретились и "клацнули", кто-то должен свою половину опубликовать. Сегодня это делаю я. Считайте это скорее приглашением к обсуждению, нежели готовым рецептом.

Традиционно для сценариев поточной обработки с использованием Map-Reduce рассматриваются такие решения как Hadoop/Spark, либо используются конвейерные системы (например Kafka), для которых есть возможность реализовать концепцию потоков (streams) с помощью дополнительных инструментов (в случае с Kafka это Kafka Connect (для подключения к источникам и получателям потока) и Kafka Streams для реализации Map-Reduce на потоке сообщений.

Начиная с версии 3.9 RabbitMQ анонсировал поддержку нового типа очереди, оптимизированного для поточной обработки. В этой статье мы посмотрим на основные отличия очередей RabbitMQ от классического режима очереди сообщений, а также возможные сценарии использования (с примерами кода на Go).

Допустим есть ситуация, когда у тебя много проектов на github и ты хочешь хранить локальную копию всех проектов на разных устройствах и носителях. У тебя есть простой вариант - указать список репозиториев, написать bash скрипт, который бы клонировал все репозитории, и еще один bash скрипт, который бы их всех обновлял. Но bash скрипты не очень приятная вещь, когда ты знаешь python. С python будет по легче, но не забудь тебе придётся писать асинхронные REST API запросы к серверу GitHub для получения списка репозиториев, потому что писать вручную список репозиториев долго, потом тебе придётся разобраться как обновлять и копировать репозитории в многопоточном режиме, потому что синхронное обновление даже 40 репозиториев это 2 минуты ожидания. В общем работенка на два вечера + документация проекта + тестирование, в итоге 3 дня разработки для достижения поставленной цели. Но зачем тебе это делать когда это уже сделали ?

→ Проект git_clones

→ Документация git_clones

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