En la sección anterior, hablamos de los dos conceptos más básicos de Service Fabric: uno es el Tipo de Nodo y el Nodo a nivel de hardware. La otra es la Aplicación.
El Tipo de Nodo es un conjunto de Nodos, que son abstracciones conceptuales de máquinas que se despliegan. Para Service Fabric, un nodo puede ser una máquina física, una máquina virtual o incluso el contenedor más popular actualmente.
Ejecutándose en el tipo de nodo es Aplicación. Es una comprensión abstracta a nivel de software de sistema. Hay varios Microservicios en una aplicación. Incluso todos los servicios subyacentes de Service Fabric, como FailoverManager Service y Naming Service, son Microservicios.
Todas las características distribuidas de Service Fabric corresponden a despliegues de Microservicios. Podemos ajustar dinámicamente cuántas instancias necesita ejecutar un Micro Servicio, cuántos nodos distribuir la presión de carga o realizar copias de seguridad ante desastres. Cada instancia escucha un puerto diferente, y la capa de balanceo de carga distribuye las solicitudes a distintas instancias.
Escenario real
El Servicio Estadual es uno de los Microservicios.
Antes de empezar a presentar el Servicio Estatal, consideremos los siguientes escenarios empresariales comunes.
Estás pensando en implementar una función de carrito de la compra en tu página web. Tras iniciar sesión, los usuarios colocarán algunos artículos en su carrito de la compra.
La próxima vez que el usuario inicie sesión, la página de recepción llamará al servicio de carritos de la compra y deberá releer los datos guardados de este servicio y mostrarlos.
Si es así, ¿cómo lo conseguirías?
Si el número de usuarios no es especialmente grande, añadiremos una tabla de carrito de la compra a la base de datos y la asociaremos con la tabla de usuario. La tabla de cartuchos tendrá un campo de ID de usuario y registrará una gran cantidad de datos de cartuchos de usuario.
Entonces esto traerá algunos problemas posteriores.
Si el número de usuarios sigue aumentando, el rendimiento de las tablas de la base de datos seguirá degradándose.
Los datos de las tablas de bases de datos deben hacerse copias de seguridad regularmente en caso de pérdida de datos
Si hay un problema con el rendimiento de la base de datos, la tabla debe ser desacreditada o incluso particionada
El propio sistema de carritos de la compra debe gestionar cualquier ajuste en la base de datos, e incluso puede necesitar un balanceo de carga
La raíz de este problema es que el sistema en sí no está diseñado para ser escalable desde el principio. Además, las bases de datos son un posible cuello de botella y una amenaza para el rendimiento.
Servicio Solemne
Consideremos una arquitectura completamente nueva.
Desde el principio, el sistema de carrito de la compra tiene 36 subservicios que gestionan todas las solicitudes (36 porque las iniciales del ID de usuario son de 0 a 9 de la a la z, un total de 36).
La solicitud del usuario se procesa según el hash inicial del ID de usuario para un subservicio específico.
El subservicio almacena los datos del carrito de la compra internamente a través de una base de datos ligera y los mantiene en su propio dispositivo de almacenamiento.
Cada subservicio también tiene 3 copias de seguridad, que sincronizan constantemente los datos almacenados, y estas copias siempre se ejecutan en diferentes nodos.
Al mismo tiempo, solo una copia de seguridad es responsable de procesar las solicitudes como estado de activación, y cuando hay un problema al activar la copia de seguridad, las otras dos copias activan una según el algoritmo de planificación.
El subsistema de recuperación ante desastres crea una nueva copia de seguridad para asegurar que el subservicio siempre tenga 3 copias de seguridad sanas.
El Servicio Con Estado es una de esas soluciones.
Volviendo al escenario anterior, el sistema de carritos de la compra es un servicio con estado.
Los 36 subsistemas son las 36 instancias de este Servicio Con Estado, que llamamos Particiones.
La copia de seguridad bajo cada subsistema es Réplica, y hay 3 Réplicas en una partición.
La copia de seguridad actualmente activa es Active Replica, y las dos copias de seguridad inactivas en espera son Secondary Replica.
Cada réplica de la misma Partición debe ejecutarse en un nodo diferente.
El código del Servicio Con Estado utiliza <T>interfaces como IReliableCollection, IReliableDictionary< T1 y T2 > para guardar datos y sincronizarse internamente.
Además, el Servicio Con Estado puede implementar las siguientes características:
Todos los números anteriores se pueden reiniciar, y puedes tener cientos de particiones en el sistema de carros para cargar más estrés. Incluso puedes tener 5 o más réplicas por partición para asegurar mayor robustez.
A los sistemas externos no les importa cuántas particiones tenga el Servicio Con Estado, se llaman por clave de partición. La clave de partición y la partición correspondiente se resuelven mediante el Micro Service of Service Fabric subyacente. Por ejemplo, en tu empresa puedes tener unos pocos millones de usuarios, pero solo configurar 5 particiones. Al llamar al servicio de estado del carrito de compra, el sistema externo solo necesita informar el ID de usuario (clave de partición) y los datos guardados. Esta petición se asigna automáticamente a una de las cinco particiones según el ID de usuario y el algoritmo hash.
Las operaciones de datos en los Servicios Estatales soportan transacciones. Así que puedes revertir en caso de fallo
Espero que la introducción anterior pueda ayudarte a comprender mejor el Servicio Militar.
Cubriremos ejemplos de código para el Servicio Con Estado en las siguientes secciones. |
Publicado en 15/3/2018 10:03:44
|
|
|
|
