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

Привет, я хочу рассказать про проект FabEx — block explorer для Hyperledger Fabric, недавно принятый в Hyperledger Labs и имеющий некоторые преимущества относительно официального эксплорера. Проект написан полностью на Golang (а не на Nodejs, как официальный), хранит данные о блокчейне в MongoDB или Cassandra по выбору (а не в PostgreSQL, как официальный), имеет как GRPC, так и REST API. Eго легко расширять, например, можно легко добавить больше реализаций хранилища. Детали под катом.

12 июля 2018 года увидел свет первый коммит проекта :telemetry. Автор коммита — Аркадий Гил, но README утверждает, что авторское право принадлежит © 2018 Chris McCord and Erlang Solutions, а последний коммит по состоянию на сегодня был сделан Жозе Валимом.

Библиотека представляется следующим образом:

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

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

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

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

Передача сообщений между процессами на разных узлах, а также между ссылками и мониторами прозрачна […]

В текущей пандемии COVID-19 появилось много проблем, на которые хакеры с удовольствием набрасывались. От лицевых щитков, распечатанных на 3D-принтере и медицинских масок домашнего изготовления до замены полноценного механического аппарата искусственной вентиляции лёгких – этот поток идей вдохновлял и радовал душу. В то же самое время были попытки продвинуться и в другой области: в исследованиях, нацеленных на борьбу непосредственно с самим вирусом.

Судя по всему, наибольший потенциал для остановки текущей пандемии и опережения всех последующих есть у подхода, пытающегося докопаться до самого истока проблемы. Этот подход из разряда «узнай своего врага» исповедует вычислительный проект Folding@Home. Миллионы людей зарегистрировались в проекте и жертвуют часть вычислительных мощностей своих процессоров и GPU, создав таким образом крупнейший [распределённый] суперкомпьютер в истории.

Но для чего конкретно используются все эти экзафлопы? Почему нужно бросать такие вычислительные мощности на фолдинг [укладку] белков? Какая тут работает биохимия, зачем вообще белкам нужно укладываться? Вот краткий обзор фолдинга белков: что это, как он происходит и в чём его важность.

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

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

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

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

Какие преимущества появляются при совмещении бизнес-логики и БД? Какие нюансы надо учесть, прибегая к такому подходу? Что с надёжностью и доступностью сервисов? Расскажем подробно об этом всём.

Продолжаем серию вебинаров, где разработчики GridGain не только рассказывают, но и показывают, как работать с теми или другими возможностями Apache Ignite.

Если пропустили, обязательно посмотрите Руководство по настройкам безопасности для Apache Ignite и GridGain с примерами.

В четверг 23 апреля поговорим о том, как в Ignite устроен ребаланс, и подробно разберем примеры логов, чтобы научиться определять, когда ребаланс остановлен, а когда все еще активен, и безопаснее перезапускать узлы кластера. Также пример поможет понять, почему был автоматически выбрал исторический или полный ребаланс. Перед вебинаром советуем прочитать про распределение данных в Apache Ignite.
Регистрация

В предыдущей статье мы говорили о новой программной модели чейнкода в Hyperledger Fabric. И хотя релиз нового Go SDK ещё не состоялся, ничто не мешает нам уже сейчас посмотреть, что нас ждет в будущем, и даже протестить это на тестовой сборке. Не всё ещё реализовано (как, например, commit handlers), но планируемый дизайн программной модели уже ясен, так что давайте взглянем на него ближе.

Победители первого этапа конкурса MOBI Grand Challenge применяют блокчейн к автоиндустрии и рынку транспорта новыми способами, начиная от колонн беспилотных автомобилей и заканчивая автоматизированной V2X-связью.

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

Mobility Open Blockchain Initiative (MOBI), некоммерческая инициатива, направленная на ускоренное внедрение стандартов, связанных с блокчейном, в автомобильной и транспортной промышленности, провела первую фазу своего проекта MOBI Grand Challenge (MGC), рассчитанного на три года и направленного на выявление инновационных способов применения блокчейна в формирующейся экосистеме подключенных к сети и автономных автомобилей.

