Что-то нормальное в эту сумму попасть не могло, в принципе, поэтому оставались варианты вроде «DIR-320+openwrt+UVC камера из ноутбука» запаянные в герметичный полиэтиленовый пакет и подвешенные на дерево. Но как-то вечером я просматривая объявления местной барахолки натолкнулся на продажу IP-камеры D-link DCS-5220A1, да еще и функцией PTZ за какие-то смешные 10$. Для тех, кто не в курсе, приведу выдержку из википедии

Pan-tilt-zoom-камера (PTZ-камера) — камера, которая поддерживает удалённое управление направлением и зумом. PTZ — это аббревиатура от панорамирования, наклона и зума (pan, tilt, zoom), которая описывает возможности управления камерой.

Да, насторожился. Но жаба пересилила, а ей вторила самоуверенность («да неужели не разберемся?!»). Камера оказалась старой, но с отличным светочувствительным сенсором (как-раз то что нужно, чтобы наблюдать ситуацию вечером). Решено и камера у меня на столе.

Сначала [+]:

1. Шикарная ночная чувствительность (без всяких ИК-подсветок) — 0.5 Lux @ f1.4
2. PTZ (хотя зум только цифровой)
3. WiFi реализовано картой miniPCI RT2560F. На aliexpress можно найти уже 802.11n (например AR9160, заменить и гнать видеопоток в максимальном качестве (камера поддерживает mpeg4 и H.263)
4. Поддержка вещания по RTSP, HTTP и т.д.
5. Поддержка UPnP
6. Золота на плату не жалели, слой на всех контактах капитальный.
7. На борту свой веб-сервер. И система на базе linux, т.к. выложены даже какие-то исходники. Правда, ни по SSH, ни по telnet достучаться изначально не удалось.

Потом замеченные [-]:

1. Максимум разрешения — это 640х480. Камера, как видно адская (сразу думал что вообще подключена по lvds, уж очень похож разъем.
2. Сложности с первичным подключением. Камера подключается к компу _только через хаб_ или кабелем кроссовером. И неизвестно какой IP адрес.

Стоит сразу отметить, что в интернете по поводу именно моей модели информации было мизерное количество — страничка на сайте d-link и все. Поэтому я решил первым делом вскрыть корпус, благо держалось все на трех винтах. Кстати, милым мне показалось наличие на нижней части корпуса стандартного крепления для фотоштатива (1/4"). В общем после снятия крышки я увидел вот такую картину:

Картинки с подписями элементов

Фотографии с авторскими пометками, это дает о себе знать прошлое в мастерской по ремонту сотовых. Все время делаешь себе cолюшены на случай прихода аналогичной модели :). Вдоволь посмотрев на плату, я собрал все обратно и решил посмотреть как камера будет работать с родным ПО (благо с сервера d-link удалось скачать какие-то огромные пакеты).

Несмотря на внимательно изучение сначала русского, потом и английского мануала, мне так и не стало ясно, как обнаружить камеру. Пришлось искать на антресолях старый хаб, подключать к нему камеру, устанавливать wireshark и слушать ethernet. Прослушивание дало ip-адрес «192.168.0.99». Забив его в ручные настройки программы d-link Network Camera Installation, камера подхватилась. Для работы с подобными камера предназначена другая утилита от d-link D-ViewCam. В ней также пришлось вводить адрес вручную, камера обнаружилась и я даже смог проверить работу PTZ. Камера действительно неплохо управляется и ездит вправо-влево/вверх-вниз с разрешением «один зубчик передаточной шестеренки» :). Правда постоянно щелкать мышкой немного утомляет.

Погуглив, я нашел документ "URL command for DCS-5220, DCS-2120", где написано, что можно управлять камерой командой: http:///cgi-bin/camctrl.cgi? [move=][&speedpan=][&speedtilt=], где value = up/down/left/right/home+ -5 — для шага в один зубчик шестеренки привода.
В принципе, вроде как должно было бы быть все, но червь сомнения не давал покоя. unix же на борту, ну какой веб-интерфейс. Посмотрев камеры-аналоги и почитав forum.openwrt.org была найдена уязвимость, позволяющая веб-запросом включить в камере телнет. Все что для этого было нужно, так это написать в строке браузера

http://<адрес камеры>/cgi/admin/telnetd.cgi?command=on

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

http://<адрес камеры>/cgi/admin/telnetd.cgi?command=off

В чистом итоге, телнет-сессия дала гораздо больше ответов, чем все официальные сайты (и даже официальный канал Телеграм 🙂 ) вместе взятые. Ниже информация об аппаратных особенностях данной камеры, собранная через telnet и консоль UART:):

