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

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

Меня зовут Роман Литвинов, я разработчик в команде Учи.ру. Хочу вам рассказать именно о такой истории из практики и о нашем сервисе под названием 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.

Предыстория/Мотивация

Все началось с хобби в начале 2020 года — с очередной попытки написания эмулятора игрового сервера Lineage 2 "по новому". Перед этим шагом было несколько попыток распиливания монолита существующих решений на рынке по новым практикам разработки, но затея оказалась тщетной, ибо те монолиты, которые и по сей день существуют и участвуют в так называемом "продакшен-пиратстве", имеют сильную связанность компонентов и решения поставленных задач, сопоставимые с началом 2000х годов, когда сфера только начинала развиваться. А самое главное, что монолит не заточен на построение распределенной архитектуры и, как следствие, обладает низкой эффективностью.

Было принято решение взять часть бизнес-логики (основной составляющей обработки действий игрока) из допотопных проектов эмуляторов и создать современный/масштабируемый эмулятор игрового сервера Lineage 2 Prelude Of War.

Подготовка среды

В этом цикле статей речь идет о параллельном программировании с использованием MPI.

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

Автор: Сергей Лукьянчиков, инженер-консультант InterSystems

Что такое распределенный искусственный интеллект?

Попытки отыскать «железное» определение ничего не дали: видимо, понятие немного «обогнало время». Но можно попробовать разобрать семантически само понятие – тогда получится, что распределенный искусственный интеллект это тот же самый ИИ (см. наши попытки дать «прикладное» определение), только еще и разнесенный на несколько компьютеров, не объединенных в единый вычислительный кластер (ни по данным, ни по приложениям, ни по доступу к отдельным компьютерам в принципе). Т. е. в абсолюте, распределенный искусственный интеллект должен быть распределен так, чтобы ни с одного из участвующих в этом «распределении» компьютеров не было возможности получить прямой доступ ни к данным, ни к приложениям других компьютеров: единственной альтернативой становится передача фрагментов данных или скриптов приложений через «явные» сообщения. Любые отступления от этого абсолюта, по идее, приводят к возникновению «частично распределенного искусственного интеллекта» – например, данные распределены, а сервер приложений общий. Или наоборот. Так или иначе, мы получаем на выходе набор «федерированных» моделей (т. е. либо обученных каждая на своем источнике данных, либо обученных каждая своим алгоритмом, либо «и то и другое вместе»).

Сценарии распределенного ИИ «для масс»

Речь не пойдет о периферийных вычислениях, операторах конфиденциальных данных, поисковых запросах на мобильных телефонах и тому подобных увлекательных, но не самых (пока что) осознанно применяемых в широких кругах пользователей сценариях. Гораздо более «жизненным» может стать, например, следующий сценарий (детальную демонстрацию можно и нужно посмотреть здесь): на предприятии работает продуктивное AI/ML-решение, качество его работы должен систематически контролировать внешний дата-саентист (т.е. эксперт, не являющийся сотрудником предприятия). Предоставить дата-саентисту доступ к решению предприятие не может (по различным соображениям), но может отправлять ему выгрузку записей из той или иной таблицы по заданному расписанию или по наступлении определенного события (например, завершение очередного сеанса обучения одной или нескольких моделей решения). При этом предполагается, что дата-саентист владеет какой-нибудь версией AI/ML-механизмов, которые были интегрированы в продуктивное решение, работающее на предприятии – скорее всего, сам же дата-саентист эти механизмы и разрабатывает, занимается их усовершенствованием и адаптацией к конкретной задаче конкретного предприятия. Размещением этих механизмов в продуктивное решение, мониторингом их эксплуатации и прочими аспектами жизненного цикла занимается дата-инженер (является сотрудником предприятия).

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

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

Давайте немедленно упорядочим хаос и остановим скам. Текущая ситуация и международное право.

Взрыв интереса и рост рынка NFT токенов поднял на поверхность ключевые вопросы токенизации. Мы разработали юридически значимую модель создания NFT на основе Парижской Конвенции по охране промышленной собственности и нового инструмента Всемирной организации интеллектуальной собственности (ВОИС) при ООН. Данный метод имеет надгосударственный правовой статус и не требует дополнительной легализации в 177 странах мира. А еще это занимает всего 15 минут…