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

Предисловие

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

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

Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.

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

В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.

Потестируйте Backyards на собственных кластерах: curl https://getbackyards.sh | sh && backyards install -a --run-demo. Если интересно, см. детали последнего релиза.

В июне мы представили Backyards, автоматизированную «сервисную сетку» (service mesh) поверх нашего оператора Istio. Она сильно упрощает управление service mesh в многооблачной и гибридной инфраструктуре. Backyards интегрирован в платформу управления контейнерами Pipeline на Banzai Cloud, но также доступен как отдельный продукт. Конечно, интеграция с Pipeline даёт множество конкретных преимуществ (как управление приложениями на нескольких облаках), но Backyards работает на любой установке Kubernetes.

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

Разработчики приложений, работающие на Java, при использовании интерфейса JMS, часто предпочитают работать со Spring Framework. Spring может упростить написание кода новых приложений, предоставляя шаблоны для общих паттернов (templates for common patterns) и успешно используется в течение многих лет с классами MQ JMS. Класс Spring JmsTemplate является ключевым интерфейсом, но он по-прежнему зависит от конфигураций и зависимостей в коде.

Spring Framework включает в себя различные модули для различных нужд. Одним из таких компонентов является Spring Boot. Spring Boot стартеры удобно подтягивают все зависимости и библиотеки авто-конфигураций, необходимые для использования конкретной технологии. Это позволяет очень легко начать работу с новым приложением и технологией, быстрее, чем работать непосредственно с классами, такими как JmsTemplate. Итак, как мы можем воспользоваться этим легким доступом для приложений MQ?

Переведено @middle_java

Я из компании Luxoft.
Согласно Opennet: LeoFS — распределённое отказоустойчивое хранилище объектов LeoFS, совместимое с клиентами, использующими API Amazon S3 и REST-API, а также поддерживающего режим работы в роли NFS-сервера. Имеются оптимизации для хранение как мелких, так и очень больших объектов, присутствует встроенный механизм кэширования, возможна репликация хранилищ между дата-центрами. Среди целей проекта отмечается достижение надёжности 99.9999999% за счёт избыточного реплицирования дубликатов и исключения единой точки отказа. Код проекта написан на языке Erlang.

LeoFS состоит из трёх компонентов:

• LeoFS Storage — обслуживает операции добавления, извлечения и удаления объектов и метаданных, отвечает за выполнение репликации, восстановления и формирования очереди запросов клиентов.
• LeoFS Gateway — обслуживает HTTP-запросы и перенаправляет ответы клиентам с использованием REST-API или S3-API, обеспечивает кэширование наиболее востребованных данных в памяти и на диске.
• LeoFS Manager — отслеживает работу узлов LeoFS Gateway и LeoFS Storage, ведёт мониторинг состояния узлов и проверяет контрольные суммы. Гарантирует целостность данных и высокую доступность хранилища.

В этом посте установим Leofs c помощью ansible-playbook, протестируем S3, NFS.

В этой статье я расскажу вам о DAG (Directed Acyclic Graph, направленный ациклический граф) и его применении в распределённых реестрах, и мы сравним его с блокчейном.



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

Это 3-я часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology. В предыдущих статьях мы познакомились с

1. Blockchain & Block API
2. Storage API.

Теперь, когда Вы имеете представление о том, как вызвать подходящее API для постоянного хранилища при разработке смарт-контракта с помощью Python в сети Ontology, давайте перейдём к знакомству с тем, как использовать Runtime API (Contract Execution API). Runtime API имеет 8 связанных API, которые предоставляют общие интерфейсы для выполнения контракта и помогают разработчикам получать, преобразовывать и проверять данные.

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

Команда Serokell с богатым опытом разработки крупных блокчейн проектов не могла остаться в стороне. Мы делегировали на конкурс пятерых сотрудников, а уже через две недели они заняли в нем первое место под (не)скромным рандомным ником Sexy Chameleon. В этой статье я расскажу о том, как им это удалось. Надеемся, за ближайшие десять минут вы как минимум прочитаете интересную историю, а как максимум найдете в ней что-то полезное, что сможете применить в своей работе.

Но давайте начнем с небольшого погружения в контекст.

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

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

СМС-сообщения — популярнейший способ двухфакторной аутентификации (2FA). Ее используют банки, электронные и крипто-кошельки, почтовые ящики и всяческие сервисы; число пользователей метода приближается к 100%.

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



