La evolución de la arquitectura de microservicios
Una aplicación en el modo monolítico generalmente tiene un servidor de aplicaciones, que contiene diferentes submódulos, cada uno de los cuales está escrito en el mismo paquete de la aplicación y, a veces, los límites entre los módulos no están claramente diseñados, especialmente si el código inicial es mixto. juntos, significa llamarse unos a otros.
Esta arquitectura monolítica relativamente pesada aún garantiza una alta disponibilidad de las aplicaciones a través de la implementación redundante y el equilibrio de carga.
La arquitectura monolítica ya no es adecuada para necesidades empresariales complejas. Haremos algunos ajustes a la arquitectura empresarial y la reemplazaremos con subsistemas uno por uno. Estos subsistemas tienen archivos de implementación independientes y ciclos de vida independientes. Los requisitos de alta disponibilidad de cada subsistema también son diferentes.Subsistemas y subsistemas completan todo el negocio a través de llamadas de red.
El sistema monolítico original, como un modelo de instancia única y proceso único, se convertirá en cientos de subservicios para formar una vista de implementación unificada.
En este momento, vaya a la carne humana para controlar uno por uno, entonces el costo será muy alto y la probabilidad de error será muy alta. De esta manera, es necesario confiar en métodos automatizados para completar la configuración de aplicaciones y las capacidades de descubrimiento de servicios.
Evolución del sistema monolítico al sistema de microservicios
Supongamos que hay una tienda en línea y las ventas tienen un módulo de ventas que proporciona un portal para vender cosas. Los productos vendidos en la tienda en línea deben almacenarse y existe un sistema de gestión de almacenes para administrar el inventario. También hay demandas de facturación y descuentos. Para una sola aplicación, se proporcionará a las funciones de la aplicación única.
Como es el mismo proceso, siempre y cuando me digas la dirección, puedo acceder a todos los servicios.
Evolución de la arquitectura de microservicios
Para dividir una aplicación monolítica en una arquitectura de microservicio, las diferentes capacidades en un proceso de aplicación se dividen en diferentes subsistemas y cada subsistema asume sus propias responsabilidades.
Dado que las ventas respaldan el negocio front-end, sus requisitos de disponibilidad serán mayores y cuantas más solicitudes simultáneas admita, aquí puede implementar más instancias, brindar más soporte de carga simultánea y luego brindar mayor disponibilidad.
La red debe estar abierta para cada sistema, incluidas las llamadas entre servicios y servicios. Para resolver este complejo acoplamiento, se puede utilizar la puerta de enlace api. Puede haber muchísimos servicios en el clúster, y estos servicios pueden estar expuestos a través del mismo nombre de dominio, por lo que se necesita una puerta de enlace API que acepte diferentes solicitudes de clientes y las reenvíe a diferentes servicios a través de la puerta de enlace.
Las llamadas entre servicios requieren un mecanismo de detección de servicios, y luego se requiere un registro de servicios. Después de que cada servicio esté activo, debe registrarse y diferentes renovaciones dirán que estoy vivo. Tiene que registrar su propio estado de salud, y cuando otras personas hagan llamadas de servicio, sabrán qué servidores reales se están ejecutando detrás de este servicio.
Aquí hay un centro de registro de servicios, la información de la dirección registrada por el centro de servicios es que si se registra de manera punto a punto, el estado de salud de cada nodo debe actualizarse en tiempo real. El otro es a través del equilibrio de carga centralizado o el equilibrio de carga distribuido, luego se vinculará la IP virtual de la entrada unificada.
Escenarios típicos de negocios de microservicios
Puede haber una relación de llamada fija entre el almacén y la contabilidad. La arquitectura del sistema actual está diseñada para fallar. Al diseñar el sistema, se debe asumir que cualquier componente no es confiable. Hay dos fallas posibles en la contabilidad. Posiblemente, una es que un el código de error puede devolverse, y el otro es que puede que no responda.Si no hay respuesta, muchas aplicaciones se escriben en el código comercial y devuelven 50x. Si se suspende la animación, entonces el almacén no sabe que hay un problema con la contabilidad, enviará la solicitud a la contabilidad y esperará su respuesta, si la aplicación no está bien escrita y es lo suficientemente robusta, esperará indefinidamente. pero pensará que la contabilidad es normal. Debido a que la contabilidad no le devuelve ningún mensaje de error, las ventas continuarán reenviando la solicitud.
Entonces hará que el almacén reciba muchas solicitudes de ventas, no hay una forma efectiva de reenviar estas solicitudes a contabilidad para obtener el valor de devolución, entonces la acumulación de solicitudes en el almacén será cada vez mayor, por lo que el almacén puede también mal funcionamiento.
Después de la aparición del almacén, también se pueden causar problemas similares y cada componente puede verse afectado, lo que hará que cada falla local se expanda a lo global.
En muchos casos, el almacén necesita la capacidad de fusionarse. Uno es que devuelve un código de error, y debe poder manejar correctamente este código de error.
Además, si no devuelve un código de error, al menos debe saber cuántas solicitudes simultáneas se han realizado y limitar las solicitudes simultáneas anteriores. Si hay muchas solicitudes simultáneas, debe fusionar y degradar el servicio, y diga a ventas que se han enviado muchas solicitudes, pero no se ha recibido respuesta. Entonces no hay forma de manejar más solicitudes ahora.
Dado que es un sistema de arquitectura de microservicios, cada servicio es responsable de registrarlo en el registro de servicios, y la llamada descendente de cada servicio requiere capacidades de balanceo de carga.
Si se proporciona un servicio HTTP, no se realiza ninguna verificación. Entonces este servicio se verá afectado por muchas solicitudes maliciosas o no maliciosas, por lo que no se puede controlar la validez, frecuencia, etc. de las solicitudes.
Si el servicio brinda la capacidad de eliminar, si no se realiza verificación ni autenticación, entonces esta protección está fuera de cuestión.
Toda la empresa tendrá un conjunto de servicios centrales para autenticación y autenticación. Cada aplicación estará conectada a este servicio. Las llamadas entre servicios deben basarse en permisos de confianza. Quiero saber quién es usted y debe tener este permiso. capaz de llamarme. Por lo general, hay un servidor de autenticación aquí.
Cada servicio se comunicará con el servidor de autenticación para obtener la capacidad de autorizar credenciales.
Una arquitectura de servicios más completa
El cliente inicia las solicitudes, el servidor responde a estas solicitudes y el servidor tiene lógica de negocios y capacidades de plataforma.
Luego, un marco completo de microservicios integra las capacidades comerciales y las capacidades de la plataforma como un todo.
límite del sistema
Cómo ordenar las capacidades de la plataforma y las capacidades comerciales.
¿Cuál es la lógica empresarial? Hay descuento de contabilidad de almacén de ventas, estos son realmente códigos lógicos relacionados con el negocio.
Estos son negocios.
El resto está relacionado con la autenticación, la ruptura de circuitos, el balanceo de carga y los protocolos, que no tienen nada que ver con los negocios. Estas son más capacidades en el lado de la plataforma. Es la llamada entre empresa y empresa, en función de qué acuerdo y qué tipo de apelación, todos estos están unificados en el lado de la plataforma.
Este tipo de arquitectura generalmente se divide en dos tipos, uno es la nube de primavera con la que los programadores de Java están familiarizados, este proyecto integra netfix, que es un software de código abierto de la empresa Netflix. Este software de código abierto incluye eurka, como el registro de servicios o cinta, que es para el equilibrio de carga del cliente.
Estos incorporan muchas bibliotecas de código abierto en el código comercial.Cuando el código comercial se usa para capacidades del lado de la plataforma, entonces el código comercial y las capacidades de la plataforma deben estar profundamente integrados. En segundo lugar, si desea realizar cambios, debe mover el paquete implementado. Por ejemplo, si desea actualizar la versión de su capacidad de detección de servicios o la capacidad de equilibrio de carga, debe actualizar todo el paquete de guerra.
De esta forma, el lado comercial y la plataforma se convierten en una relación estrechamente acoplada.
Entonces, ¿existe una forma más elegante y más razonable de hacer que el negocio pertenezca al negocio y la plataforma pertenezca a la plataforma? ¿Puede simplificar los requisitos en el lado de la plataforma básica que enfrenta el negocio?
Se autenticará, descubrimiento de servicios. Estas capacidades de fusión se arrojan al lado de la plataforma, de modo que el lado comercial realmente solo se preocupa por el negocio. Este modo es la capacidad recomendada por la red de servicio, que es el resultado que persigue istio.
