Русский
Русский
English
Статистика
Реклама

Сервисная архитектура

Концепция независимой инфраструктуры для IIoT системы на основе mesh cети

10.12.2020 22:22:03 | Автор: admin

Добрый день,

Меня зовут Алексей Бабушкин. Я СЕО независимого дизайн хауса электроники Hi-tech nation. Мы занимаемся контрактной разработкой продуктов в области интернета вещей. В свободное от работы время пилим свои решения с использованием беспроводной передачи данных и тестируем продуктовые гипотезы. Так родилась концепция независимой инфраструктуры для IIoT систем на основе mesh сети, которой я хочу с вами поделиться.

Начнём с теории

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

Типовая архитектура таких систем состоит из следующих 3-х уровней:

- оконечные периферийные устройства (датчики, контроллеры, исполнительные устройства и пр.). Этот уровень отвечает за сбор информации с устройств и за приведение её к стандартному виду, фильтрацию и локальное хранение;

- сетевые шлюзы (роутеры, gateway станции и пр.). Они создают инфраструктуру для управления и обмена данными между устройствами посредством проводных или беспроводных протоколов (RS-485, Modbus, CAN, BLE, Wi-Fi, ZigBee, LoRa, и пр.). На этом уровне происходит предварительная обработка информации, выстраивается коммуникация с верхнем уровнем и предоставляется возможность настройки и управления через веб-приложения;

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

Теперь немного глубже

На старте формирования нашей концепции мы решили проанализировать все три уровня и выделить их слабые стороны.

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

Слабые стороны второго уровня связаны, в первую очередь, с набирающим обороты переходом на беспроводную передачу данных. Радиоэфир становится все более перегруженным, поскольку большинство нелицензированных беспроводных технологий основаны на частоте 2,4 ГГц. Вскоре это станет одним из самых ограниченных ресурсов. Также стоит отметить неблагоприятную среду, в условиях реально работающих промышленных объектов, в которой приходится функционировать IIoT (большое количество металлоконструкций, высокочастотные помехи от работы производственного оборудования, Wi-Fi сети и пр.). Все эти факторы в совокупности могут привести к снижению качества работы IIoT системы или даже к полной остановке её работы. Чтобы избежать проблем со связью в будущем, современные беспроводные решения должны уметь сосуществовать с другими беспроводными технологиями, поддерживать динамическую смену каналов и работать на других частотах, например, 433 или 868 МГц.

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

Слабые стороны третьего уровня связаны в первую очередь с недостатками облачных решений. К таким можно отнести вопросы безопасности. Согласно исследованию Crowd Research, проведенному в 2019 году, около 90% специалистов по кибербезопасности обеспокоены безопасностью используемых облачных сервисов. В некоторых отраслях (например, оборонно-промышленный комплекс) службы безопасности на основе внутренних нормативных актов ограничивают передачу данных за периметр предприятия, что исключает возможность использования облачных решений в принципе. Ещё одним недостатком облачных сервисов считают большую степень зависимости от поставщиков услуг (так называемый vendor lock-in), которые помимо предоставления сервисов и инфраструктуры, потенциально получают неконтролируемое влияние на рынок и клиентов. Так же сюда можно отнести высокую стоимость предоставления подобного рода услуг.

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

Так исторически сложилось

Все периферийные устройства мы, как правило, разрабатываем на основе микроконтроллера ESP32 разработанного компанией Espressif Systems. На наш взгляд, сегодня это один из лучших вариантов с точки зрения цена/качество/производительность на рынке. За вполне приемлемую цену мы получаем два ядра, аппаратные блоки шифрования, интегрированныеWi-FiиBluetooth модули, практически все периферийные интерфейсы и встроенный сопроцессор, на котором, посредством программирования на Assembler, можно весьма эффективно решать различные фоновые задачи в режиме ультранизкого потребления. Пришлось, конечно, практически полностью переписать китайский SDK, но сейчас не об этом.

Mesh

Беспроводную передачу данных мы решили строить на основе разработанной нашими инженерами mesh-cети. Q-mesh это сетевой протокол, построенный поверх протоколов IEEE 802.11n, IEEE 802.11lr и Bluetooth, позволяющий объединять многочисленные устройства, распределенные по большой площади как внутри, так и снаружи помещения в единую беспроводную локальную сеть. Сеть работает на частотах 2.4 ГГц и 868 МГц или 433 МГц. Частота 2.4 ГГц используется как основная, а частота 868 МГц или 433 МГц как дополнительная, для повышения надёжности, а также для маршрутизации между удаленными сегментами сети.

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

