arquitectura de microservicios está muy extendida en el desarrollo de software. Pero las organizaciones que lo utilizan, además de las dificultades para implementar la lógica empresarial, también enfrentan fallas distribuidas.
Los errores de computación distribuida están bien documentados pero son difíciles de detectar. Como resultado, construir una arquitectura de sistema distribuido confiable y a gran escala se convierte en un desafío complejo. El código que se ve muy bien en un sistema monolítico puede convertirse en un problema una vez que se pasa a la red. El
equipo de Mail.ru Cloud Solutionstradujo un artículo, cuyo autor ha estado involucrado en la detección de errores típicos en el código de producción durante varios años y estudió las razones que llevaron a este resultado. Este artículo proporciona pautas de revisión de código que el autor usa como una lista de verificación básica.
El sistema remoto falla
No importa cuán cuidadosamente esté diseñado el sistema, fallará en algún momento; esto es un hecho cuando el software se lanza a producción.
Las fallas ocurren por una variedad de razones: errores, problemas de infraestructura, picos repentinos de tráfico, deterioro de la negligencia, pero casi siempre ocurren. La solidez y confiabilidad de toda la arquitectura depende de cómo los módulos de llamada manejen los errores:
- . . , , . — . , .
- . , . ? ? , ? ? .
Esta situación es peor que una falla total, ya que no se sabe si el sistema remoto está en funcionamiento. Por lo tanto, para manejar este escenario, siempre debe verificar los problemas que se describen a continuación.
Algunos de los problemas se pueden resolver de forma transparente con el código de la aplicación mediante el uso de tecnologías Service Mesh como Istio. Sin embargo, debe asegurarse de que dichos problemas se manejen independientemente del método:
- Establezca tiempos de espera para las llamadas del sistema remoto . Esto también se aplica a los tiempos de espera para API remotas y llamadas a bases de datos, publicación de eventos. Compruebe si se han establecido tiempos de espera razonables y finales para todos los sistemas remotos en las llamadas. Esto evita el desperdicio de recursos esperando si el sistema remoto deja de responder.
- -. , — . , .
, - (, ). , , . — , . - (Circuit Breaker). , , Hystrix. . , Circuit Breaker . — .
- - . - — , . , . , -. , .
- . , . , , .
- . , ( API, ), — . : , , . .
,
- , API . - API. , API . API API, — .
- SLA — . SLA , . , .
SLA : — . , SLA. — , , . - API-. SLA — SLA.
- . — , . , , , . .
— «» , «» . , id = 123, id =123. , «» , « ». .
- . , , . , Redis, . , .
- . API (), ? , , ? API ?
- . , , , . . . , , . . .
- Verifique la entrada en cada punto de entrada. En un entorno distribuido, cualquier parte del sistema puede verse comprometida desde el punto de vista de la seguridad o tener errores. Por tanto, cada módulo debe comprobar qué recibe como entrada. Y no asuma que recibirá una entrada limpia, es decir, segura.
- Nunca almacene credenciales en un repositorio de código. Este es un error muy común y difícil de eliminar. Sin embargo, las credenciales siempre deben cargarse en el tiempo de ejecución del sistema desde un almacenamiento externo, preferiblemente seguro.
Espero que estas pautas le resulten útiles para reducir errores comunes en el código de sistemas distribuidos.
¡Buena suerte!
Qué más leer: