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

Одно из первых упоминаний распределенных вычислений относится к 1973 году. Сотрудники научно-исследовательского центра Xerox PARC Джон Шох и Джон Хапп написали программу, которая рассылала себя по другим работающими компьютерам через локальную сеть PARC.

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

Ещё одним значимым событием было создание проекта SETI@Home (Search for Extra-Terrestrial Intelligence at Home) для поиска внеземного разума путём анализа данных с радиотелескопов, в том числе на домашних компьютерах участников. Данный проект был запущен в 1999 году и оста новлен в 2020-м. Эта распределенная система была построена на платформе BOINC, созданной в университете Беркли.

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

Ещё одной важной областью применения распределённых вычислений является обработка больших данных с использованием методов машинного обучения и Data Mining. В качестве языка программирования для этой цели в последние годы на лидирующие позиции выходит язык Python. По состоянию на март 2020 года, согласно рейтингу TIOBE, Python находится на третьем месте, хотя ещё в 2015 году занимал лишь седьмое.

Одной из известных проблем языка Python является относительно низкая производительность в сравнении с компилируемыми языками – такими как C++. Данный недостаток является дополнительным поводом применять параллельное и распределённое программирование в процессе разработки.

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

В большинстве случаев вся enterprise разработка сводится к выполнению одних и тех же требований: создается заявка, в зависимости от типа заявки у нее есть какой-то жизненный цикл, по завершению жизни заявки мы получаем (…или не получаем) желаемое. Под заявкой мы можем подразумевать все что угодно, начиная с покупки в интернет-магазине товара, денежного перевода или расчета траектории баллистической ракеты. У каждой заявки есть свой жизненный путь и что важно отметить - время жизни, и чем меньше это время, тем лучше. Иными словами, чем быстрее мой банковский перевод осуществится, тем лучше. Требования тоже схожи, побольше RPC operations per second, поменьше Latency, система должна быть отказоустойчивой, масштабируемой и должна быть готова вчера. Есть миллион инструментов, сотни баз данных, различные подходы и паттерны. И все уже давно написано, нам остается лишь правильно использовать готовые технологии в наших проектах. 

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

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

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

Итак Ява-машина — это ОС. Даже круче чем ОС местами. На самом деле это не такое уж заявление из ряда вон. Ведь всем прекрасно известен пример полноценной ОС, значительно основанной (изначально) на Ява – Андроид. Кроме того, существуют и ОС в классическом понимании полностью на базе JVM.

Итак, какие признаки ОС мы имеем у JVM? Управление памятью - несомненно. Управление потоками - да, но как правило на базе существующих местных потоков базовой ОС. Тем не менее, потоки являются важной неотъемлемой и очень развитой подсистемой машины, предоставляя гораздо больше сервисных средств, чем базовые потоки ОС.

Ввод-вывод также очень развит, если иметь в виду всю инфраструктуру Ява, со всеми серверами и библиотеками. В этом смысле ввод-вывод базовой ОС - примерно как старый Биос для последней, осуществляет низкоуровневые операции.

У Ява есть философия. Если в Юникс - всё файл, то в Ява всё (почти) есть объект.

Есть важная часть системы, про которую многие либо не знают, либо забывают. Ява – среда с мощнейшими средствами разграничения доступа. Именно поэтому в том числе её широко применяют в банковской сфере.

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

Во-первых, JVM – управляемая (managed) среда. Это не только означает безопасность исполнения кода. Это также модель разграничения, аналогичная выделению ядра в большинстве ОС в отдельный контекст привилегированного исполнения. Т.н. нативный контекст исполнения, в котором работает сама машина - прямой аналог реального (или подобного) режима исполнения процессором ядра ОС. Сама машина имеет полный контроль над всеми процессами внутри неё. Байткоду достается уже сильно ограниченная, защищённая среда. Степень свободы загружаемого байткода определяется Ява-машиной и её рантайм-библиотекой. Более того, сам механизм загрузки байткода (классов в первую очередь) иерархичен и подразумевает разделение прав и ответственности – ветвление прав. Это ветвление достигается за счёт применения отдельных загрузчиков классов. При этом создаётся иерархия областей видимости, код, загруженный в одном контексте не имеет доступа к другому независимому контексту. При этом нельзя получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм рефлексии, даже к целым отдельным объектам. Этот механизм встроен в язык (ключевые слова private, protected и т.п.) и в платформу – уже названные загрузчики и конечно менеджеры безопасности, о которых тоже не забудем. Такие механизмы обеспечивают разделение контекстов выполнения аналогично процессам классических ОС. Я бы даже сказал более строгое и надёжное разделение.

Загрузчики классов совместно с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды исполнения Ява, а что не может. Механизм этот необычайно гибкий. При этом, в отличие от нативного кода, загружаемый байткод проходит полную проверку на валидность (он не может затем вызвать непредсказуемый сбой) и безопасность - так как возможные варианты поведения ограничены теми же загрузчиком+менеджером безопасности. Вы слышали когда-нибудь о вирусах на Яве?

Эта статья о следующем эволюционном шаге в развитии систем обработки данных. Тема амбициозная, поэтому расскажу сначала немного о себе. Вот уже больше 10 лет я работаю над проектами в области CRDT и синхронизации данных. За это время успел поработать на университеты, стартапы YCombinator и известные международные компании. Мой проект последние три года – Replicated Object Notation, новый формат представления данных, сочетающий возможности объектной нотации (как JSON или YAML), сетевого протокола и оплога/бинлога. Вы могли слышать про другие проекты, работающие в том же направлении, например, Datanet, Automerge и другие. Также вы могли читать Local-first software, это наиболее полный манифест данного направления Computer Science. Авторы - замечательный коллектив Ink&Switch, включая широко нам известного по "Книге с Кабанчиком" М.Клеппманна. Или вы, возможно, слушали мои выступления по этой теме на различных конференциях.

