• Выбрать мониторинг ДГУ легко!.. Или нет?

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

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



      Но на самом деле все проще, ведь вариантов решений всего 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 доставил уже 10.000.000.000.000 сообщений

      • Перевод

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


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



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

      Читать дальше →
    • LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?

      КДПВ: LLTR Часть 0 - пневмотранспорт из Футурамы


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


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


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


      Подробнее в статье про него:

      Ладно, а зачем понадобилось “гонять” 120 GiB файл по сети на такое количество ПК?

      Этим файлом был VHD с операционной системой, программами, и т.п. Файл создавался на мастер‑системе, а затем распространялся на все остальные ПК. VHD был не только способом доставки системы на конечные ПК, но и давал возможность восстановления исходного состояния системы при перезагрузке ПК. Подробнее в статье: “Заморозка системы: история перехода с EWF на dVHD”.



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


      Существующие протоколы обнаружения топологии канального уровня (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: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

        Читать дальше →
        • +23
        • 9,1k
        • 6
      • Безопасное взаимодействие в распределенных системах



          Привет Хабр!

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

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

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

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

          Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.
          Читать дальше →
          • +62
          • 9,8k
          • 1
        • The Messenger of Everything

            У всех существующих мессенджеров есть свои плюсы и минусы, но каждый из них тянет одеяло на свою сторону из-за несовместимости с другими – и от этого страдают пользователи.


            Единым стандартом мог бы стать XMPP, но он, в отличии от E-Mail, появился относительно поздно и не успел набрать достаточную аудиторию, чтобы корпорации не могли уже от него отказаться. Ведь там быстро поняли, что без удержания аудитории внутри собственной экосистемы много не заработать. Да и кроме того, надо признать, у XMPP было достаточно недостатков из-за обилия расширений, многие из которых, несмотря на свою важность, оставались в экспериментальном статусе, а какие-то и вовсе дублировали друг друга.


            Пожив в «новом дивном мире» десятка мессенджеров в смартфоне, и ощутив все недостатки такого положения дел, мы наконец готовы к чему-то новому.


            И да, нам нужен новый стандарт!

            Читать дальше →
          • Батареи, Гигафабрика, Northvolt и Siemens. Посторонним Т

            Достаточно незаметно для популярных новостях прошло подписание одного весьма любопытного соглашения.

            Шведский стартап Northvolt и немецкая корпорация Siemens в пятницу 25 мая подписали партнёрское соглашение. По нему мюнхенский концерн становится одним из инвесторов и поставщиком решений по автоматизации, управлению производственными процессами и cloud-окружения для шведского предприятия.
            Читать дальше →
          • MassTransit, Saga и RabbitMQ для реализации диспетчера процессов

              Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.


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


              Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.


              image

              Читать дальше →
            • Более глубокий взгляд на различные платформы смарт-контрактов

              Привет, Хабр! Представляю вашему вниманию перевод статьи "A Deeper Look at Different Smart Contract Platforms".

              Мы живем в эпоху смарт-контрактов. В то время как Биткоин показал нам, что платежная система может существовать в децентрализованной одноранговой сети, именно Эфириум открыл ящик Пандоры второго поколения блокчейн, и люди наконец увидели истинный потенциал распределенных приложений (Dapps) и смарт-контрактов.

              В этой статье мы рассмотрим одну из новых платформам смарт-контрактов Cardano и посмотрим, в чем ее отличие.

              Прежде чем мы это сделаем, давайте зададим себе вопрос.

              Что такое смарт-контракты?


              Смарт-контракты автоматизированные контракты. Они самоисполняются с конкретными инструкциями, написанными на языке программирования, которые выполняются при выполнении определенных условий.
              Читать дальше →

            Самое читаемое