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

Сеть Интернет по своей архитектуре допускает возможность прямого обмена трафиком между любыми узлами, но все же в большинстве сценариев используется асимметричный вариант использования с относительно небольшим количеством узлов, отдающих содержание (объединенных в CDN, кэширующие сети (например, Google Global Cache), либо отдельные зеркала, расположенные на высокоскоростных каналах). При многих достоинствах такой подход не лишен и серъезных недостатков, прежде всего из-за значительной разбалансированности сети и перегрузке некоторых каналов связи при относительно небольшом трафике на других.

Решением этой проблемы могло стать использование сетей, основанных на прямом обмене трафиком (peer-to-peer или p2p), но создание полностью децентрализованной сети представляет значительную сложность, поэтому во многих случаях все же оставляют некоторые общие реестры, хранящие информацию об узлах-носителях определенного содержания (так, например, работают торрент-трекеры) и на которых регистрируются клиенты сети при подключении. Основным недостатком такого псевдодентрализованного подхода является возможность относительно простой остановки функционирования сети через блокировку соответствующих трекеров. Альтернативой могут быть полностью децентрализованные сети и мы рассмотрим в этой статье основные подходы к их реализации на примере свободного протокола и сети Peernet.

Привет, Хабр! Сегодня мне хотелось бы поговорить о том, почему все больше клиентов ЦОДов предпочитают гибридные облачные инфраструктуры, и поговорить о том, как именно их можно реализовать на практике. Под катом вы найдете разные схемы создания гибридной облачной инфраструктуры. Всех заинтересованных приглашаю обсудить плюсы и минусы такого подхода в развитии ИТ-инфраструктуры.

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

Перед вами перевод Белой Книге, где описывается основная концепция Solana - доказательство истории (Proof-of-History, PoH).

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

Если вы работаете с вебом, вы обязательно столкнётесь с брокерами сообщений. Они бывают разные, но чаще остальных встречаются Kafka, RabbitMQ и AWS SNS/SQS. У каждого из них есть свои особенности, плюсы и минусы — выбирать брокер нужно под свою задачу. 

О том, как сделать правильный выбор, рассказали эксперты из команды курса «Go-разработчик» Яндекс Практикума: 

• Многоуровневая архитектура;
• «Клиент-сервер»;
• «Каналы и фильтры»;
• «SOA»;
• «Издатель-подписчик»;
• «Общие данные»;
• «Одноранговая сеть»;
• «Брокер сервисов».

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

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

В идеальном децентрализованном приложении мы бы хотели хранить все в блокчейне на смарт-контрактах — в хранилище Ethereum: данные не могут быть изменены несанкционированным способом. Но запись какой-либо информации, размером 32 байта обойдется нам в 20000 газа. На момент написания статьи это примерно $0.26, c одной стороны не много, но что если мы хотим хранить в хранилище какой-то значительный массив информации.

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

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

Видео-туториал: https://www.youtube.com/watch?v=1aC1_AlCuT8

Приветствую, коллеги.

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

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

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

Существует множество способов решить эту задачу, и как водится, все они обладают своими достоинствами и недостатками. Основное достоинство описываемого способа заключается в очень простой реализации на стороне приложения (с которого есть необходимость получать аналитику). Но если бы мы сейчас разрабатывали все те приложения, которые нужно “научить” делиться аналитикой, то мы бы, наверное, их подружили с брокером сообщений типа Kafka или Rabbit, а внедрять в уже существующие приложения работу с брокером сообщений (особенно, если брокеры очередей сообщений не развернуты в компании) значительно сложнее, чем просто научить приложения писать свои показатели в лог.

Итак, рассмотрим подробно, как устроена предлагаемая система:

В основе системы лежат события, которые генерируют приложения. События сохраняются в лог (stdout, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).

Немного иной взгляд на концепцию "Web3" технологий.

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

Однако финансовые рынки на основе блокчейна — обычно называемые децентрализованными финансами или просто DeFi — часто включают пользователей, которые идентифицируются только по псевдоанонимным адресам. Чтобы учесть эту уникальную динамику ограниченной кредитной репутации, рынки кредитования DeFi, как правило, имеют избыточное обеспечение, то есть заемщикам необходимо внести залог, превышающий стоимость кредита. Например, заемщику может потребоваться внести 150 долларов в ETH в качестве залога, чтобы взять 100 долларов USDC. Такой избыточный залог гарантирует, что если заемщик не сможет вернуть долг, залог может быть ликвидирован, чтобы возместить убытки кредиторов — основополагающий механизм поддержания платежеспособности.

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

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