Идеи этой статьи перекликаются с тем, что пишет последние годы Pat Helland: Immutability Changes Everything и др. Они смежны с проектами IPFS и DAT, к которым я имею отношение.

Итак. Классические БД выстроены на линейном логе операций (WAL). От этого лога выстроены транзакции, от него же выстроена репликация master-slave. Теория репликации с линейным логом написана ещё в начале 1980-х с участием небезызвестного Л. Лампорта. В классических legacy системах с одной большой центральной базой данных всё это работает хорошо. Так работают Oracle, Postresql, MySQL, DB2 и прочие классические SQL БД. Так работают и многие key-value БД, например, LevelDB/RocksDB.

Но линеаризация не масштабируется. Когда система становится распределённой, всё это начинает ломаться. Образно говоря, линейная система – это что-то вроде греческой фаланги. Нужно, чтобы все шли ровно, а для этого хорошо, чтобы земля была везде ровной. Так получается не всегда: где-то электричество отключили, а где-то сеть медленная. Хотя в системе Google Spanner и было показано, что с достаточно большим бюджетом землю можно сделать ровной абсолютно везде, мы всё же отметим, что Google тоже бывает отключается целиком по совершенно смешным причинам.

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

Что может объединить эти два мира? Ответ: диалог экспертов этих двух миров (криптоэкономического и корпоративного) по вопросам стандартизации технологический и лучших практик, а также принятие общих технологических подходов. Такой диалог потенциально сможет упростить последующие интеграционные процессы и ускорить принятие блокчейн-технологий широкими массами.

Но как этого достичь? В коммерческой среде, когда нужно наладить взаимодействие участников какого-либо сектора экономики, создаются ассоциации и консорциумы. В чисто технологических вопросах такими площадками выступают центры стандартизации, например МСЭ-Т(ITU-T), ИСО (Международная организация по стандартизации). В России такой независимой площадкой объединения экспертов блокчейн-технологий выступает Технический Комитет по стандартизации "Программно-аппаратные средства технологий распределённого реестра и блокчейн" (http://bccmt.ru).

Как руководитель одной из рабочих групп (с декабря 2019 года) и эксперт ISO TC 307 DLT (TC 307 - Blockchain and distributed ledger technologies) я хочу поделиться информацией по стандартизации блокчейн технологий в России и мире. А также привлечь внимание экспертов блокчейн рынка к работе ТК 159, как площадке взаимодействия, которая может многое дать своим участникам.

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

Необходимое отступление: кластер в Apache Ignite

Введение

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

Введение

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

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

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

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

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

Представим, что вам нужно настроить мониторинг распределённой базы данных, такой как GridGain. Метрики положим в Prometheus. Графики нарисуем в Grafana. Про систему оповещения не забудем – для этого настроим Zabbix. Для анализа трейсов воспользуемся Jaeger. Для управления состоянием и CLI хорош. А для SQL запросов воспользуемся бесплатным JDBC клиентом вроде DBeaver.

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

А теперь наймем для поддержки и настройки всего этого зверинца команду специалистов и будем жить долго и счастливо. Или нет, потому что столько ресурсов мы на эту задачу просто не получим. Придется искать способы удешевить обслуживание. В GridGain моя команда для этого написала собственный инструмент, закрывающий все потребности распределенной In-Memory платформы Apache Ignite или ее корпоративной версии GridGain.

Control Center умеет работать с GridGain начиная с версии 8.7.23 любой редакции, а также с Apache Ignite версии не младше 2.8.1.

Всем привет!

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

Вчера произошел запуск NEAR, проекта, над которым я и мои коллеги работали последние 2 года.

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

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

Зачем нужны протоколы блокчейна

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

В краткосрочной перспективе это уже используется для построения финансовых сервисов, которые не контролируются банками и государствами. На Ethereum – самой популярной на сегодня платформе для децентрализованных приложений – за последние два года появилось огромное количество интересных финансовых сервисов: MakerDAO построили децентрализованную валюту, чья цена почти точно равна одному доллару, позволяя использовать финансовые сервисы на платформе с использованием неволатильных активов. Compound построили возможность класть деньги в их сервис, и получать почти гарантированный доход, Augur и Flux построили сервисы, на которых можно делать ставки на различные события в реальном мире. Помимо этого на Ethereum запущено большое количество различных децентрализованных бирж. Все эти сервисы либо автономны и не контролируются никем, либо контролируются коллективно участниками сервиса.

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

В конце октября запускаем новую группу курса «Архитектура и шаблоны проектирования» и приглашаем всех специалистов на бесплатный Demo-урок «Шаблон адаптер», который проведёт Матвей Калинин — главный разработчик в одном из крупнейших банков страны.

Введение

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

Наша компания специализируется на разработке программных решений класса ERP, в составе которых львиную долю занимают транзакционные системы с огромным объемом бизнес-логики и документооборотом а-ля СЭД. Современные версии наших продуктов базируются на технологиях JavaEE, но мы также активно экспериментируем с микросервисами. Одно из самых проблемных мест таких решений – интеграция различных подсистем, относящихся к смежным доменам. Задачи интеграции всегда доставляли нам огромную головную боль, независимо от применяемых нами архитектурных стилей, технологических стэков и фреймворков, однако в последнее время в решении таких задач наметился прогресс.

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

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

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

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