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

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

В .Net Core 3 добавилась отличная возможность передачи контекста корреляции в HTTP-заголовках, поэтому если ваши приложения используют прямые HTTP-вызовы для межсервисного взаимодействия, то вы можете воспользоваться этой коробочной функцональностью. Однако, если архитектура вашего бекенда подразумевает взаимодействие через брокера сообщений (RabbitMQ, Kafka и т.п.), то вам по-прежнему необходимо озаботиться темой передачи корелляционного контекста через эти сообщения самостоятельно.

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

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

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

Привет, я работаю в команде проекта РРД КП (распределенный реестр данных для контроля жизненного цикла колесных пар). Здесь я хочу поделиться опытом нашей команды в разработке корпоративного блокчейна для данного проекта в условиях ограничений, накладываемых технологией. По большей части я буду говорить о Hyperledger Fabric, но описанный здесь подход может быть экстраполирован на любой permissioned блокчейн. Конечная цель наших изысканий  —  готовить корпоративные блокчейн-решения так, чтобы итоговым продуктом было приятно пользоваться и не слишком тяжело поддерживать.

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

Это вторая часть из серии статей "Учимся разворачивать микросервисы". В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.

Предлагаю ознакомиться с расшифровкой доклада Александра Сигачева Service Discovery в распределенных системах на примере Consul.

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

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

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

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

Предлагаю ознакомиться с расшифровкой лекции "Hadoop. ZooKeeper" из серии "Методы распределенной обработки больших объемов данных в Hadoop"

Что такое ZooKeeper, его место в экосистеме Hadoop. Неправда о распределённых вычислениях. Схема стандартной распределённой системы. Сложность координации распределённых систем. Типичные проблемы координации. Принципы, заложенные в дизайн ZooKeeper. Модель данных ZooKeeper. Флаги znode. Сессии. Клиентский API. Примитивы (configuration, group membership, simple locks, leader election, locking без herd effect). Архитектура ZooKeeper. ZooKeeper DB. ZAB. Обработчик запросов.

Нет, запуск децентрализованного приложения (dapp) на блокчейне не приведет к успешному бизнесу. На самом деле, большинство пользователей даже не задумывается работает ли приложение на блокчейне — они просто выбирают продукт, который дешевле, быстрее и проще.

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

Довольно часто в whitepaper'ах приложений, которые построены на блокчейне, можно найти параграф, в котором сказано: "блокчейн дорогой и не способен поддерживать требуемое число транзакций в секунду. К счастью, много умных людей работает над масштабированием блокчейна и к моменту запуска нашего приложения он станет достаточно масштабируем".

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

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

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

Счастливого запоздалого Нового года, Spring коммьюнити!

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

Образец приложения BookStore Service Broker был обновлен для демонстрации интеграции нескольких различных проектов Spring, включая Spring Cloud Open Service Broker, Spring Data, Spring Security, Spring HATEOAS и, конечно, Spring WebFlux и Spring Boot. Все эти проекты имеют версии GA, включающие Реактивную поддержку и готовые к продакшену в ваших собственных приложениях и сервисах.

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

Чем плохи атомарные свопы и как каналы им помогут, что важного произошло в хардфорке Constantinople и как быть, когда нечем платить за газ.

Главная мотивация любого специалиста по безопасности— желание избежать ответственности.

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

Предисловие

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

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

Я работаю в команде 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 с доставкой одноразовых кодов через блокчейн, и расскажем, как владельцу сервиса его подключить.