Согласно заявлению MOBI: «Целью MGC является создание жизнеспособной, децентрализованной, специальной сети связанных между собой автомобилей на распределенной бухгалтерии (distributed ledger technology) и инфраструктуры, которая может надежно обмениваться данными, координировать поведение и, в конечном счете, улучшать городскую мобильность».

Доброго времени суток!

В этой статье рассмотрим настройку кластера из трех узлов ZooKeeper (служба координации распределенной системы), два из которых — брокеры сообщений Kafka, третий — управляющий.

В результате будет реализована следующая схема компонентов:

Не так давно был выпущен первый релиз fabric-contract-api-go — реализации новой программной модели чейнкода по RFC 0001. Давайте разберемся, что это и как этим пользоваться.

​ В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit'a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.

So what's the problem?

​ Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.

​ Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.

Как минимум до конца апреля мы вряд ли увидимся оффлайн: конференции и другие мероприятия отменились или перешли в онлайн. Самое время посмотреть полезные видео, которые вы откладывали на потом (проверьте, что новенького на канале Apache Ignite сообщества). Если хочется побольше интерактива, присоединяйтесь к вебинарам про распределенные вычисления, Ignite SQL и настройки безопасности.

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

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

^{Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In distributed systems, theory and practice are combined:
nothing works and no one knows why.}

Чтобы доказать, что шутка в эпиграфе — абсолютная глупость, мы уже в третий раз проводим SPTDC (school on practice and theory of distributed computing). Об истории школы, её сооснователях Петре Кузнецове и Виталии Аксёнове, а также об участии JUG Ru Group в организации SPTDC мы уже рассказывали на Хабре. Поэтому сегодня — о школе в 2020 году, о лекциях и лекторах, а также об отличиях школы от конференции.

Школа SPTDC пройдёт с 6 по 9 июля 2020 года в Москве.

Все лекции будут на английском языке. Основные темы лекций: persistent concurrent computing, cryptographic tools for distributed systems, formal methods for verifying consensus protocols, consistency in large-scale systems, distributed machine learning.


Сразу догадались, в каком воинском звании персонажи на картинке? Я вас обожаю.

Всем привет. На связи Владислав Родин. В настоящее время я преподаю на портале OTUS курсы, посвященные архитектуре ПО и архитектуре ПО, подверженного высокой нагрузке. В преддверии старта нового потока курса «Архитектор высоких нагрузок» я решил написать небольшой авторский материал, которым хочу поделиться с вами.

---

Введение

Из-за того, что на HDD может выполняться лишь порядка 400-700 операций в секунду (что несравнимо с типичными rps'ами, приходящимися на высоконагруженную систему), классическая дисковая база данных является узким горлышком архитектуры. Поэтому необходимо уделить отдельное внимание паттернам масштабирования данного хранилища.

На текущий момент имеются 2 паттерна масштабирования базы: репликация и шардирование. Шардирование позволяет масштабировать операцию записи, и, как следствие, снижать rps на запись, приходящийся на один сервер вашего кластера. Репликация позволяет делать тоже самое, но с операциями чтения. Именно этому паттерну и посвящена данная статья.

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

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

Это третья часть в серии статей "Учимся разворачивать микросервисы", и сегодня речь пойдет о Helm 3. В прошлой части мы создали Kubernetes конфигурацию для учебного проекта из 2 микросервисов (бекенда и шлюза) и задеплоили все это в Google Kubernetes Engine. В этой статье мы напишем Helm-чарт для нашей системы, создадим для него репозиторий на основе GitHub Pages и задеплоим проект в GKE с помощью Helm.

В прошлом году в Санкт-Петербурге прошла первая конференция Hydra, посвящённая параллельным и распределённым системам. С докладами выступали лауреаты премии Дейкстры и премии Тьюринга (Лесли Лэмпорт, Морис Херлихи и Майкл Скотт), создатели компиляторов и языков программирования (C++, Go, Java, Kotlin), разработчики распределённых баз данных (Cassandra, CosmosDB, Yandex Database), а также создатели и исследователи алгоритмов и структур данных (CRDT, Paxos, wait-free data structures). В общем, на этом месте уже можно брать отпуск, сворачивать окно IDE, открывать плейлист на YouTube с лучшими докладами Hydra 2019 — и пусть task scheduler немного подождёт.

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

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