Wer sich einmal gedacht hat, dass seine derzeitige zentrale Broker-Struktur im Unternehmen ein Flaschenhals darstellt und dieser Flaschenhals nicht einmal //echt hochverfügbar// und //skalierbar// ist, weiß, dass die Architektur nicht stimmig für die eigentlichen Anforderungen ist.
Mit "echt hochverfügbar" meine ich, dass "eine Kiste" auch mal ausfallen darf, der Broker, also der Message Service, immernoch erreichbar ist und seine Daten behält. Es gibt keine Downtime.
//Skalierbar// ist meiner Meinung nach jede Software, die nicht sofort bei Einsatz weiterer Ressourcen neue Lizenzverhandlungen nach sich ziehen. Vertikal zu skalieren und eine VM mit mehr Prozessoren auszustatten ist auch immer nur begrenzt möglich. Z.B. packt eine JVM auch nur sinnvoll bis zu 32gb in den Speicher. Danach greift das 64bit-Dilemma. Horizontal skalieren kann auch bedeuten weitere Broker einzusetzen, die sich nicht den Datenstand teilen.
Es muss also auch immer möglich sein horizontal zu skalieren. Z.B. Ressourcen für eine Instanz durch neue Nodes //nebendran//.
Man kennt solche Anforderungen aus den geclusterten Dateisystemen. Da "wirft" man einen Node in den Pool und der Pool erweitert sich. Ein Node fällt aus, die anderen Nodes, auf denen die Daten repliziert wurden, übernimmt. Das System heilt sich zudem selbst, indem es die Replikas neu verteilt.
Warum sollte das nicht auch für Message-Broker gelten?
Letzten Endes ist ein Message-Broker auch nur eine Art Storage-System. Die Persistenz der Daten muss hochverfügbar sein. Ein hinter dem Messaging-System liegendes Storage- oder Dateisystem darf nicht ausfallen. Es muss robust sein.
Eine andere Möglichkeit Queuing robust zu gestalten sind Directory-Services, die nicht auf einen zentralen Broker zeigen, sondern eben auf verteilte, näher bei oder in den Diensten liegenden, Message-Qeues. Eine gute Lektüre zu verschiedenen Architekturen und eben diesen Brokerless-Architekturen ist hier: http://zeromq.org/whitepapers:brokerless. Ganz oben zu sehen, die bekannte zentrale Messaging-Struktur, bei der eine Nachricht viele Roundtrips auf sich nimmt, bevor sie am Ziel ist.
tl;dr:
Der Punkt ist doch letztlich: Ein Messaging-System darf nicht ausfallen und klassische Ansätze, wie zentrales Messaging sind veraltet und die Daten sind unsicher. Wer heute sowas für sein Unternehmen implementiert und unternehmenskritische Dienste darauf aufbaut geht ein großes Risiko ein. Will dir jemand sowas verkaufen, sei sehr skeptisch.
