service - software - ¿Por qué molestarse con el descubrimiento de servicios cuando el middleware orientado a mensajes hace el trabajo?
middleware ventajas y desventajas (2)
Me sale el problema que etcd / consul / $ lo que sea que estén tratando de resolver. Los consumidores de servicios necesitan hablar con los proveedores de servicios, un sistema distribuido sumamente fluido necesita un mecanismo para unirlos.
Sin embargo, el problema de "¿a dónde van los consumidores de servicios con sus solicitudes?" es antiguo y IMO se ha resuelto con MOM: middleware orientado a mensajes.
En MOM, la idea es que a los consumidores de servicios no les importa dónde viven los proveedores de servicios. Simplemente envían un mensaje y hacen que el bus de mensajería se encargue de enrutar el mensaje al consumidor correspondiente. Puede haber varios proveedores haciendo lo mismo (round-robin basado en cola) o proveedores versionados (/ v1 / request va a uno, / v2 / request va a otro).
Este es un patrón de integración simple y poderoso que desacopla completamente una interfaz de servicio de su implementación.
Y, sin embargo, veo esta extraña obsesión con el descubrimiento de proveedores de servicios, que parece crear un acoplamiento estrecho entre los consumidores y los proveedores (además de algunos otros anti-patrones también).
Entonces, ¿qué me estoy perdiendo aquí? TIA.
En MOM, todo fluye a través del autobús, por lo que podría convertirse en un cuello de botella. Con el descubrimiento del servicio, un consumidor busca un productor "una vez" (está bien, puede que tenga que volver a verificar después de un tiempo), y luego "directamente" (está bien a través de un proxy) habla con él.
O si prefiere frases pegajosas: puntos finales inteligentes y tuberías tontas frente a (creo que) puntos finales tontas y tuberías inteligentes .
Personalmente no veo a los dos como tampoco para este tipo de arquitectura. Puede usar el descubrimiento de servicios para ver qué servicios están disponibles en este momento y suscribirse a MOM para los eventos que sabe que estarán allí. Si no puede encontrar los servicios de los que depende, puede generar una alerta. No todas las mamás te avisan cuando no hay un editor para un canal.
También puede combinarlos en la forma en que el descubrimiento del servicio es donde se encuentran los servicios con los que desea ponerse en contacto directamente, por ejemplo, un almacén de datos que no realiza ningún trabajo, y seguir utilizando el MOM para suscribirse a eventos para los cambios que realizan otros sistemas. Tampoco todos los casos de uso encajan bien con la cola de trabajos, ya que algunas tareas deben resolverse de forma síncrona, y luego el descubrimiento del servicio es una excelente manera de tener un entorno dinámico.
Yo prefiero el MQ asíncrono, y creo que si lo hace bien, con balanceo de carga, redundancia, agrupación con lectores y escritores separados, etc. puede tener una gran estabilidad, escalabilidad y una forma estandarizada para que todos sus componentes se comuniquen.