На заметку/напоминание всем кто решится повторять подобные эксперименты — к выходу UART подключайтесь через преобразователь уровней (у меня это был FTDI232).

Внимательно проанализировав консольные логи загрузки, стало примерно ясно, что ядро напрямую распаковывается в оперативную память. Теоретически, на сайте можно найти GPL прошивки если не для всех, то по крайней мере, для многих продуктов d-link. Но именно для моей модели cкачать последнюю прошивку не удалось. Ладно, взял первую попавшуюся (файл *.pkg) и скормил ее binwalk.

Получилось следующее:

$binwalk DCS-5220_A2_v1.05.pkg
DECIMAL HEXADECIMAL DESCRIPTION
__________________________________________
54_0x36_uImage header, OS Kernel Image, compression type: none, image name: "linux-2.4.26"
11770 _0x2DFA _gzip compressed data, maximum compression,
897238_0xDB0D6_gzip compressed data, maximum compression, file name: "initrd.img"
2935070_0x2CC91E_gzip compressed data

Перед тем, как заниматься дальнейшими изысканиями, по диагонали посмотрел есть ли какие-то упоминания о разборке и/или пересборке прошивок для таких камер. Натолкнулся на ресурс Firmware unpackers for IP cameras, где собраны скрипты для распаковки прошивок IP-камер D-Link и аналогичных им по железной начинке камер Trendnet. К сожалению, моей модели там в наличии не было. На всякий случай попробовал написать автору. К моему удивлению, последний ответил, и подтвердил информацию выданную binwalk — внутри прошивки простые архивы. Запуск binwalk с ключом -e дал следующую картину:

Простенькие TAR архивы легко извлекаются командой tar -xvf. Содержимое там следующее:

Так как внутри — ничего интересного не обнаружилось, было решено лезть внутрь initrd.img . Для анализа достаточно просто смонтировать образ командой:

$ sudo mount -o loop initrd.img /home/imagefile/

Внутри стандартный набор, готовый к редактированию любознательным исследователем 🙂

$ ls
bin dev drivers etc home lib linuxrc lost+found mnt proc root sbin tmp usr var

Попутно я установил, что прошивки для камеры 5220 ревизии A1 и ревизии A2 идентичны и полностью взаимозаменяемы. А вот прошивки от ревизии B к камерам с аппаратным обеспечением ревизии А категорически не подходят.

В общем, теоретически подогнать прошивку под свои нужды не составляет труда. Так же, как и добавить необходимый драйвер (при замене miniPCI карты например). Прошить камеру можно через стандартный интерфейс программы D-ViewCam или Installation Wizard (о которых я говорил в самом начале).

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

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

Примечание: изначально, являясь ярым поклонником openwrt, признаюсь, что внутрь камеры полез для того, чтобы выяснить можно ли туда установить openwrt. Ответ — можно, сетевой функционал сохраниться, но полностью пропадет PTZ-функционал. Поэтому — лучше модифицировать существующие прошивки. Но тему на форуме openwrt.org я сохранил, и туда же выкладываю все новое, что удается узнать об d-link DCS-5220.

На этой неделе исполнительный директор Международного энергетического агентства рассказал о прогнозе специалистов организации на Global Wind Summit. Согласно прогнозу, ветер к 2027 году станет основным источником энергии в Европе.

В настоящий момент примерно четверть энергии, которую получают европейские страны, поступает из АЭС, и еще 20% поставляют ТЭС, работающие на каменном угле и газе. Что касается ветра, то этот источник поставляет всего лишь 10% энергии от общего ее объема, потребляемого в странах Европы.

