Нюансы проектирования распределенных систем
С 1 июня по 15 июля демонстрационный грузовик Eaton гастролирует по России с решениями компании в области эффективного и безопасного управления энергией. Маршрут охватывает 11 городов: Москва, Санкт-Петербург, Череповец, Псков, Великие Луки, Нижний Новгород, Казань, Набережные Челны, Уфа, Екатеринбург, Ростов-на-Дону.
Dfinity хочет заменить индустрию облачных вычислений своим децентрализованным интернет-компьютером и создать на его основе новое поколение мега-приложений.
До конференции по распределённым системам Hydra осталось менее трёх недель, программа уже готова, и пришло время рассказать о ней Хабру. Под катом — описания всех докладов, а для начала скажем общее:
Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах «повышенной ответственности» все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.
«Как быстро мы упремся в сетевой канал, который использует Kafka — через года два или раньше?»
Mina Protocol — это первый в мире криптовалютный протокол, сжатый до размера нескольких твитов, он всегда составляет 22кб. Революционная блокчейн-архитектура Mina использует доказательство с нулевым разглашением, что решает множество проблем нынешних блокчейнов (конфиденциальность данных, перегрузка сети, транзакционные издержки, простота использования и простота интеграции в традиционные сервисы).
Мы все так привыкли к облачной синхронизации Dropbox и совместному редактированию в Google Docs, что объединение результатов действий разных пользователей может казаться давно решённой проблемой. Но на самом деле в этом вопросе остаётся множество подводных камней, а работа над алгоритмами CRDT вовсю продолжается.
Один из людей, ведущих эту работу — Мартин Клеппманн (Martin Kleppmann): исследователь в Кембриджском университете и создатель популярной библиотеки Automerge. И на конференции Hydra он рассказывал о нескольких вещах, которые исследовал буквально в последнюю пару лет. Какие действия пользователя могут заставить Google Drive выдать «unknown error»? Почему в CRDT метаданные о работе над документом могут занимать в сто раз больше места, чем сам документ, и как с этим бороться? А у какой проблемы сейчас даже не существует известного решения?
Обо всём этом он поведал в докладе, а теперь мы сделали для Хабра текстовый перевод. Видео и перевод — под катом, далее повествование будет от лица спикера.
Обычно требования к аутентификации такие: нужно защитить информацию пользователей, обеспечить надежное шифрование учетных данных и легкий вход в систему. Со временем и ростом сервиса возникает необходимость переосмыслить механизмы аутентификации с учетом конкретной ситуации.
Меня зовут Роман Литвинов, я разработчик в команде Учи.ру. Хочу вам рассказать именно о такой истории из практики и о нашем сервисе под названием Butler, о «дворецком», через которого проходит каждый пользователь, прежде чем зайти на платформу.
Итак, овсянка, сэр.
Заслуженно распространена точка зрения, что типичный разработчик высокоуровневого прикладного ПО настолько свыкся с доступностью системных ресурсов и мягкостью требований реального времени, что ожидать от него оптимизации кода в угоду снижения ресурсоёмкости приложения можно лишь в крайних случаях, когда этого прямо требуют интересы бизнеса. Это и логично, ведь в задачах прикладной автоматизации самым дорогим ресурсом остаётся ресурс человеческий. Более того, снижение когнитивных затрат на возню с байтами оставляет внимание разработчика свободным для задач первоочередной важности, таких как обеспечение функциональной корректности программы.
Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.
На днях мне пришло сообщение от портала Госуслуги, с предложением поучаствовать в тестировании дистанционного электронного голосования (ДЭГ). Стало интересно, начал гуглить и поисковик сразу же выдал ссылку на хабровскую статью «Обзор системы дистанционного электронного голосования ЦИК РФ». Ознакомился…и…после прочтения, испытал противоречивые чувства, которые вылились в эту статью, созданную на базе идеи, описанной мной еще в 2018 году на сайте change.org.
Подобно продвижению среди искусных воинов доспеха, с полностью отсутствующей защитой от тяжелого металлического ботинка в задней части чуть пониже спины, я искренне не понимаю, как можно было всерьез пытаться продать систему-решето из упомянутой выше статьи хабровчанам.
Ведь, очевидно, что процессе проведения выборов возникает конфликт интересов между
• власть имущими, не желающими уступать дорогу другим
• теми, кто власти пока не имеет, но желает её получить
• теми, кто хорошо устроился при действующей власти и ничего менять не хочет.
• простыми гражданами, радеющих за принципы сменяемости власти и соблюдения своих избирательных прав.
И главная проблема любой избирательной системы – представители первой группы, потому что у власть имущих есть доступ к данным всех жителей страны, которые могут быть использованы для формирования потока фейковых бюллетеней. Есть огромный админ ресурс. Есть доступ к бюджетным деньгам. Под рукой имеется силовой аппарат и карманная судебная система.
Каким образом система, предложенная ЦИК-ом защищена от организатора выборов? Да, никак. И дочитав эту статью до конца, вы поймете почему.
Перевод статьи начального уровня в блоге проекта Textile от 12 декабря 2019 г.
В предыдущей статье мы начали с вопроса: «Как подойти к своему первому p2p-приложению?» После недолгих размышлений мы быстро пришли к выводу, что решение не полагаться на централизованный сервер и сосредоточиться на том, чтобы сделать приложение для равноправных узлов, сопряжено с множеством дополнительных сложностей. Две основные группы «проблем» - это состояние приложения и инфраструктурное разнообразие протоколов. К счастью, мы обнаружили, что нам не нужно изобретать велосипед, заново решая груду инфраструктурных задач - вместо того мы можем использовать великолепный сетевой p2p-стек: библиотеку libp2p.
В сегодняшнем посте мы пойдем немного дальше и представим «игрушечное» приложение, чтобы почувствовать, как на самом деле можно что-то разрабатывать с помощью libp2p, и, надеюсь, мотивировать вас создать собственное p2p-приложение. Серьезно, вы удивитесь, насколько это просто!
Приложение
Сразу оговоримся, наша программа нынче будет написана на языке Go, с использованием библиотеки go-libp2p. Если вы ещё не знакомы с этим языком, настоятельно рекомендуем ознакомиться. Он действительно хорош для приложений, имеющих дело с параллелизмом и сетевыми взаимодействиями (такими, как например, обработка множества p2p-соединений). Большинство библиотек IPFS/libp2p имеют свои базовые реализации, написанные на Go. Прекрасным введением в Go является тур на golang.org.
Итак, наша программка будет простым приложением для пинг-понга с некоторыми добавочными настройками, чтобы сделать её более интересной, в отличие от обычных безыскусных примеров. Вот некоторые особенности нашего приложения (не волнуйтесь, мы расскажем подробней об этих пунктах позже):
29 апреля в Санкт-Петербурге состоится первый открытый митап Почтовых технологий — цифровой «дочки» Почты России.
Почему «на набережной»? Дело в том, что мероприятие пройдёт в гибридном формате — первые 50 зарегистрировавшихся смогут бесплатно посетить его вживую в нашем питерском офисе на Аптекарской набережной. Для остальных будет доступна онлайн-трансляция.
29 апреля мы поговорим о DevOps. Как создавать отказоустойчивые приложения на базе Kubernetes? Своим опытом поделятся три эксперта из Почтатеха, Yandex.Cloud и IT-one.
Вы скажете - оксиморон! Позволю себе привести некоторые аргументы в защиту данного выражения.
Краткое вступление. Я часто занимаюсь поиском неисправностей в IT системах сложности от средней и выше. Ещё это иногда называют troubleshooting. Хотя иногда переходят на личности и даже обзывают бездельником. Перегрузи хост и дело сделано, говорят мне некоторые коллеги. Я поначалу удивлялся, как можно такое предложить, если на хосте крутится куча сервисов, иногда критических, если куча разработчиков родила массу процессов и хост является частью большой системы!? Потом перестал. И вот почему...
Всем привет! Меня зовут Виталий, я разработчик в компании Web3Tech. В этом посте я представлю основные концепции и конструкции платформы Spring Cloud Stream для поддержки и работы с брокерами сообщений Kafka, с полным циклом их контекстного unit-тестирования. Мы используем такую схему в своем проекте всероссийского электронного голосования на блокчейн-платформе Waves Enterprise.
Являясь частью группы проектов Spring Cloud, Spring Cloud Stream основан на Spring Boot и использует Spring Integration для обеспечения связи с брокерами сообщений. При этом он легко интегрируется с различными брокерами сообщений и требует минимальной конфигурацией для создания event-driven или message-driven микросервисов.
В одном из наших проектов используется Edge-модуль, работающий на широком наборе оборудования c процессором ARM, типа Raspberry Pi. Данное устройство используется для того, чтобы пересылать медиа-данные посредством зашифрованного канала на сервер.
Основная часть нагрузки, которую создает ПО, обрабатывающее эти медиа-данные, генерируется криптографическими функциями TLS, поскольку в прочем отношении это просто релей. В этой связи появился интерес оценить производительность процессоров перечисленных ниже платформ для того, чтобы понять их потенциальную емкость в количестве обрабатываемых источников медиа-данных.
МойОфис продолжает цикл публикаций (1, 2) о разработке корпоративной почтовой системы нового поколения Mailion, которая реализуется при грантовой поддержке РФРИТ. В состав Mailion входит объектное хранилище DOS; в предыдущей статье мы рассмотрели его общую архитектуру и ключевые оптимизации, повышающие экономическую эффективность хранения данных. Сегодня мы переходим к одной из самых сложных и увлекательных тем в области разработки баз данных — проблеме масштабирования.
1. Предыстория;
2. Суть ФЗ № 259 «О цифровых финансовых активах и цифровой валюте» (Далее – Закон о ЦФА);
3. Судебная практика;
4. Вопросы и предложения.
На сегодняшний день криптовалюта на слуху практически у каждого человека. О криптовалюте спорят, к ней по-разному относятся в разных странах. Например, в Индии совсем недавно подготовили законопроект, согласно которому владеть, выпускать, менять криптовалюту будет запрещено под угрозой уголовной ответственности, а в Японии криптовалюта является уже 100% платежным средством.
В настоящей статье мы рассмотрим правовое регулирование криптовалюты в России по состоянию на конец марта 2021 года.
Эта статья — реакция на другую статью Производительность главнее всего. Да, в интернете опять кто-то не прав. Однако я хочу несколько выйти за рамки обсуждаемой темы, чтобы дополнить и углубить рассмотрение важных аспектов.
Конечно, Кнут не нуждается в том, чтобы его кто-то защищал. В самом деле, кто такой Кнут, а кто такой я? Однако моя цель — не защита Кнута, а защита здравого смысла.
Оказывается, что контекст статьи очень важен. Поэтому приведу ссылку, чтобы читатель мог самостоятельно ознакомиться с оригиналом статьи: http://cowboyprogramming.com/files/p261-knuth.pdf
Итак, перед нами статья 1974 года Стенфордского Университета под названием “Структурное программирование с оператором GOTO” (здесь и далее перевод авторский). Меня еще не было, а статья уже была. Я подозреваю, как и многих из вас, читающих статью.
Перевод статьи начального уровня в блоге проекта Textile от 19 ноября 2019 г.
Первые шаги к созданию децентрализованного приложения могут быть трудными. Изменить привычный при разработке централизованных приложений образ мышления не легко, поскольку распределённый дизайн ломает большинство допущений, устоявшихся в наших мозгах (и программных инструментов, которые мы используем). Чтобы проиллюстрировать то, как наша команда представляет себе одноранговую коммуникацию, мы выпускаем серию из двух статей, посвященную стеку протоколов libp2p. В этой первой статье мы размышляем о некоторых сложностях, связанных с созданием децентрализованных приложений, и выясняем, как абстракция уровня сетевого протокола, такая как libp2p, может нам помочь. В следующей статье (которая скоро появится) мы будем использовать эти же концепции для создания простого примера, написанного на языке Go, чтобы понять, как различные компоненты, о которых мы здесь говорим, связаны друг с другом.
Стремительно нарастающая сложность
Внедрить распределённое (p2p) взаимодействие в какое бы то ни было приложение - задача не из простых. Попредставляйте лишь пару минут, как должно работать ваше творение - и всё начинает усложняться прямо на глазах. Рассмотрим две основные проблемы для p2p-приложений: состояние приложения и инфраструктура взаимодействия. Управление текущим состоянием системы не тривиально. Нет центрального органа, который бы его определял. Состояние системы - производное от состояний множества других узлов, которое имеет взрывную сложность в ненадежных сетях и сложных протоколах. Что касается инфраструктуры связи, ваше приложение должно взаимодействовать со многими равноправными узлами, поэтому вам придется столкнуться с изрядным количеством проблем.
Мы уже третий год проводим конференцию о параллельных и распределённых вычислениях. Hydra 2021 пройдёт в онлайне, и вот что интересно: онлайн-конференция ведь и сама является распределённой системой. У неё есть множество компонентов (это и люди, и оборудование), разбросанных по планете и действующих параллельно (у конференции сразу несколько треков).
А значит, неизбежны соответствующие проблемы вроде «связь отвалилась». Как с ними бороться? Тут нам помогает как раз инженерия распределённых систем.
Например, «избыточность» — это не только когда реплики данных пишутся в три дата-центра. Это ещё и когда у конференции есть одновременно спикеры, эксперты и ведущие. Такая схема с тремя ролями означает, что если связь с кем-то временно пропадёт, двое других заполнят паузу в эфире, не оставляя зрителей наедине с пустотой.
В общем, от «Гидры» можно ожидать неплохой отказоустойчивости (подробнее можно почитать здесь). А чего ещё ждать? Расписали под катом — и заодно приложили ссылку на доклады предыдущей Hydra.