Estoy en una situación en la que puedo usar Service Fabric (localmente) pero no puedo aprovechar Azure Service Bus (o cualquier cosa "en la nube"). ¿Cuál sería el corolario de hacer cola / pub-sub? Service Fabric está permitido ya que se puede ejecutar en un contenedor local y es "gratuito". Otra infraestructura de mensajería de terceros, como RabbitMQ, también está fuera de la mesa (por el momento).

He construido sistemas usando un bus desarrollado localmente, construido sobre MSMQ y WCF, pero no veo cómo lograr lo mismo en SF. Sospecho que puedo hacer que los servicios SF usen un ICommunicationListener personalizado que exponga msmq, pero eso solo estaría disponible dentro del clúster (según yo lo entiendo). Puedo construir un HTTPBridge (en SF) delante de ellos para que estén disponibles fuera del clúster, pero luego perdería el desacoplamiento de por vida (el cliente puede llamar a un servicio, usar colas, incluso si ese servicio no está en línea en ese momento) ya que el puente en sí no se beneficiaría de ninguno de los aspectos de la cola.

Tengo algunas posibilidades, pero todas padecen alguna enfermedad que solo existe debido a la ciencia ficción, localmente. Además, el mismo código debe implementarse fácilmente en Azure SF completo (donde puedo usar ASB y este problema desaparece), por lo que no quiero construir dos sistemas separados solo por el lugar donde lo alojo en algunos casos.

Gracias por cualquier consejo.

0
Will Comeaux 16 oct. 2018 a las 16:44

2 respuestas

La mejor respuesta
  1. Puede crearlo usted mismo, por ejemplo así. Esto usa un BrokerService que distribuirá los datos del mensaje a los servicios y actores suscritos.
  2. También puede ejecutar una plataforma de cola en contenedores como RabbitMQ con volúmenes.

Al ejecutar el sistema de cola dentro del clúster, no introducirá una dependencia externa.

1
LoekD 16 oct. 2018 a las 14:14

El problema no es SF. El problema principal con su diseño es que está acoplando los requisitos arquitectónicos a las implementaciones. SF se ejecuta en la parte superior de VirtualMachines, al final, la única diferencia es que SF coloca los servicios en esas máquinas, al usar otra solución, tendría un Agente que implementa estos servicios allí o realiza una implementación manual. Los desafíos son los mismos.

De la descripción se desprende claramente que el requisito de su diseño es la necesidad de una cola de mensajes, el concepto de colas es el mismo, no importa si es Service Bus, RabbitMQ o MSMQ. Cada uno de ellos tendrá los fundamentos básicos de las colas con detalles específicos de cada implementación, algunos podrían agregar transacciones, algunos podrían implementar múltiples patrones, y así sucesivamente.

Si diseña basándose en una implementación específica, acoplará su solución a la implementación y hará que su solución sea difícil de mantener y enfrentar los desafíos que describió.

Soluciones como NServiceBus y Masstransit reducen muchos de estos acoplamientos de su código, y si cree que no son suficientes, puede crear su propia abstracción. Luego, usa configuraciones para vincular su lógica comercial a las implementaciones.

A pesar del consejo anterior, no le recomendaría que use diferentes soluciones por entorno, porque como se dijo anteriormente, cada solución tiene sus propias implementaciones y es posible que no se asimilen entre sí, por ejemplo, podría enfrentar problemas en producción porque desarrolló contra MSMQ. en entornos DEV y TEST, y cuando se implementa en Producción, utiliza ServiceBus, tienen diferentes limitaciones, como el tamaño del mensaje, el período de retención y su hijo.

Si está dispuesto a usar MSMQ, puede agregar MSMQ a las VM que ejecutan su clúster y conectarse desde sus servicios sin ningún problema. Eche un vistazo a este SO primero: ¿Cómo puedo usar MSMQ en Azure Service Fabric

1
Diego Mendes 16 oct. 2018 a las 17:04