Раскрыты тысячи эпизодов SIM-свопинга — так назвали эту схему мошенничества. Масштабы бедствия говорят о том, что скоро мир откажется от 2FA по СМС. Но этого не происходит — в исследовании рассказывают, что выбирают метод 2FA не пользователи, а владельцы сервисов.

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

Архитектуры, управляемые событиями (Event Driven Architecture), в целом, и Apache Kafka, в частности, привлекли в последнее время большое внимание. Для реализации всех преимуществ архитектуры, управляемой событиями, механизм делегирования событий должен быть по своей сути асинхронным. Тем не менее, могут существовать некоторые особые сценарии/потоки использования, в которых требуется семантика Синхронного Запроса-Ответа. В этом выпуске показано, как реализовать "Запрос-Ответ" с помощью Apache Kafka.

Перевел @middle_java

Это вторая часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology. В предыдущей статье мы познакомились с Blockchain & Block API смарт-контракта Ontology.

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

В статье я расскажу про то, что такое Assurance Contract, также известные как механизм предоставления общественных и групповых благ, и вместе напишем свою собственную реализацию краудфандинга на основе Автономных Агентов на платформе Obyte.

Спустя два года я вернулся к блогу ради поста, который отличается от обычных занудных лекций о Haskell и математике. Последние несколько лет я занимался финансовыми технологиями в ЕС, и, кажется, пришло время написать на тему, которой технические СМИ уделили мало внимания.

Недавно Facebook выпустил то, что именует «новой платформой финансовых сервисов» под названием Libra. Она позиционируется как цифровая расчётная система, основанная на корзине международных валют, которые управляются на «блокчейне» и хранятся в денежном пуле, управляемом из Швейцарии. Цели проекта амбициозны и влекут масштабные геополитические последствия.

В Financial Times и New York Times много разумных статей о необоснованных денежных и экономических предположениях в основе предлагаемой финансовой системы. Но не хватает специалистов, способных на анализ с технической точки зрения. Не так много людей работают над финансовой инфраструктурой и публично говорят о своей работе, поэтому данный проект не слишком освещён в технических СМИ, хотя его внутренности открыты для всего мира. Я имею в виду открытые исходники в репозиториях Libra и Calibra Organisation.

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

Всем привет. Меня зовут Александр, я Java-разработчик в группе компаний Tinkoff.

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

В статье я расскажу про наш опыт перехода на сервис-ориентированную архитектуру, сопровождающуюся переездом в Kubernetes, и про решение сопутствующих проблем. Будет рассмотрен подход к организации системы распределенного кэширования In-Memory Data Grid (IMDG), его преимущества и недостатки, из-за которых мы решили написать собственное решение.

В статье рассматривается проект, бэкэнд которого написан на Java. Поэтому речь также пойдет про стандарты в области временного In-memory-кэширования. Обсудим спецификацию JSR-107, несостоявшуюся спецификацию JSR-347, а также особенности кэширования в Spring. Добро пожаловать под кат!

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

Это первая часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology при помощи инструмента разработки смарт-контрактов SmartX.

В этой статье мы начнём знакомство с API смарт-контракта Ontology. API смарт-контракта Ontology разделен на 7 модулей:

1. Blockchain & Block API,
2. Storage API,
3. Runtime API,
4. Native API,
5. Upgrade API,
6. Execution Engine API и
7. Static & Dynamic Call API.

Blockchain & Block API является основной частью системы смарт-контрактов Ontology. Blockchain API поддерживает базовые операции блокчейн-запроса, как например получение текущей высоты блока, тогда как Block API поддерживает базовые операции блок-запроса, как например запрашивание количества транзакций для данного блока.

Давайте приступим!

Для начала создайте новый контракт в SmartX, а затем следуйте инструкциям ниже.

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

В этой статье мы разберем на двух примерах, как написать смарт контракт на языке C++, используя WASM на основе блокчейн сети Ontology. Сегодня, после нескольких месяцев стабильной работы в тестовом режиме, Ontology запустила WASM в основной сети, что позволяет безболезненно и с меньшими издержками переносить контракты dApp со сложной бизнес-логикой на блокчейн, тем самым значительно обогащая dApp экосистему.

Ontology Wasm также поддерживает создание смарт контрактов на языке Rust, об этом можно почитать тут.

Ниже рассмотрим два примера смарт-контракта: сначала напишем “Hello world!” и потом создадим виртуальные денежный конверт, который можно будет отправить другу в качестве подарка.

Разработка WASM-контракта с помощью С++