¿Qué es una arquitectura de nada compartido y una arquitectura de todo compartido? ¿Cuál es la diferencia entre ellos y cuáles son sus usos?

Una arquitectura de todo compartido significa que cualquier servicio lo sabe todo y fallará si no lo hace. Si tiene una base de datos central (u otro servicio similar), entonces es probable que tenga una arquitectura de todo compartido.

Shared-nothing significa que no se comparte ningún estado entre todos los demás servicios. Si un servicio falla, no pasa nada a los otros servicios.

La mayoría de las aplicaciones generalmente comienzan como una arquitectura de todo compartido, pero no tienen que hacerlo, esa ha sido mi experiencia. Cuando llegue a la escala global, querrá poder fallar los servicios aleatorios, y por qué la aplicación puede ejecutarse en un estado degradado hasta que el servicio fallido regrese, el resto de la aplicación continuará ejecutándose.

La arquitectura de nada compartido es resistente cuando se hace correctamente. Todo lo que necesita saber desde fuera del servicio se envía al servicio en su “solicitud de trabajo”, que probablemente esté firmada o encriptada con una clave confiable.

Por ejemplo, si un usuario solicita un recurso del servicio de recursos. El servicio de recursos tendrá su propia base de datos sobre qué usuarios pueden solicitar ese recurso específico, o la solicitud incluirá un token encriptado que proporciona al servicio autenticación y / o autorización. El servicio de recursos no tiene que llamar a un recurso de autorización (o buscar en una base de datos compartida) y preguntar si el usuario puede acceder al recurso. Esto significa que, si el servicio de autenticación estuviera inactivo y el usuario tuviera un token válido (desde antes de que el servicio de autenticación cayera) que todavía fuera válido, el usuario podría recuperar el recurso hasta que el token expire.

¿Cuándo usarlos?

Use la arquitectura de todo compartido cuando necesite ser altamente consistente a costa de la resiliencia. En el ejemplo que mencioné anteriormente, si el servicio de autenticación decidió que el token era incorrecto y lo revocó, el servicio de recursos no podría saberlo antes de ser informado por el servicio de autenticación. En ese período de tiempo, el usuario podría haber recuperado el recurso “ilegalmente”. Esto es similar a solicitar varios préstamos antes de que tengan la oportunidad de aparecer en su informe crediticio y afectar su capacidad de obtener un préstamo.

No use nada compartido cuando la resistencia sea más importante que la consistencia, si puede garantizar algún tipo de consistencia eventual, entonces esta podría ser la solución más escalable.