Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Не забудьте пожалуйста поучаствовать в опросе.

Мы давно стремимся быть максимально открытыми и делиться опытом, пусть и не всегда идеальным. Это помогает не только находить узкие места у себя в разработке, но и пробовать что-то новое.

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

Разрабатывая различные приложения, использующие популярную библиотеку Castle Windsor для внедрения зависимостей и Apache Ignite.NET в качестве «ключика», который открывает дверь в «облачные» вычисления, я столкнулся с небольшим неудобством: у меня не было никакой возможности внедрить зависимость в сервис, запускаемый через так называемый Service Grid.

Причина по которой это происходит довольна банальна. Apache Ignite.NET сериализует сервис, отправляет его на один из доступных серверов, где он десериализуется и запускается. Так как этот процесс никаким образом не имеет понятия о Castle Windsor, мы получаем то, что получаем.

Для решения этой проблемы нам необходимо создать плагин для Apache Ignite.NET, который получит контейнер, отвечающий за внедрение зависимостей и предоставить возможность сервису обратиться к нему, для получения того или иного объекта.

Понятие IoT (Internet of Things) давно вошло в лексикон IT-шников. Хотя я и не нашел такого хаба, но надеюсь это скоро будет исправлено :)

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

Введение

Решил проанализировать статью, описывающую некоторые интересные детали потоковой обработки ровно один раз: exactly-once. Дело в том, что некоторые авторы очень странно понимают термины. Разбор статьи как раз позволит прояснить многие детали более глубже, т.к. выявление нелогичностей и странностей позволяет более полноценно прочувствовать понятия и смысл.

Приступим.

Анализ

Начинается все очень даже неплохо:

На последней встрече сообщества Apache Ignite в Москве я рассказывал про:

• Open source-сообщество;
• Власть и деньги в open source;
• Как стать контрибьютором и коммитером, и зачем это нужно.

Ограниченное время доклада не позволило привести больше примеров, поэтому расширенную версию выкладываю на Хабре. Всё изложенное основано на моем личном опыте и не является официальной позицией какой-либо компании или организации.

Недавний пост о том как мы в Сбербанк-Технологиях разрабатываем Open Source раскрыл множество интересных подробностей о подходах, стремлениях и идеологии.

Сегодня я хочу рассказать о том реальном вкладе, который наша команда вносит в Open Source.

Как считать хиты страницы google.com? А как хранить счётчик лайков очень популярных пользователей? В этой статье предлагается рассмотреть решение этих задач с помощью CRDT (Conflict-free Replicated Data Types, что по-русски переводится примерно как Бесконфликтные реплицированные типы данных), а в более общем случае — задачи синхронизации реплик в распределённой системе с несколькими ведущими узлами.

1. Что такое Micronaut

Micronaut — это фреймворк на JVM для построения легковесных модульных приложений. Он разработан компанией OCI, той же компанией, что подарила нам Grails. Micronaut это современный фреймворк, призванный сделать создание микросервисных приложений быстрым и простым.

Micronaut содержит возможности похожие на существующие фреймворки, такие как Spring, но в то же время он реализует некоторые новые идеи, которые являются его отличительными чертами. Вместе с поддержкой Java, Groovy и Kotlin он предлагает множество путей создания приложений.

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

Как это работает и что получилось — читай под катом.

Автоматическое разрешение конфликтов в среде с более, чем одним ведущим узлом (в данной статье под ведущим узлом понимается узел, который принимает запросы на изменение данных) – очень интересная область исследований. Существует несколько различных подходов и алгоритмов, в зависимости от области применения, и в данной статье будет рассмотрена технология Операциональных Преобразований (Operational Transformations, OT) для разрешения конфликтов в приложениях совместного редактирования, таких как Google Docs и Etherpad.

В мае вышла новая версия Apache Ignite — 2.5. В неё внесено множество изменений, с полным списком которых можно ознакомиться в Release Notes. А в этой статье мы рассмотрим ключевые новшества, на которые стоит обратить внимание.

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

Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.

Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.

Новый вариант топологии: звезда вокруг ZooKeeper

Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.

Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.

Один из главных трендов развития информационных технологий в последние 20 лет – перенос сложных вычислений с локального компьютера на удаленные серверы, которые соединены с ним через компьютерные сети. Начиналось всё с концепции «сетевого компьютера», которая затем переросла в облачные вычисления.

И вот после этой логичной технологической эволюции мы снова слышим разговоры о том, что часть вычислений лучше всё-таки переносить на локальные устройства. Речь идёт о так называемых периферийных вычислениях, или Edge Computing. Что это — дальнейшее развитие технологий или разворот назад?

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

