En este artículo, se describe una estrategia de stamps de implementación para admitir el escalado vertical del número de dispositivos conectados en una solución de Internet de las cosas (IoT). En el artículo, también se describe en detalle cómo implementar dispositivos y aplicaciones IoT entre stamps de implementación.
La estrategia de stamps de implementación para soluciones IoT se basa en el patrón de diseño Stamps de implementación. Los stamps de implementación son unidades compuestas de componentes heterogéneos que admiten una población de dispositivos definida. Los stamps de implementación escalan verticalmente el número de dispositivos IoT conectados mediante la replicación de stamps, en lugar de escalar verticalmente de forma independiente las diferentes partes de una solución.
Ventajas de los stamps de implementación:
- Colocar y distribuir los dispositivos por criterios como la dependencia geográfica, el ciclo de vida o el estado de la versión.
- Contener el impacto de una interrupción o degradación del servicio a stamps específicos.
- Implementar nuevas características, funcionalidades y cambios arquitectónicos en stamps específicos que puedan admitirlos.
- Compatibilidad con la administración de dispositivos de varias generaciones mediante la alineación de las funcionalidades y los servicios con las poblaciones de dispositivos especificadas.
- Proporcionar un modelo de escalado y costo basado en stamps para adaptarse de forma predecible al crecimiento futuro.
Arquitectura de stamps de implementación de IoT
Descargue un archivo Visio de esta arquitectura.
En el diagrama anterior, se muestra una estrategia de stamps de implementación para Azure IoT. Esta solución crea stamps atómicos que constan de:
- Una instancia de Azure IoT Hub
- Puntos de conexión de enrutamiento como Azure Event Hubs
- Componentes de procesamiento
Los stamps siempre se deben diseñar para admitir capacidades explícitas. Para determinar el número correcto de dispositivos que se admitirán, tenga en cuenta la cantidad de tráfico de comunicación que se espera de los dispositivos. En esta solución, cada stamp admite de forma óptima una población de dispositivos definida de 1000 a 1 000 000 de dispositivos. A medida que crece la población de dispositivos, las instancias de stamp agregadas se adaptan al crecimiento.
Movimiento de dispositivos y aplicaciones entre stamps
Los stamps de implementación están pensados para una implementación atómica, pero en ocasiones tiene que trasladar poblaciones de dispositivos entre stamps. Por ejemplo, podría ser necesario:
- Mover poblaciones de dispositivos desde los stamps de prueba a los stamps de producción como parte de un ciclo de lanzamiento.
- Mover dispositivos y usuarios a otro stamp como parte de la corrección de interrupciones en un escenario de alta disponibilidad.
- Equilibrar la carga para distribuir la población de dispositivos de forma más uniforme entre stamps.
Movimiento de dispositivos entre centros
Si los componentes del stamp solo abarcan el comportamiento del dispositivo a la nube, el movimiento de dispositivos entre centros es suficiente para migrar los dispositivos de un stamp a otro. Azure IoT Hub Device Provisioning Service (DPS) proporciona una manera de mover dispositivos entre instancias de IoT Hub. Para usar DPS en la estrategia de stamps, asegúrese de comprender los conceptos y la terminología de IoT Hub Device Provisioning Service (DPS).
Nota:
DPS usa identificadores de registro, mientras que IoT Hub usa identificadores de dispositivo. Estos identificadores suelen ser el mismo valor, pero pueden ser diferentes. Al consultar o administrar dispositivos con las API de DPS, asegúrese de usar los identificadores de registro.
Movimiento de dispositivos y aplicaciones entre stamps autocontenidos
Si los stamps de implementación incluyen front-ends web o aplicaciones de API que se comunican mediante IoT Hub, esos componentes también se deberán migrar a los nuevos centros para continuar la comunicación con los dispositivos que se han trasladado. Puede mover aplicaciones completas y dispositivos entre stamps.
En los casos en los que cada stamp abarca una aplicación completa, Azure Traffic Manager puede mover el tráfico de un stamp a otro. Esta estrategia implica la creación de varios stamps, cada uno de los cuales contiene toda la aplicación con su propia dirección URL. Toda la población de dispositivos y usuarios de la aplicación se mueve de un stamp a otro.
Esta estrategia totalmente autocontenida es:
- Fácil de implementar.
- Adecuada como parte de una estrategia de alta disponibilidad.
- Útil para la migración de dispositivos y usuarios de los entornos de prueba a los de producción.
Descargue un archivo Visio de esta arquitectura.
En el diagrama anterior, se muestra el proceso de traslado de un conjunto de dispositivos del Stamp 1 al Stamp 2:
- Los dispositivos adquieren el punto de conexión de IoT Hub mediante DPS si es desconocido o ya no es válido.
- Cuando los dispositivos se trasladan al Stamp 2, Traffic Manager apunta la dirección URL de la aplicación a la instancia de Aplicación 2.
- DPS mueve un conjunto completo de dispositivos de un stamp a otro.
- Cada stamp de aplicación contiene el front-end de la aplicación y hace referencia a la instancia de IoT Hub correspondiente a ese stamp.
Movimiento de dispositivos entre stamps detrás de una única puerta de enlace de aplicaciones
Cuando un único front-end de aplicación admite varios stamps de dispositivos, el front-end de aplicación debe actualizar dinámicamente su asignación de dispositivo a centro para mantener la comunicación de la nube al dispositivo. Para posibilitar el traslado de dispositivos a otros stamps y centros de IoT, las puertas de enlace pueden usar un mecanismo de almacenamiento en caché para la asignación de dispositivo al centro. Los clientes del servicio pueden usar una rutina de búsqueda compartida para detectar y migrar dinámicamente las llamadas del dispositivo a los nuevos centros de IoT.
Descargue un archivo Visio de esta arquitectura.
En este modelo, la puerta de enlace usa una memoria caché para asignar dispositivos a centros de IoT y el valor predeterminado es el punto de conexión almacenado en caché. Si la puerta de enlace recibe un error de dispositivo no encontrado, usa el SDK del servicio DPS para consultar la inscripción de dispositivos individuales y determinar qué centro de IoT Hub usa ahora el dispositivo. A continuación, la puerta de enlace actualiza la memoria caché con la nueva asignación.
Estas son algunas consideraciones para esta estrategia:
Aunque el almacenamiento en caché en una búsqueda compartida evita volver a negociar los puntos de conexión en cada llamada, es posible que se produzca un error en el punto de conexión de la memoria caché. Una memoria caché secundaria o un plan de reserva de renegociación con DPS pueden mejorar la confiabilidad de la solución.
Si la inscripción del dispositivo está en curso, el dispositivo no será accesible. Use una API de DPS como Get Device Registration State para obtener el centro de IoT asignado al dispositivo y su estado de inscripción actual.
En el caso de solo dispositivo, los dispositivos se desconectan del centro de IoT cuando se mueven de un stamp a otro. En el caso de la aplicación al dispositivo, el error se produce cuando la aplicación intenta alcanzar el dispositivo mediante el centro de IoT.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Jason Wadsworth | Ingeniero principal de software
Pasos siguientes
- Dispositivos, plataforma y aplicaciones IoT
- Comandos de la aplicación al dispositivo de IoT
- Patrón de diseño de stamps de implementación