Но к 2027 расклад существенно изменится. 23% энергии будет генерироваться при помощи ветроэлектростанций, предприятия по выработке биогаза станут производить объемы этого источника энергии, которые позволят генерировать около 20% энергии от общего объема. Еще 20% будет вырабатываться на ТЭС, где будут продолжать жечь метан, 20% предоставят АЭС и еще 10% — «грязные» ТЭС на каменном угле. Что касается солнечной энергии, то ее доля возрастет примерно до 6-7%.

Ветер станет играть такую важную роль потому, что он является одним из самых доступных ресурсов, особенно на побережье. Евросоюз имеет отличную возможность получать «зеленую» энергию, постепенно отказываясь от загрязняющих природу источников. В 2017 году в Европе вырабатывалось около 15,78 МВт энергии при помощи ветроэлектростанций. Если верить прогнозам, то к 2040 году этот показатель возрастет до 200 МВт.

Пока что, правда, неясно, как на общей картине скажется выход Великобритании из Евросоюза (если он, конечно, все же состоится). Дело в том, что сейчас Великобритания предсталяет собой одного из главных поставщиков «зеленой» энергии в Евроюз. Кроме того, ряд амбициозных проектов планируют начать реализовывать в Северном море.

Кроме электричества, страны Европы смогут вырабатывать и большое количество водорода, который нужен для промышленности. Для его получения необходимо большое количество электричества, при помощи которого осуществляется электролиз воды. Если энергии будет действительно много (имеется в виду зеленая энергия), и она станет дешеветь, то водород можно будет получать чуть ли не в неограниченном количестве.

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

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

Проблемы «зеленой» энергетики, в частности, ветро- и солнечной, в том, что некоторые страны не имеют достаточного количества ветра или уровня инсоляции. Кроме того, в ряде регионов случаются продолжительные периоды, когда ветра или солнца практически нет. Все это приводит к тому, что делать упор на «зеленую» энергию пока нельзя, поскольку энергетическая инфраструктура должна быть равномерно загружена. Если же делать основной упор на ветер и солнечную энергию, придется позаботиться о стабильности работы инфраструктуры в то время, когда ветер стихает, а солнце часто скрывается за облаками либо же продолжительность светового дня сильно падает.

Как бы там ни было, но человечество уже создало технологии, которые позволяют бороться с изменениями в поступлении энергии и изменении потребления. Есть различные способы решить проблему, которые постепенно реализуются. В Австралии, например, построили огромную аккумуляторную станцию, которая уже сэкономила правительству государства многие миллионы долларов США.

/ libreshot / PD

Типы архитектур ПО

Многоуровневая архитектура

Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI.

Система делится на уровни, каждый из которых взаимодействует лишь с двумя соседними. Поэтому запросы к БД, которая обычно располагается в самом конце цепочки взаимодействия, проходят последовательно сквозь каждый «слой».

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

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

Плюсы:

Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает о том, как устроены остальные уровни. Поэтому «содержимое» уровней можно изменять без риска глобальных конфликтов между слоями.

В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов. Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения.

Недостатки:

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

Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.

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

Хорошо подходит:

• Для создания новых приложений, которые нужно развернуть по-быстрому. Это своеобразный «шаблон общего назначения».
  

  Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).

  Среди разработчиков есть мнение, что не нужно с первых же дней проекта готовить его к колоссальным нагрузкам (писать future proof программное обеспечение). Реальные требования к приложению или сервису могут отличаться от ожидаемых, а бизнес-цели могут измениться. Потому код, написанный с прицелом на далекое будущее, рискует превратиться в технический долг.

• Как пишет O’Reilly, многоуровневая архитектура — естественный выбор для многих корпоративных приложений. Так как в компаниях (особенно крупных) часто происходит разделение компетенций: есть команда, ответственная за фронтенд, есть люди, которые отвечают за бэкенд, и так далее. Отсюда вытекает естественное деление приложений на уровни: одни разработчики трудятся над клиентом, другие — над логикой.

  Подобная взаимосвязь, между структурой организации и подходами к разработке приложений также продиктована законом Конвея, сформулированном еще в 1967 году. Он гласит: «Разрабатывая какую-либо систему, организации вынуждены придерживаться схемы, которая бы повторяла структуру коммуникаций внутри компании».