Как мы храним данные

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

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

В процессе работы такой системы может генерироваться значительный объем данных. Для их хранения, обработки и маршрутизации в системе предусмотрены сервера, построенные на микро сервисной архитектуре, которая позволяет распределять нагрузки. Это делает систему более устойчивой и надежной. Сервера обеспечивают передачу данных между удаленными ячейками mesh-сети, синхронизируют данные между собой и обновляют данные у пользователей в реальном времени. Устройства и пользователи подключаются к системе через веб-сокеты, что обеспечивает быстрый отклик устройств на команды и быстрое предоставление свежих данных пользователям.

Автономное питание

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

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

Ледовая арена Химик. Управление освещением реализовано согласно нашей концепцииЛедовая арена Химик. Управление освещением реализовано согласно нашей концепции

Передача данных

В отличие от традиционных сетей, например, Wi-Fi, Q-mesh поддерживает динамический выбор канала, основываясь на информации о загрузке каналов, интенсивности и спектре помех. Это способствует более устойчивой работе системы в условиях загруженного радиоэфира.

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

Скорость передачи данных в диапазоне 2.4 ГГц составляет от 0.25 до 112 Мбит/сек, а время задержки передачи от точки к точке от 5 до 50 миллисекунд. Скорость передачи данных в диапазоне 868 МГц составляет 1 Мбит/сек. Передача данных в диапазоне 433 МГц происходит на скорости 0.25 Мбит/сек.

Безопасность сети обеспечивается применением современных алгоритмов шифрования (AES с длиной ключа 192 или 256 бит) с использованием аппаратной поддержки. Трафик туннелируется между сервером и устройством или между парой устройств и шифруется отдельным ключом.Ключ генерируется из шума радиоэфира.

Управление и настройка

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

Управление и настройка такой системы происходит через веб-интерфейс, который может раздавать любое из устройств системы выполняющего роль сетевого шлюза (gateway станции). Учитывая ограниченные вычислительные возможности периферийных устройств, поддержку веб-интерфейса они отдают в виде скрипта на сторону браузера смартфона, ПК или планшета, которые, располагают куда большей производительностью. Так как это происходит только в момент, когда пользователь взаимодействует с системой, то нагрузки на принимающую сторону не значительны. В свою очередь, для того, чтобы устройство проснулось и передало необходимые данные дальше, ему также не нужны большие вычислительные ресурсы. Поэтому мы можем использовать более дешевые и менее производительные микроконтроллеры, создавая для пользователя дополнительную ценность. В дополнение к этому, решения для браузеров легко интегрировать, так как они работают практически с любой ОС: Linux, Mac, Android и т.п. Таким образом, на том же ESP32 с 256 Кбайт оперативной памяти, мы можем запускать веб-приложения практически, любой сложности и с любой графикой, производить сложные вычисления на стороне веб-приложения с приемлемой скоростью отображения. Это возможно потому, что основная обработка происходит на стороне значительно более производительного оборудования и, поэтому, запас вычислительных ресурсов у нас практически безграничный.

Резюме

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

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

Подробнее..

Как быть, когда все советуют растащить проект на микросервисы. А ты не готов

30.06.2020 12:04:28 | Автор: admin
Монолит часто обсуждают в негативном ключе. Но сразу перейти на микросервисы получится не у всех и вот уже не первая команда и компания делятся опытом построения переходного звена: модульной архитектуры. Давайте в деталях посмотрим, как делаются такие проекты.



Недавно я смотрел два доклада на эту тему: от Юлии Николаевой из iSpring и Антона Губарева из Skyeng. Так как с Антоном мы работаем в одной компании, для своего подкаста я решил поговорить с Юлей.



Ниже текстовая расшифровка основных идей из разговора.

Мы взвесили причины, по которым хотели перейти в микросервисы, и настоящие проблемы, которые мешали нам жить в монолитной архитектуре


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

Это произошло с нашим проектом: он стартовал в 2009-м, но долго не было людей и времени, чтобы бороться с неконтролируемым разрастанием кодовой базы. А к 2018-му стало понятно: пора уже как-то реструктуризировать монолит.

Когда встал вопрос, что делать с нашим монолитом, мы, естественно, тоже рассматривали микросервисы. Но У распределенной архитектуры свои накладные расходы. И мы не были к ней готовы. Например, у нас не было команды девопсов от слова совсем.

