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

В последнее время многие блокчейн-платформы для исполнения смарт-контрактов переключились на WASM — WebAssembly. Мы не стали исключением, и в последнем обновлении тоже добавили WebAssembly как альтернативу привычному Docker. В этом посте мы расскажем, для каких задач нам потребовался именно WASM, что мы достигли с ним на сегодня и как WASM отражается на производительности блокчейна.

Divide et impera (разделяй и властвуй) – древний принцип для управления чем-то большим и сложным.

Многие из нас программируют. Многие из нас делают системы, сложные системы. Но некоторым повезло работать в ситуации, когда объёмы по-настоящему огромны и требования кажутся невыполнимыми. Шардировние – один из излюбленных счастливчиками, которых зовут приключения, приемов.

Что-нибудь разбить на кусочки – это круто! Переходите на сторону шардирования у нас есть печеньки!

Работаете с распределенными системами или только пытаетесь к ним подобраться? Проектировать такие системы с нуля бывает сложно и страшно: чтобы учесть все нюансы, нужен определенный багаж знаний. 

На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.

Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.

Рассказываем, как использовать методы стеганографии и шифрования в децентрализованных сервисах на IPFS. Исключаем риски, связанные с централизованным хранением логинов и паролей. Используем метод LSB, «наименьший значащий бит». Внутри статьи — примеры кода на C# и алгоритме AES для шифрования и расшифровки. 

Jesse Anderson, директор Big Data Institute, и Martin Kleppmann, автор книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка», вместе исследуют меняющийся ландшафт обработки данных. Они начинают с истории создания книги Мартина, подчеркивая важность искусства задавать правильные вопросы. Мартин рассказывает об изменениях, произошедших в отрасли с 2017 года, подчеркивая рост облачных сервисов. Затем беседа приобретает новый поворот, когда Мартин погружается в академические круги, делясь своими соображениями о программном обеспечении для совместной работы на основе локального подхода и увлекательном мире Automerge. Начинающие инженеры‑программисты получат несколько советов о том, как найти тонкий баланс между простотой и гибкостью. В завершение обсуждают о различных карьерных путях в динамичной сфере инженерии данных, что делает разговор полезным для профессионалов на любом этапе их пути.

28 июля 2015 г.

11 марта 2013 года Биткоин пережил технический кризис. Версии 0.7 и 0.8 программного обеспечения отличались друг от друга в поведении из-за ошибки, что привело к разделению цепочки блоков. Учитывая, насколько катастрофичным может быть хардфорк, кризис был быстро разрешен с удивительно малым ущербом благодаря исключительной компетентности ответственных разработчиков.

Привет всем, на связи снова Александр Бобряков, техлид в команде МТС Аналитики. Продолжаем цикл статей про фреймворк Apache Flink.

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

Начиная с этой статьи начнём разбирать, как тестировать всё наше приложение Flink + Spring. Многие описанные подходы вполне применимы и в любом другом обычном Spring-приложении, поэтому, надеюсь, вы найдёте для себя что-то новое.

В данной статье мы рассмотрим, как протестировать stateless- и stateful-операторы Flink с помощью абстракций TestHarness.

Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.

Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).

Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.

Привет! Меня зовут Александр Попов, я tech lead команды маркетплейса 05.ru. Сейчас мы занимаемся бэком маркетплейса и некоторыми другими сервисами на рынке Дагестана. 

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

Привет, Хабр! На связи Николай, главный редактор Web3 Tech. Как можно предположить по должности, опыта в разработке я почти не имею. Год назад закончил мини-курс по Python, сделал об этом пост и с тех пор код не писал. Но недавно набрался смелости, заручился посильной поддержкой коллег и решил создать, пусть и локальную, но все же свою блокчейн-сеть!

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

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

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

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.

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

Всем привет, меня зовут Александр Бобряков. Я техлид в команде МТС Аналитики, занимаюсь Real-Time обработкой данных. Мы начали использовать фреймворк Apache Flink, и я решил поделиться на Хабре своим опытом внедрения этой технологии в цикле статей.

В предыдущей статье — «Apache Flink. Как работает дедупликация данных в потоке Kafka-to-Kafka?» — я рассказывал про построение пайплайна Kafka-to-Kafka с промежуточным разделением потока и дедупликацией событий. Также разобрались, что такое состояние оператора и зачем оно нужно.

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

Когда-то файлы хранили на дискетах, потом на дисках, потом на флэшках. Закончилось всё облаками. Тогда встал ряд различных вопросов по надёжности и приватности. С одной стороны можно просто доверить файлы гуглу или яндексу, но тогда о приватности можно забыть. C другой стороны можно завести собственное облачное хранилище, будь то дорогое железное решение от Synology, или оперсорсное на арендованной vps на nextcloud, но тут требуется вовлечение, что бы облако оставалось в рабочем состоянии (следить за апдейтами, своевременно обновлять оборудование, поддерживать резервное железо). Вместе с развитием блокчейна и развитием децентрализованных технологий web 3.0, появились и облачные хранилища, обещающие приватность, доступность и низкую цену. Предлагаю к рассмотрению 2 проекта, которые появились более 10 лет назад, и до сих пор существуют - Filecoin и Storj.

Эта публикация является развитием идей, сформулированных в предыдущей статье - "Идентификация пользователей в Web 3.0". После предыдущей публикации я понял, что в массах нет однозначного определения, что же именно называть Web 3.0 - виртуальную реальность, интернет вещей или децентрализацию на базе блокчейна. С моей точки зрения, Web 3.0 - это архитектура веб-приложений, обусловленная спросом пользователей на конфиденциальность их собственных данных.

Развитие идей Web 2.0 привело к тому, что пользователи сами стали товаром. Вернее, товаром стала информация об их связях и предпочтениях, которую собирают и монетизируют корпорации типа Google и Facebook. В ответ на это у многих пользователей появилось желание не делиться своими персональными данными с корпорациями, а хранить свои данные в недоступном для корпораций месте. Размышлениям о том, к каким последствиям может привести персонализация хранимых данных, и посвящена данная публикация. Сразу предупреждаю - это просто моё растекание мыслью по древу, а не "сборник рецептов" или разъяснения "как всё устроено". Не очаровывайтесь, чтобы не разочароваться :)

В посте про историю развития смарт-контрактов целый раздел мы посвятили такому понятию, как конфиденциальные смарт-контракты. У блокчейна есть целый ряд преимуществ, которые делают его привлекательных для реализации конфиденциальных систем. Но данные смарт-контрактов, формирующих бизнес-логику блокчейна, по умолчанию хранятся в открытом виде и доступны для всех. Этот конфликт решают конфиденциальные смарт-контракты (КСК) — они стали для нас одной из основных фичей платформы, запланированных на 2023 год, и успешно дошли до релиза. Далее мы раскроем подробности реализации КСК и приведем пример контракта, который вы легко сможете развернуть на оpen-source инстансе нашей сети.