Событийно-ориентированная архитектура

В этом случае разработчик прописывает для программы поведение (реакции) при возникновении каких-либо событий. Событием в системе считается существенное изменение её состояния.

Можно провести аналогию с покупкой автомобиля в салоне. Когда автомобиль находит нового владельца, его состояние меняется с «продается» на «продано». Это событие запускает процесс предпродажной подготовки — установку дополнительного оборудования, проверку технического состояния, мойку и др.

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

Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать.

На Wiki приводится следующий код реализации этого механизма:



public class FooPanel extends JPanel implements ActionListener {   public FooPanel() {     super();      JButton btn = new JButton("Click Me!");     btn.addActionListener(this);      this.add(btn);   }    @Override   public void actionPerformed(ActionEvent ae) {     System.out.println("Button has been clicked!");   } } 



Достоинства архитектуры:

Так как приложения состоят из большого количества асинхронных модулей (у которых нет информации о реализации друг друга), их легко масштабировать. Такие системы собираются как конструктор — прописывать зависимости не нужно, достаточно реализовать новый модуль. Дополнительно асинхронная модель позволяет добиться высокой производительности приложений.

Недостатки:

Асинхронная натура таких приложений усложняет отладку. Одно событие может запускать сразу несколько цепочек действий. Если таких цепочек будет много, то понять, что именно вызвало сбой, может быть затруднительно. Для решения проблемы приходится прорабатывать сложные условия обработки ошибок. Отсюда же вытекает проблема с журналированием — логи трудно структурировать.

Подходит для:

• Создания асинхронных систем. Это очевидно, поскольку сама архитектура состоит из большого количества асинхронных модулей.
• Можно применить для создания UI. Веб-страница выступает в роли контейнера, в котором каждый её компонент изолирован и реагирует на определённые действия пользователя.
• Для организации обмена сообщениями между различными информационными системами.

Микроядерная архитектура

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

Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.

Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году). В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов.

Достоинства архитектуры:

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

Недостатки:

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

Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.

Хорошо подходит для:

• Создания расширяемых приложений, которыми пользуется большое количество людей. Например, ОС для iPhone имеет «микроядерные» корни — её разработчики черпали вдохновение в Mach (это один из самых первых примеров микроядра).
• Создания приложений с четким разделением базовых методов и высокоуровневых правил.
• Разработки систем с динамически меняющимся набором правил, которые приходится часто обновлять.

Микросервисы

Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).

В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели. По его словам, это позволит избежать излишнего «раздувания» архитектуры.

Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.

Достоинства:

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

Подробнее о механизмах масштабирования микросервисных систем можно почитать в книге Мартина Эббота (Martin L. Abbott) «Искусство масштабирования» (The Art of Scalability).

Недостатки:

Сложно искать ошибки. В отличие от монолитных систем (когда все функции находятся в одном ядре), бывает сложно определить, почему «упал» запрос. За деталями приходится идти в логи «виновного» процесса (если их несколько, то проблема усугубляется).

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

Еще один недостаток — необходимость мириться с концепцией eventual consistency (согласованность в конечном счёте). У микросервисов есть собственные хранилища данных, к которым обращаются другие микросервисы. Информация об изменении этих данных распространяется по системе не мгновенно. Потому возникают ситуации, когда у некоторых микросервисов (пусть и на крайне короткий промежуток времени) оказываются устаревшие данные.

Где использовать:

• В крупных проектах с высокой нагрузкой. Например, микросервисы используются стриминговыми платформами. Системы доставки контента и иные вспомогательные сервисы можно масштабировать независимо друг от друга, подстраиваясь под изменения нагрузки.
• В системах, использующих «разномастные» ресурсы. Если одной части приложения нужно больше процессорного времени, а второй — памяти, то имеет смысл разделить их на микросервисы. После чего их можно захостить на разных машинах — с мощным CPU или большим объемом памяти соответственно.
• Когда нужна безопасность. Так как микросервисы изолированы и общаются по API, можно гарантировать, что передаваться будет только та информация, которая нужна тому или иному сервису. Это важно при работе с паролями или данными платёжных карт.