Вместе с нашими друзьями из IBM приглашаем на митап, где подробно расскажем про HyperLedger Fabric. Ждём всех: разработчиков, архитекторов, инженеров и просто тех, кто хочет разобраться, как работает Fabric.

Увы, но ответ неоднозначный – и да, и нет. Выбрать-то, конечно, легко, но запутаться еще проще. Так вот, о том, как не запутаться, и пойдет речь.

ДГУ у вас или другое оборудование — универсального решения по дистанционному мониторингу и управлению, которое подходит всем, умеет все и стоит дешево, не существует. Ограничения есть всегда. Один вариант предлагает скудный набор функций, но за копейки, другой наоборот – требует высокой цены, но за большие возможности. А между ними будут бесчисленные вариации, сочетающие в себе функциональность и цену в разных пропорциях. И кажется, что можно легко потеряться в этом море решений. Хотя…



Но на самом деле все проще, ведь вариантов решений всего 3, и в них можно разобраться.

Привет Хабр! Предлагаю вашему вниманию перевод статьи «Do you need a Blockchain»

Часть 1 (Управление цепочками поставок)

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

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

Мы различаем публичные (permissionless) Bitcoin \ Ethereum, и частные (permissioned) Hyperledger \ Corda блокчейны и противопоставляем их свойства свойствам централизованно управляемых баз данных. мы покажем структурированную методику для определения оптимальных технических подходов при решении конкретных прикладных задач. мы проанализируем три случая — Управление цепями поставок (Supply Chain Management), межбанковские и международные платежи (Interbank and International Payments), и Децентрализованные автономные организации (Decentralized Autonomous Organizations).

Привет! Недавно я натолкнулся на довольно интересное описание архитектуры Pusher Channels и решил его перевести для вас. На мой взгляд, автор очень доступно описал подходы к построению высоконагруженной и масштабируемой архитектуры. Скорее всего, статья будет полезна новичкам, а также специалистам из смежных областей.

В офисе компании Pusher у нас висит небольшой счетчик с постоянно увеличивающейся цифрой. Он показывает количество доставленных сообщений за всё время существования Pusher Channels. В пятницу в 22:20 по UTC число увеличилось на один разряд и достигло 10.000.000.000.000. В нём 13 нулей — 10 трлн.

Вы можете подумать, что счётчик общего количества сообщений — бесполезная кичливая метрика. Но это число — ключевой индикатор успеха Pusher Channels, нашего продукта для коммуникации в режиме реального времени. Во-первых, данный счётчик отражает доверие, оказанное нам пользователями. Во-вторых, он измеряет масштабируемость нашей системы. Чтобы цифра увеличивалась, мы в Pusher должны сделать так, чтобы пользователи доверяли отправку сообщений нашему сервису, и мы должны быть уверены в том, что наша система способна обработать эти сообщения. Но что нам стоит доставить 10 трлн сообщений? Давайте посмотрим.

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

Начну с причины возникновения LLTR (Link Layer Topology Reveal).

У меня был один “велосипед” - синхронизатор больших файлов “на полной скорости сети”, способный за 3 часа целиком залить 120 GiB файл по Fast Ethernet (100 Мбит/с; 100BASE‑TX; дуплекс) на 1, 10, 30, или > 200 ПК. Это был очень полезный “велосипед”, т.к. скорость синхронизации файла почти не зависела от количества ПК, на которые нужно залить файл. Все бы хорошо, но он требует знания топологии сети для своей работы.

Можно продолжить цепочку дальше, но на этом я прервусь.

Существующие протоколы обнаружения топологии канального уровня (LLDP, LLTD, CDP, …) для своей работы требуют соответствующей поддержки их со стороны всех промежуточных узлов сети. То есть они требуют как минимум управляемых свитчей, которые бы поддерживали соответствующий протокол. На Хабре уже была статья, как используя эти протоколы, “определить топологию сети на уровнях 2/3 модели OSI”.

Но что же делать, если промежуточные узлы – простые неуправляемые свитчи?

Если интересно как это можно сделать, то добро пожаловать под кат. Обещаю наличие множества иллюстраций и примеров.

{ объем изображений: 924 KiB; текста: 69 KiB; смайликов: 9 шт. }

Аннотация

Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.

Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.

Введение

Разработчик распределенных систем проходит несколько стадий:

Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.

Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.

Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

Привет Хабр!

Меня зовут Алексей Солодкий, я PHP-разработчик в компании Badoo. И сегодня я поделюсь текстовой версией моего доклада для первого Badoo PHP Meetup. Видео этого и других докладов с митапа можно найти здесь.

Любая система, состоящая хотя бы из двух компонентов (а если у вас есть и PHP, и база данных, то это уже два компонента), сталкивается с целыми классами рисков во взаимодействии между этими компонентами.

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

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

Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.