В 2019 году к нам обратился «Ростелеком» с запросом о создании федеральной системы дистанционного электронного голосования (ДЭГ) на основе блокчейна. По сравнению с обычным голосованием ДЭГ на блокчейне явно дешевле и быстрее для подсчета голосов; оно также может обеспечить большую явку. Но при этом для большинства людей блокчейн-голосование — это черный ящик, а в голосованиях такого уровня ящик все-таки должен быть прозрачным. О том, как мы добились этого и выполнили другие требования заказчика, я расскажу далее в посте.

У нас есть задача постоянно компилировать тонны плюсового кода. Наш проект — почти 200 000 cpp- и h-файлов, множество Git-веток, сотни разработчиков, десятки билд-агентов: его нельзя единожды скомпилировать, приходится перекомпилировать постоянно, параллельно, разные версии.

Наш проект необычный. Потому что эти 200 000 файлов — это результат автогенерации. Потому что пишем мы на PHP, а потом через KPHP все PHP-исходники превращаются в плюсы. Именно так разрабатывается бэкенд ВКонтакте.

Компилировать тысячи объектников долго. Локально это занимает много часов. Мы использовали distcc — но всё равно медленно. Мы даже пропатчили distcc для поддержки precompiled headers — но даже тогда медленно. И решили написать своё — чтоб стало, наконец, быстро.

В итоге мы написали замену distcc — компилятор nocc. Он не имеет никакого отношения к PHP и даже к KPHP, а просто предназначен для компиляции .cpp → .o в промышленных масштабах.

Это техническая статья про параллелизацию, демоны и специфику С++. Ссылки на GitHub и видео приложу в конце статьи.

Привет! Меня зовут Антон Губарев, я инженер PaaS (Platform-as-a-Service) в Авито. Платформа как сервис позволяет продуктовым командам разработки не тратить время на рутинные инфраструктурные задачи, в том числе такие как определение  оптимальных значений request/limit CPU и RAM для контейнеров в кластерах Kubernetes. Вместо этого они могут сосредоточиться на качестве микросервиса, над которым работают. PaaS умеет автоматически рассчитывать ограничения и выделять ресурсы для каждого из 1 800 микросервисов Авито.

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

Закончилась конференция SmartCon 2022 организованная Chainlink, где выступили более 150 докладчиков и было представлено более 100 презентаций, собрались ведущие представители индустрии Web2 и Web3, такие как Google, Coinbase, SWIFT, FTX, BNY Mellon, T-Systems MMS и др.

Наступление эры, в которой системы с криптографическим обеспечением станут нормой, требует не только монументального объема согласованных усилий, но и принципиальных академических исследований и сильного акцента на потребностях пользователей и корпораций. В этой статье мы расскажем про CCIP и DECO.

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

Доказательство с нулевым разглашением было впервые определено в статье 1985 года "The Knowledge Complexity of Interactive Proof Systems", написанной Шафи Голдвассером и Сильвио Микали. В этой статье авторы показывают, что аттестующий может убедить проверяющего в истинности определенного утверждения о точке данных, не раскрывая никакой дополнительной информации об этих данных.

Zero-Knowledge Proof может быть интерактивным, когда доказывающий убеждает конкретного проверяющего, но должен повторять этот процесс для каждого проверяющего, или неинтерактивным, когда доказывающий создает доказательство, которое может быть проверено любым человеком, использующим то же доказательство. Существует несколько реализаций доказательства нулевого знания, включая zk-SNARKS, zk-STARKS, PLONK и Bulletproofs, каждая из которых имеет свой размер доказательства транзакции, доказательство доказательства, время проверки и многое другое, работая с различными механизмами в своих системах.

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

Действие разворачивается на базе очень большой track & trace системы класса big data. В ней давно откладывали переход на шардированную архитектуру хранилища. Поэтому главному герою предстоит справиться справиться со злом, пробудившимся в системе под нагрузкой: деградацией производительности, полкой по блокировкам и алертами о перегрузке.

В конце — как обычно, хэппи-энд. Наш герой бесстрашно меняет архитектуру решения на лету без downtime (DT) и обеспечивает штатную работу системы. Зло повержено, а отважный инженер купается в овациях!

Статья написана по мотивам доклада на конференции Saint Highload++ 2022. Если не хотите читать — можно посмотреть видео-версию выступления.