Почему мы в 1cloud переходим на микросервисы

Как мы уже говорили, в основе предоставляемых нами сервисов (частное облако, виртуальные серверы, объектное облачное хранилище и др.) лежит многоуровневая архитектура. Она показала себя с хорошей стороны, но теперь её возможности по масштабированию начали иссякать.

У нас становится все больше партнеров, которые предоставляют свои решения на базе нашей платформы по франшизе. Появляются удаленные площадки и сервисы, которыми становится сложно управлять из единой точки (в частности, наше оборудование находится в нескольких дата-центрах в России, Казахстане и Беларуси).

Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.

Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД. Это гораздо удобнее и эффективнее в поддержке и разработке.

Мы сможем разделить работу над сервисами между несколькими разработчиками (выделить специализации в компании) и эффективно масштабироваться горизонтально — когда нужно, будем просто подключать новые микросервисы.

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

Клиенты из Казахстана и Беларуси (и других стран, где мы откроем представительства) заметят существенное увеличение скорости и отзывчивости интерфейсов, так как панели управления будут размещаться локально.

Что уже сделано

Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.

При этом новая архитектура закладывает технологическую основу для следующего этапа — миграции на контейнеры. Сейчас мы используем Windows-инфраструктуру, и для перехода в контейнеры нужно переписать весь накопившийся код на .NetCore и перевести его под управление Linux.

Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.

Что стоит запомнить про архитектуры

• Многоуровневая архитектура — приложение делится на уровни, каждый из которых выполняет строго определенный набор функций. Каждый уровень можно модифицировать по отдельности. Из недостатков — низкая скорость работы кода и сложность поиска багов.

  Подходит для разработки приложений, которые нужно оперативно вывести на рынок. Часто используется для создания корпоративных сервисов.

• Событийно-ориентированная архитектура — здесь разработчик прописывает реакции системы на какие-либо события. Например, если поступили данные, записать их в файл. Приложения на базе событийно-ориентированной архитектуры просто масштабировать, так как все обработчики событий ничего не знают о реализации друг друга. Однако отладка таких систем затруднена — одно действие может вызывать сразу несколько цепочек действий (сложно понять, какая из них вызвала сбой).

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

• Микроядерная архитектура — состоит из двух ключевых компонентов: плагинов и ядра. Плагины отвечают за бизнес-логику, а ядро — за их загрузку и выгрузку. Такое разделение обязанностей упрощает поддержку системы. Однако может сказаться на производительности — она напрямую зависит от количества подключенных и активных модулей.

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

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

  Используют в крупных проектах с высокой нагрузкой, которым требуется повышенная безопасность.

О чем еще мы пишем в блоге 1cloud:

• Эволюция архитектуры облака 1cloud: сложности модулирования
• Как IaaS помогает франчайзи «1С»: опыт 1cloud
• Зачем нужен мониторинг?

/ фото Wikimedia PD

Кратко о парадоксе Максвелла

Демон Максвелла — вымышленное существо, которое в XIX веке придумал физик Джеймс Клерк Максвелл, чтобы описать парадокс второго закона термодинамики.

Максвелл предложил следующий мысленный эксперимент. Берется емкость и делится перегородкой на две половины. Затем ее заполняют условно «холодными» и «горячими» молекулами газа. Эти молекулы перемешаны и перемещаются с разными скоростями.

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

Парадокс в том, что после того как молекулы «займут свои места» в емкости, энтропия системы оказывается больше, чем в своем изначальном состоянии. Это нарушает второй закон термодинамики, согласно которому энтропия изолированной системы не может уменьшаться, а лишь возрастать или оставаться прежней.

Сперва физики решили, что демона Максвелла можно отождествить с вечным двигателем, так как он берет энергию «из ниоткуда». Но потом было доказано, что демон тоже тратит энергию на сортировку молекул. Значит, энергия возникает из работы демона, и законы термодинамики не нарушаются. Парадокс разрешил Лео Силард в 1929 году.

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