Не было как такового нормального CI/CD, не было ни докера, ни кубернетеса вообще ничего такого.


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

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

У нас все усугублялось тем, что кусок легаси написан Symfony 1.4 с использованием Propel 2, который не так просто использовать в парадигме DDD (Domain Driven Design). А нам очень хотелось DDD. Для этого хорошо подходит ORM Doctrine, которую к легаси так просто не прикрутишь.

Мы решили скрестить ужа с ежом и теперь живем с двумя фреймворками.


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


Буквально каждый день, на каждом шагу мы встречали множество вопросов, которые не знали, как решить


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

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


Они занялись переездом в кубернетес, докер и все такое.

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

Да, поначалу тяжело. Но зато когда разработчик распробует и примет новую архитектуру, а ему прилетает фича, которую нужно сделать в легаси, у него сразу возникнет мысль: Как бы мне сделать так, чтобы было похоже на новую архитектуру.

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

На все у нас ушло, наверное, три с половиной месяца.


Мы не просто переделали архитектуру, но и реализовали новый функционал с вынесением частей из легаси. Плюс, все эти три месяца нам команда девопсов настраивала инфраструктуру, чтобы мы смогли взлететь в Kubernetes. Сейчас в новом коде у нас 14-15 контекстов плюс большой легаси, где можно было бы выделить несколько контекстов. Пока в легаси остается большинство контроллеров непонятно было, куда положить их код, потому что контроллеры могут получать и манипулировать данными разных контекстов.

И ура! Мы можем писать фичи в 3-4 потока командой из 12 бэкендеров.


Сергей: В PHP мы не можем дать программисту по рукам и запретить использовать какой-то внутренний класс другого модуля. Это же все держится на устных договоренностях внутри команды. Как это все организовать?


Юлия: Контролировать такую архитектуру сложно. Все разработчики должны быть погружены в эту идею, разделять ее. Мы по этим граблям прошлись поначалу, когда вовлекали команду. Многим казалось, что это оверинжиниринг дикий: Зачем так сложно, давайте так не будем.

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

Мы нашли такую утилиту deptrac статический анализатор кода, который помогает контролировать зависимости.


Утилита встроена в наш CI/CD и запускается автоматически: фактически, большая часть договоренностей контролируется с ее помощью. Логические ошибки стараемся отлавливать еще на архитектурном ревью: это встреча, на которой разработчик, которому предстоит пилить фичу, представляет схемы, где все по слоям уже разделено. Там сразу понятно, что в каком контексте, какие взаимосвязи и т.д.

Сергей: А как такую архитектуру мэйнтэйнить?

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

Сергей: БД у нас одна, проект у нас один. Что мне делать, если в моем модуле нужны данные из нескольких других контекстов?

Юлия: Это один из самых сложных вопросов наверное, как в модульной, так и в микросервисной архитектуре. Мы пытались в одном из случаев реализовать объединение данных из разных API: сделали запросы, объединение в памяти, сортировку, фильтрацию. Работало жутко медленно.

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

Сергей: И здесь мы подходим к проблеме с дублированием кода...

Юлия: Дублирование возникает, например, если у нас есть слой, который авторизует операции во всех контекстах и мы его дублируем в каждом контексте. То есть, у нас есть практически одинаковый код, который запрашивает: А есть ли права у пользователей. Но мы считаем, что это достаточно приемлемое дублирование.

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

Юлия: Ты перечислил кейсы, которые хорошо укладываются в событийную модель. У нас много через асинхронные ивенты сделано. Если контекст не должен знать ничего про то, что произойдет в других контекстах, будет событие, которое обработает все заинтересованные в нем лица. Если действие тесно связано с выполняемой операцией и про ее контекст нужно знать, напрямую вызывает метод API.

Все как в микросервисной архитектуре, грубо говоря.


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

Сергей: Но если приложение постоянно усложняется фичами и контекстами, модульный монолит все равно лишь промежуточный шаг к микросервисам?

Юлия: Да, конечно. Если подразумевается, что приложение будет непрерывно расти, если команды будут расти, это естественно. Например, у нас возникла проблема, что автотесты нереально долго выполняются перед релизом, а если что-то отвалится приходится повторно это все запускать.

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

P.S. Больше выпусков подкаста Между скобок с интересными людьми из мира PHP можно найти здесь.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru