Tendrás solo servicios autónomos.

Question

Uno de los principios de SOA es: " Los servicios son autónomos " Tengo 2 servicios. El Servicio A depende del Servicio B. El Servicio A no puede servir a los clientes a menos que el Servicio B esté en funcionamiento. ¿Violaré el principio aquí?

O si autónomo debe significar "desacoplado", ¿cumplo con el principio si tengo un dispositivo a prueba de fallos (digamos otra instancia del Servicio B que se ejecuta en otra parte que está conectada si la instancia principal está inactiva)? Esto puede satisfacer mis requisitos de disponibilidad, pero no estoy seguro de cómo esto puede reducir mi dependencia. Sí, la prueba de fallos podría ser incluso el Servicio C de un tercero y, en este caso, puedo mejorar mi autonomía.

O el principio solo significa que los servicios deben diseñarse como " fifedoms " con interfaces bien definidas para obtener los datos en & amp; fuera. Sin embargo, algunos gurús parecen pensar que necesitas incluso almacenar estos datos que recibes internamente para reducir la dependencia y mantener tu autonomía ...

¿Es un error si tuviera que tratar los servicios como componentes con mensajes? :)

¿Pensamientos?

Answer 1

Consulte esta publicación en Principios de SOA . También vea La constelación fractal de servicios autónomos .

" Los servicios deben implementarse, administrarse y versionarse independientemente de otros servicios y / o aplicaciones que dependen de ellos. "

Autonomía no significa aislado o completamente independiente.

En su lugar, puedes tener una " constelación " de dos servicios. Sí, dependen unos de otros. No, A no se rompe cuando B se mueve o se actualiza. Tampoco A se rompe cuando se cambian las partes internas sin interfaz de B.

De manera similar, desde el punto de vista de B, y la actualización a las partes internas de A no cede a los cambios en la interfaz de B y las partes internas.

La API evoluciona de forma independiente. El esquema, los mensajes y las implementaciones son independientes. Simplemente se refieren entre sí.

" El Servicio A no puede servir a los clientes a menos que el Servicio B esté en funcionamiento " - no te preocupes El servicio A tampoco puede servir a los clientes si está fuera de servicio. El mantenimiento del servicio es un problema. No importa si es B (de lo que A depende) o A. La dependencia no tiene nada que ver con que A o B sean confiables o estén disponibles.

Sí, los servicios tienen interfaces bien definidas e independientes. La implementación de A depende de B, pero la interfaz no.

---

Editar.

" algunos gurús parecen pensar que incluso necesitas almacenar estos datos que recibes internamente para reducir la dependencia y mantener tu autonomía ... "

No puedo ver el punto. Si A depende de B, y el algoritmo de B cambia, la copia de A de los datos de B es, en efecto, antigua. Depends-on generalmente significa una relación real, activa, hasta la transacción.

El problema es que B puede ser lento, lo que hace que A sea lento, lo que hace que la aplicación que usa A sea lenta. Eso es un fastidio. Pero eso no es un llamado para romper las reglas de autonomía y tener a A para mantener un caché secreto de datos antiguos de B.

Answer 2

Su autonomía solo se ha mejorado al tener un servicio de respaldo. ¿Qué pasa si los servicios B y C caen? Entonces su servicio se cae. Puede mejorar su autonomía (y su rendimiento) aún más si almacena en caché los resultados de los servicios externos. De esa manera, si B y C caen, aún puede dar servicio a algunos de sus clientes con resultados en caché. Sin embargo, mientras confíe en servicios de terceros, nunca logrará el 100% de autonomía.