Три года назад демона Максвелла удалось реализовать в виде одноэлектронного транзистора со сверхпроводящими алюминиевыми выводами. Однако воплотить концепцию в жизнь со значительным количеством атомов или молекул ученым не удавалось. До недавнего времени.

Квантовый демон: в чем суть

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

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

В рамках эксперимента исследователи использовали лазеры с длиной волны в 839 нм, чтобы сформировать оптическую 3D-решетку размером 5х5х5 и поместить в нее атомы цезия. Изначально эти атомы находились в состоянии с орбитальным квантовым числом (l) равным 4 и магнитным квантовым числом (m) равным −4 и распределялись по решетке случайным образом. Однако по окончании эксперимента они формировали подрешетки размером 5x5x2 или 4x4x3, что уменьшало энтропию системы более чем в два раза.

Чтобы перемещать атом по решетке, ученые меняли его состояние (изменяя его квантовые числа) и переключали поляризацию одного из световых пучков. В результате атомы, находящиеся в разных состояниях, начинали «отталкиваться» и перемещаться по решетке. Когда нужно было «зафиксировать» положение атома, его квантовые числа возвращались в исходное состояние.

Чем полезна разработка

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

Уменьшение энтропии в оптической ловушке атомов позволяет строить квантовые вентили с меньшим количеством ошибок. А квантовые вентили считаются базовыми логическими элементами квантового компьютера. Потому предложенная система позволяет в перспективе повысить вычислительную эффективность квантовой машины.

Другая технология — телепортация квантового вентиля

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

/ фото Rachel Johnson CC

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

Исследователи телепортировали логический вентиль CNOT (контролируемое отрицание), который реализует операцию, похожую на «сложение по модулю 2». С учетом кодов корректировки ошибок надёжность метода составила 79%.

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

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

P.S. Дополнительные материалы из Первого блога о корпоративном IaaS:

• «Как дела у VMware»: обзор новых решений
• Как разместить 100% инфраструктуры в облаке IaaS-провайдера и не пожалеть об этом
• Как протестировать дисковую систему в облаке
• 9 полезных советов для плавного перехода в облако

P.P.S. Статьи по теме из нашего блога на Хабре:

• Шаг к квантовому превосходству: 49-кубитный квантовый компьютер от Intel
• Создан первый молекулярный компьютер на синтетических полимерах

Корпорация Microsoft уже во второй раз объявляет о прекращении поддержки десктопной версии Skype (7.0). В первый раз компания сообщала о том, что мессенджер старой версии прекратит работу в сентябре. Но затем, после того, как сотни тысяч человек попросили этого не делать, дату перенесли.

Правда, ненадолго — сейчас компания уведомила пользователей Skype о том, что для классической версии все закончится 1 ноября. Ну а с 15-го ноября корпорация прекратит поддержку аналогичной версии для мобильных устройств и планшетов.

Похоже на то, что сделать уже ничего нельзя, хотя один из пользователей десктопной версии запустил сбор подписей в поддержку идеи оставить программу в живых хотя бы для «профессиональных» пользователей. На данный момент собрано около 1200 подписей.

В своем блоге редмондская корпорация заявила, что продолжает работу над наиболее важными и востребованными функциями мессенджера. «Недавно мы добавили запись звонков, сейчас понемногу дорабатываем функцию поиска в рамках диалога. Еще какое-то время спустя вы сможете добавлять номера телефонов к существующим контактам, а также получите немного больше инструментов контроля, включая статус», — заявляют разработчики Skype.

Восьмая версия Skype была представлена в 2017 году. Тогда сервис получил новые функции, включая аналог «Историй», от которого через время было решено избавиться. Разработчики провели и редизайн приложения по просьбе пользователей. В частности, кнопки вызова списка контактов, звонка и сообщений опущены в нижнюю часть дисплея, что позволяет получить быстрый доступ к этим двум функциям. С мобильной версией поступили аналогичным образом.