В этой статье содержится список элементов, которые следует учитывать при перемещении решения Интернета вещей в рабочую среду.
Использование меток развертывания
Метки — это отдельные единицы основных компонентов решения, которые поддерживают определенное количество устройств. Каждая копия называется меткой или единицей масштабирования. Например, метка может состоять из заданного набора устройств, Центра Интернета вещей, концентратора событий или другой конечной точки маршрутизации и компонента обработки. Каждая метка поддерживает определенное заполнение устройства. Вы можете выбрать максимальное число устройств, которое может хранить метка. По мере роста количества устройств вы добавляете экземпляры меток, а не независимо масштабируете различные части решения.
Если вместо добавления меток вы перемещаете один экземпляр решения Интернета вещей в рабочую среду, вы можете столкнуться со следующими ограничениями:
Ограничения масштаба. Ваш отдельный экземпляр может столкнуться с ограничениями масштабирования. Например, ваше решение может использовать службы с ограничениями на количество входящих подключений, имена узлов, сокеты TCP или другие ресурсы.
Нелинейное масштабирование и стоимость. Компоненты вашего решения могут масштабироваться нелинейно в зависимости от количества сделанных запросов или объема полученных данных. Вместо этого для некоторых компонентов может наблюдаться снижение производительности или увеличение стоимости после достижения порогового значения. Масштабирование с большей емкостью может быть не такой хорошей стратегией, как масштабирование путем добавления меток.
Разделение клиентов. Вам может потребоваться изолировать данные одних клиентов от данных других клиентов. Точно так же у вас могут быть некоторые клиенты, которым требуется больше системных ресурсов для обслуживания, чем другим, и вы можете сгруппировать их по разным меткам.
Экземпляры с одним и несколькими арендаторами. У вас могут быть крупные клиенты, которым нужны собственные независимые экземпляры вашего решения. У вас также может быть пул небольших клиентов, которые могут совместно использовать развертывание с несколькими арендаторами.
Сложные требования к развертыванию. Вам может потребоваться развертывание обновлений службы контролируемым образом и развертывание с использованием разных меток в разное время.
Частота обновлений. У вас могут быть клиенты, которые терпимо относятся к частым обновлениям вашей системы, в то время как другим клиентам это может не нравиться из-за возможных рисков и они будут предпочитать нечастые обновления.
Географические или геополитические ограничения. Чтобы уменьшить задержку или обеспечить соответствие требованиям к независимости данных, вы можете развернуть некоторых своих клиентов в определенных регионах.
Чтобы избежать описанных выше проблем, попробуйте сгруппировать службу в несколько меток. Метки работают независимо друг от друга и могут развертываться и обновляться также независимо друг от друга. Один географический регион может содержать одну метку или несколько меток, чтобы обеспечить горизонтальное увеличение масштаба в пределах региона. Каждая метка содержит группу ваших клиентов.
Использование задержки при возникновении временного сбоя
Все приложения, взаимодействующие с удаленными службами и ресурсами, должны быть чувствительны ко временным сбоям. Это особенно справедливо для приложений, работающих в облаке, где особенности среды и возможности подключения через Интернет определяют то, что такие типы сбоев могут возникать чаще. К временным сбоям относятся:
- Кратковременная потеря сетевого подключения к компонентам и службам.
- Временная недоступность службы.
- Истечение времени ожидания, когда служба занята.
- Конфликты, вызванные одновременной передачей устройств.
Эти ошибки часто устраняются без вмешательства со стороны пользователя, поэтому если повторить действие через некоторый промежуток времени, оно с большой вероятностью будет выполнено успешно. Но определить соответствующие интервалы между повторными попытками сложно. Типичные стратегии используют следующие типы интервалов повтора:
- Экспоненциальная задержка. Перед первой повторной попыткой приложение выдерживает небольшой интервал, а для каждой последующей попытки интервал увеличивается по экспоненциальному закону. Например, повторные попытки выполнения операции могут предприниматься через 3 секунды, 12 секунд, 30 секунд и так далее.
- Постоянные интервалы. Для всех повторных попыток применяется одинаковый интервал. Например, повторные попытки выполнения операции могут предприниматься через каждые 3 секунды.
- Немедленный повтор. Иногда временная ошибка кратковременна, возможно, из-за такого события, как конфликт сетевых пакетов или всплеск нагрузки в аппаратном компоненте. В этом случае имеет смысл повторить операцию немедленно, поскольку она может завершиться успешно, если ошибка устраняется за то время, пока приложение подготавливает и отправляет следующий запрос. Однако никогда не следует выполнять более одной попытки немедленного повтора. При этом вам следует переключиться на альтернативные стратегии, такие как экспоненциальная отсрочка или резервные действия, если немедленная повторная попытка не удалась.
- Случайный выбор. Любая из описанных выше стратегий может включать в себя элемент случайности, чтобы предотвратить ситуацию, когда несколько экземпляров клиента одновременно предпринимают последовательные повторные попытки.
Избегайте также следующих антишаблонов:
- Реализации не должны включать дубликаты слоев кода повторных попыток.
- Никогда не применяйте механизм с бесконечными повторными попытками.
- Никогда не выполняйте немедленный повтор больше одного раза.
- Старайтесь не использовать обычный интервал повторных попыток.
- Не допускайте ситуации, когда несколько экземпляров одного клиента или несколько экземпляров разных клиентов выполняют повторные попытки одновременно.
Использование подготовки без участия пользователя
Подготовка — это процесс регистрации устройства в Центре Интернета вещей Azure. Подготовка предоставляет Центру Интернета вещей информацию об устройстве и механизме аттестации, который оно использует. Вы можете использовать Службу подготовки устройств к добавлению в Центр Интернета вещей (DPS) или выполнить подготовку напрямую через API диспетчера реестра Центра Интернета вещей. Использование DPS связано с преимуществом поздней привязки, которая позволяет удалять и повторно подготавливать полевые устройства в Центре Интернета вещей без изменения программного обеспечения устройства.
В следующем примере показано, как реализовать рабочий процесс перехода от тестовой среды к рабочей с помощью DPS.
- Разработчик решения связывает тестовые и рабочие облака Интернета вещей со службой подготовки.
- Устройство реализует протокол DPS для поиска Центр Интернета вещей, если он больше не подготовлен. Устройство изначально подготавливается для тестовой среды.
- Так как устройство зарегистрировано в тестовой среде, оно подключается и выполняется тестирование.
- Разработчик повторно подготавливает устройство к рабочей среде и удаляет его из центра тестирования. Центр тестирования отклоняет устройство при следующем его повторном подключении.
- Устройство подключается и повторно согласовывает поток подготовки. Теперь DPS направляет устройство в рабочую среду, где устройство подключается и аутентифицируется.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Мэтью Коснер | Главный менеджер по разработке программного обеспечения
- Энсли Йео | Главный диспетчер программ
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.