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

Системы оркестрации контейнеров существенно упростили управление многокомпонентными системами, в том числе основанными на микросервисной архитектуре. Но остался открытым вопрос организации надежного обмена сообщениями между микросервисами, координации последовательности операций при распределенной архитектуре. В этой статье мы рассмотрим подход Incubating (CNCF)-проекта Dapr (Distributed Application Runtime) по использованию Sidecar-контейнеров в Kubernetes для реализации микросервисной архитектуры, основанной на событиях. 

В первой теоретической части мы поговорили про то, что такое обновляемый смарт-контракт и как работают обновления.

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

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

ИТ в медицине — достаточно скользкая тема. Нужно отметить, что за последние 10 лет реально растет "проникновение" (как выражаются бюрократы) ИТ в медицину и в здравоохранение в целом. Спецы, работающие в линейных МО (мед. организациях), не дадут соврать. Мне даже представляется, что РФ не то, что отстает, но даже где-то и опережает глобальные тренды. Правда, на мой взгляд, есть разрыв между собственно технологиями и уровнем подготовки и мотивации пользователей, для которых они создаются. Ну и сами ИТ решения не всегда решения, а, скорее, головная боль

Любой МО нужен софт, и не просто бухгалтерский 1С, управление торговлей и CRM, нужен специализированный, МИСы (медицинские информационные системы), и не одна. Нужно вести учет приема пациентов, как-то получать, анализировать и хранить диагностические данные (изображения, графики, результаты анализов, и много чего еще), вести карты с записями о болезнях и т.д. и т.п.

Если МО участвует в программе обязательного мед. страхования (ОМС), она должна ежемесячно формировать и отправлять в территориальный (федеральный) фонд ОМС (ТФОМС) отчеты о количестве принятых в МО пациентов, характере и стоимости оказанной им мед. помощи. Без этого, никак нет возможности получить денежное возмещение от страховых компаний за оказанные услуги.

Собственно отчет — это 2-3 XML файла, упакованных в ZIP архив. Для подготовки пакетов с отчетами, разбора протоколов ошибок и оформления реестров к счетам для страховых компаний, я написал небольшую библиотеку и web приложение (сервер задач) для доступа к библиотеке по REST API.

Возможно, это будет интересно специалистам, или более широкой публике.

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

Чтобы получить максимальную пользу от этой статьи, вы должны иметь начальные знания о смарт-контрактах на базе Ethereum и EVM. В этой серии статей приводится краткое описание кода, так что опыт программирования не менее трех месяцев будет полезен, как и базовое понимание Solidity и способов его компиляции, что такое смарт-контракты и как они развертываются, а также как использовать такие инструменты, как Metamask и Hardhat.

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

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

Эта статья впервые появилась в журнале Computer и подготовлена InfoQ & IEEE Computer Society.

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

За десятилетие, прошедшее с появления теоремы, разработчики и исследователи использовали теорему CAP (а иногда и злоупотребляли ею) как повод для изучения широкого спектра новых распределенных систем. Движение NoSQL также использовало её в качестве аргумента против традиционных баз данных.

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

• согласованность (С), эквивалентная наличию единственной актуальной копии данных;
• высокая доступность (A) этих данных (для обновлений); и
• устойчивость к сетевым разделениям (P).

Такое толкование CAP помогало разработчикам быть открытыми для более широкого диапазона систем и компромиссов; действительно, за последнее десятилетие возникло множество новых систем и много споров об относительных достоинствах согласованности и доступности. Формулировка «2 из 3» всегда вводила в заблуждение, поскольку имела тенденцию чрезмерно упрощать противоречия между свойствами. Но сейчас такие тонкости имеют значение. CAP запрещает лишь крошечную часть проектного пространства: идеальная доступность и согласованность при наличии разделений, которые встречаются редко.

Привет, Хабр! Меня зовут Сергей Корнеев, и я хочу рассказать о том, как мы организовали сбор данных в компании “Россети”. На момент запуска проекта я работал в “Россети.Цифра” и руководил внедрением BI-платформы. Нам с командой удалось решить проблему ручного сбора данных на базе Visiology Smart Forms, и именно об этом я расскажу сегодня. 

Сеть Интернет по своей архитектуре допускает возможность прямого обмена трафиком между любыми узлами, но все же в большинстве сценариев используется асимметричный вариант использования с относительно небольшим количеством узлов, отдающих содержание (объединенных в 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, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).