service - serie - soa vs microservicios
SOA: Uniendo datos a través de múltiples servicios. (6)
Es desafortunado ver que toda esta discusión se está deteriorando en una búsqueda de afirmación "¿Puedo usar una base de datos compartida o no en SOA?", Que es totalmente irrelevante y no ayuda en absoluto a responder la pregunta original.
Más que a menudo en una situación del mundo real, los datos ya están almacenados en diferentes sistemas para comenzar. Los datos de clientes, por ejemplo, provienen de CRM, datos de productos de SAP, datos de contratos de otra fuente diferente.
No es una búsqueda para obtener estos datos técnicamente juntos, en lugar de una comprensión de que solo hay una fuente de datos. En otras palabras, solo hay un propietario de los datos dentro de su empresa, quien es el único responsable de mantenerlos y garantizar la calidad correcta de los datos.
Almacenar datos localmente por razones de rendimiento significa replicar datos, lo que es más que una aventura peligrosa, a menos que tenga una sólida estrategia de almacenamiento en caché. Creo que Mosh ha dado algunas respuestas sensatas cuando se enfrenta a un panorama de aplicaciones existente.
Imagina que tenemos 2 servicios: Producto y Pedido. Según mi comprensión de SOA, sé que cada servicio puede tener su propio almacén de datos (una base de datos independiente o un grupo de tablas en la misma base de datos). Pero ningún Servicio tiene permitido tocar el almacén de datos de otro Servicio directamente.
Ahora, imagine que hemos almacenado los datos de productos y pedidos de forma independiente en los Servicios de productos y pedidos. En el Servicio de pedidos, podemos identificar los productos por su ID.
Mi pregunta es: con esta arquitectura, ¿cómo puedo mostrar la lista de pedidos y los detalles del producto en la página "igual"?
Mi entendimiento es que debo obtener la lista de artículos de pedido de OrderService. Cada artículo de pedido tiene un ID de producto. Ahora, si hago una llamada por separado a ProductService para recuperar los detalles de cada Producto, eso sería muy ineficiente.
¿Cómo abordarías este problema?
Saludos, Mosh
Hice una investigación y encontré 2 soluciones diferentes para esto.
1- Los servicios pueden almacenar en caché los datos de otros servicios localmente. Pero esto requiere un mecanismo de publicación / suscripción, por lo que cualquier cambio en la fuente de los datos debe publicarse para que los Servicios suscritos puedan actualizar su caché local. Esto es costoso de implementar, pero es la solución más rápida porque el Servicio tiene los datos requeridos localmente. También aumenta la disponibilidad de un Servicio al evitar que dependa de los datos de otros Servicios. En otras palabras, si el otro Servicio no está disponible, aún puede hacer su trabajo con sus datos de caché.
2- Alternativamente, un Servicio puede consultar una "lista" de objetos de otro Servicio proporcionando una lista de identificadores. Esto evita que se realice una llamada por separado al servicio de destino para obtener los detalles de un objeto determinado. Esto es más fácil de implementar pero en términos de rendimiento, no es tan rápido como la solución 1. Además, en caso de que el Servicio objetivo no esté disponible, el Servicio de origen no puede hacer su trabajo.
Espero que esto ayude a otros que han encontrado este problema.
Mosh
La integración de la base de datos (de lo que realmente se habla cuando dos servicios comparten una tabla en una base de datos) es incorrecta en muchos niveles. Rompe completamente algunos de los principios más importantes de la ingeniería de software.
acoplamiento suelto, encapsulación separación de preocupaciones
Un servicio debe ser (para ganar ese nombre) completamente independiente, a saber:
- no debe confiar en otros para garantizar la coherencia y coherencia de sus datos
- No debe confiar en otros para garantizar la seguridad de sus datos.
- no debe depender de implementaciones externas (solo interfaces)
Dos servicios que comparten datos en el nivel de DB no pueden garantizar ninguno de los primeros.
El hecho de que usted "controle" ambos servicios es completamente irrelevante. Hoy controla ... mañana puede que desee subcontratar o reemplazar uno de los servicios. Eso debería ser tan simple como asegurar que las interfaces adecuadas estén en su lugar.
Imagine los dos servicios que comparten una tabla con algún campo (varchar) en ella. Ahora un servicio necesita cambiar ese campo a numérico ... golpee el otro servicio deja de funcionar - el acoplamiento suelto se va por el desagüe.
En la mayoría de los casos, el truco consiste en definir correctamente el alcance del servicio y estipular claramente qué hace un servicio y qué no. También debes evitar convertir todo en un servicio. Establezca la granularidad de su servicio en alta y los servicios comenzarán a aparecer en todas partes y los dolores de cabeza de la integración aumentarán.
Dicho esto, hay algunas situaciones en las que la integración de datos entre servicios plantea algunos desafíos. La premisa principal es, siempre debe ser: los datos pueden pertenecer a un solo servicio. Los datos están intrínsecamente ligados a la lógica empresarial que afecta la consistencia y la coherencia de los datos y, como tal, nunca debe haber más de un servicio que controle los datos.
No creo que haya ningún principio en SOA de que los servicios deban tener un almacén de datos separado. En general es en realidad poco práctico. Sí, puede tener servicio de productos y pedidos, y el cliente puede realizar la unión utilizando la llamada de servicio web como usted dijo y esto puede ser aceptable en algún escenario. Pero eso no significa que no pueda tener un servicio específico para un cliente si ya conoce el comportamiento y los requisitos de rendimiento del cliente.
Lo que quiero decir es que debe tener un servicio de búsqueda que devuelva pedidos y productos con la unión realizada en la base de datos. Esto es práctico y resolvería su problema de negocio.
Otro enfoque sería tener algún tipo de fuente de datos que viva fuera de los servicios SOA. Esta fuente de datos podría considerarse su caché de datos, su fuente de datos operacional o incluso un almacén de datos. Los paquetes de extracción pueden exportar los datos de los servicios (y / o algún tipo de mecanismo de tiempo real). Puedes consultar esta fuente de datos como quieras.
La ventaja de este enfoque es que la caja negra de SOA se mantiene y puede intercambiar un servicio sabiendo cómo lo ha acoplado.
La desventaja es la complejidad agregada y la sobrecarga de mantenimiento.
SOA es solo una frase de moda para implementar componentes detrás de los servicios web. Cuantos almacenes de datos tengas depende totalmente de ti. En algunos casos, tiene sentido tener datos particionados detrás de componentes individuales, y en otros casos todos los datos viven detrás de un servicio, y en otros casos muchos componentes que exponen las interfaces de servicio se conectan a la misma base de datos a través del protocolo de conexión de la base de datos. Abordar el problema al abordar el problema, no imponer restricciones artificiales.