Apache ActiveMQ Artemis - Message Broker Vergleich

Von: Thomas Bayer
Datum: 22. Juni 2018
Aktualisiert: 6. Juli 2018

1 Architektur

Artemis verwendet nicht-blockierende IO Zugriffe für eine hohe Performanz bei vielen gleichzeitigen Consumer und Producer Verbindungen. Ob die Performanz von Artemis durch die Architektur wirklich um Größen besser ist, als z.B. die vom ActiveMQ erfährst du weiter unten im Abschnitt Performanz.

Der Broker unterstützt eine Vielzahl von Protokollen, kann im Cluster betrieben werden und ist über Interceptoren und Plugins erweiterbar.

JMS verwendet die Konzepte Queue und Topic um zwischen einer 1 zu 1 Zustellung und Publish/Subscribe zu unterscheiden. Artemis verwendet die Konzepte Adresse, Routing Type und Queue, mit denen JMS Queues und Topics nachempfunden werden können. Darüber hinaus erlaubt das Address Model von Artemis auch ein anderes Verhalten zu realisieren. Eine Nachricht wird bei Artemis von einem Producer an einen Endpunkt geschickt. Die Enpunkte heißen beim Artemis Adressen. Ein Routing Type bestimmt wie eine Nachricht an Queues geleitet wird. Über die Queues werden die Nachrichten dann den Consumern zur Verfügung gestellt. Der Routing Type Anycast sendet eine Nachricht an nur eine einzige aus einer Menge an Queues. Das Verhalten entspricht den Queues bei JMS. Der zweite Routing Type ist ein Multicast, der eine Nachricht auf alle zugeordneten Queues verteilt. Wird jede Queue von nur einem Subscriber konsummiert, dann entspricht dies den JMS Topics.

Die Abbildung unten zeigt ein Beispiel für das Routing von Nachrichten. Schickt ein Producer Nachrichten an den Endpunkt preise, so bekommt ein Consumer der Queue preise eine Kopie der Nachricht. Die drei Subscriber preise.subscriber.? bekommen jeweils eine Kopie der Nachricht.

Abbildung 1: Adresse, Routing Type und Queue

Ist ein Subscriber offline und kann aus diesem Grunde seine Nachrichten nicht abholen, so werden diese in seiner Queue zwischengespeichert. Im Gegensatz zu vielen reinen JMS Brokern kann die Queue des Subscribers und deren Nachrichten in der Konsole eingesehen werden.

Mit dem Modell aus Adresse, Routing Type und Queue kann das Verhalten von JMS hundertprozentig abgebildet werden. Artemis verwendet für die Queues ein Anycast und für ein Topic einen Multicast.

2 Messaging Protokolle

Über Plugins kann Artemis zusätzliche Messaging Protokolle bedienen. Ausgeliefert werden Plugins für die Protokolle:

• AMQP
• OpenWire ( ActiveMQ)
• MQTT ab Version 3.1
• STOMP
• STOMP over Web Sockets
• HornetQ ( Für bestehende HornetQ Clients).
• Core ( Artemis )

2.1 AMQP

Artemins unterstützt AMQP in der Version 1.0 und ist damit u.a zu .NET und Apache qpid Clients kompatibel. Andere AMQP Versionen bzw. Dialekte wie die Version 0-9-1 werden nicht unterstützt.

2.2 OpenWire

OpenWire ist das native Protokoll des ursprünglichen ActiveMQ Brokers. ActiveMQ Broker Installationen können durch Artemis ersetzt werden, ohne die Clients zu verändern, da diese weiterhin wie gewohnt über OpenWire mit dem Broker kommunizieren können. Der Screenshot der Artemis Console unten zeigt neben einer Verbindung zu einem Artemis Client auch Verbindungen zu ActiveMQ Consumern über das OpenWire Protokoll.

Abbildung 2: Artemis ( Core) und ActiveMQ Consumer in der Artemis Console

In der Praxis könnte sich die Migration von ActiveMQ nach Artemis etwas aufwendiger gestalten, da nicht nur das Protokoll sondern auch die serverseitigen Features eine Rolle spielen können.

3 Enterprise Messaging

Über einen JCA Connector kann Artemis als JMS Implementierung in Java Enterprise Server integriert werden und dort z.B. die Message Driven Beans (MDBs) Funktionalität anbieten. Der WildFly Application Server von JBoss verwendet Artemis als integrierten Message Broker für seinen JEE Stack.

4 Programmier Schnittstellen

Für die Entwicklung von Consumer und Producer stehen dem Programmierer die Schnittstellen JMS und Artemis Core API zur Verfügung.

4.1 JMS Support

Artemis unterstützt JMS in der Version 2.0. Da die Java Messaging Services nur eine Programmierschnittstelle auf der Basis von Java Interfaces definieren und kein Protokoll, findet die JMS Anpassung im Client statt. Mit dem Server kommuniziert der JMS Client über das Artemis Core Protokoll. Für die Umstellung eines JMS Clients auf Artemis muss die Initial Factory in den jndi.roperties umgestellt werden. Zum Beispiel von ActiveMQ:

auf Apache Artemis:

Zusätzlich müssen noch die Client Bibliotheken ausgetauscht werden. Der Code des Clients muss für eine Migration nicht angepasst werden.

4.2 Artemis Core API

Wem JMS zu umständlich ist, der kann direkt das Artemis Core API verwenden. Das Core API bietet auch einen größeren Funktionsumfang als das JMS API.

5 Mangement Console

Die Web Konsole für das Management des Artemis wird von einem integrierten Jetty Web Server bereitgestellt. Im Web Server läuft die Management Konsole, die API Beschreibung und die Dokumentation. Die Management Konsole basiert auf der modularen Java Management Konsole hawtio, die auch für andere Projekte wie z.B. dem JBoss Wildfly Server verwendet wird.

Der Screenshot unten zeigt die Hawtio Konsole mit dem Plugin für Artemis. Der Graph zeigt eine Übersicht der Beziehungen zwischen Broker, Queues, Consumer und Producer.

Abbildung 3: Artemis Console auf der Basis von Hawtio

Der Administrator kann Nachrichten einer Queue einsehen, löschen und verschieben.

Abbildung 4: Nachrichten Browser mit Funktionen zum Verschieben, Löschen und erneut Senden.

Nützlich ist das Editieren und erneute Senden einer Nachricht. Die ursprüngliche Nachricht wird nicht verändert sondern eine Kopie editiert und diese als zusätzliche Nachricht versendet.

Abbildung 5: Editieren einer Nachricht.

6 Management APIs

Die Verwaltung des Brokers kann neben der Mangement Console auch über ein Management API erfolgen. Queues anlegen, Parameter setzen und Statistiken auslesen kann man beim Artemis mit JMX, über REST mit Jolokia, dem Client Core API oder über JMS Nachrichten an die spezielle Managementqueue activemq.management.

7 Message Persistenz

Für das Zwischenspeichern von Nachrichten bietet Artemis die zwei Optionen: Ablage der Nachrichten in einer Dateisystem oder über JDBC in einer Datenbank.

7.1 File Storage

Das Speichern von Nachrichten auf der Platte ist der Default bei Artemis. Alle Operationen wie Nachrichten Persistieren oder Löschen werden als Schreiboperationen am Ende einer Datei realisiert ( Append Only ). Das Bewegen des Schreib-Lese-Kopfes der Platte wird dadurch möglichst vermieden und die langsame Positionierung des Kopfes bremst den Zugriff nicht. Artemis verwaltet selbst die Dateien und optimiert den Speicherplatz der Nachrichten ( Compaktion).

Für die Interaktion mit dem Dateisystem gibt es zwei Implementierung. Die Implementierung auf der Basis von Java NIO bietet gute Performanz und läuft auf jedem Betriebssystem. Für Linux gibt es eine optimierte Variante, welche die Linux Asynchronous IO Bibliothek nutzt.

7.2 JDBC Storage

Der JDBC Message Store wird zwar mitausgeliefert, ist aber noch unter Entwicklung. Empfohlen wird der File Store. Der JDBC Store wird nur entwickelt für die Benutzer, die einen JDBC Store verwenden müssen. Andere Gründe den JDBC Store einzusetzen gibt es nicht. Der File Storage ist um Größenordnungen schneller, als der JDBC Store.

8 Clustering

Mit Artemis lassen sich verschiedene Cluster Konfigurationen und Topologien realisieren um Lastverteilung und/oder Ausfallsicherheit zu erreichen.

8.1 Last Verteilung

Wie beim ActiveMQ Broker kann mit Artemis ein Store and Forward Netzwerk an Brokern gebildet werden. Mehrere Broker Instanzen werden dazu über Message Bridges verbunden. Über die Bridges werden Nachrichten zwischen den Brokern ausgetauscht. Eine Nachricht befindet sich zu einem Zeitpunkt immer nur auf einem einzigen Broker. Damit die Last sinnvoll verteilt werden kann, stehen die Broker in Kontakt und tauschen sich über ihre Clients und Subscriptions aus. Mit diesen Informationen können Nachrichten gezielt zu den Konsumern geleitet werden. Ein Netzwerk aus Brokern kann mit Client Side Load Balancing kombiniert werden.

8.2 Ausfallsicherheit

Ausfallsicherheit sorgt dafür, dass beim Ausfall eines Brokers alle mit ihm verbundenen Clients über andere Broker weiter arbeiten können, ohne dass Nachrichten verloren gehen.

Artemis erzielt die Ausfallsicherheit über eine Master Slave Topologie. Artemis verwendet für Master Slave bzw. Leader Follower die politisch korrekten Begriffe Live und Backup Server. Ein Live Server bedient alle Anfragen der Consumer und Producer. Die Backup Server erhalten Replikas der Nachrichten und halten sich für einen Ausfall bereit. Nach dem Ausfall des Live Servers übernimmt ein Backup Server die Arbeit. Nachdem ein Live Server wieder zur Verfügung steht kann der Cluster wieder automatisch auf den Live Server wechseln und der Backup Server stellt seine Arbeit wieder ein.

Die Backup Server können entweder über eine geteiltes Medium ein oder über Replikation mit Daten versorgt werden.

Die vom Artemis für die Ausfallsicherheit genutzt Master Slave Topologie hat gegenüber einer Multimaster oder Masterless Architektur wie sie z.B. Apache Kafka einsetzt die folgenden Nachteile:

• Die Backup Server übernehmen keine Arbeit und tragen nicht zur Gesamtperformanz des Clusters bei. Nicht für die Antwortzeiten und auch nicht für die Speicherkapazität.
• Es wird zwischen den zwei Rollen Master und Slave unterschieden. Beim Multimaster sind alle Knoten gleich.
• Beim Ausfall des Masters müssen die Clients auf einen Slave umstellen. Dies kann schief gehen, da vielleicht die Clients nicht mit der Slave Adresse versorgt wurden oder das Routing im Netzwerk nicht konfiguriert ist. Beim Multimaster werden ständig alle Knoten mit einbezogen so dass es beim Ausfall eines Knotens weniger Überraschungen gibt.

Eine Multimaster Architektur ist mit dem JMS API ohne weiteres nicht möglich. Daher passt der Live Server und Backup Server Ansatz zum Produkt.

Es wird beim Artemis nicht garantiert, dass bei einem Failover keine Nachrichten oder Bestätigungen verloren gehen. In-flight Nachrichten oder Acknowledgements können bei einem Ausfall betroffen sein. Beim Failover wurde bewußt auf eine 100 prozentige Statereplikation aus Performanzgründen verzichtet.

8.3 Service Discovery

Mit dem Dynamic Discovery Feature können Clients ihre Server im Netz finden. Als Broadcast Technologie kann UDP oder JGroups verwendet werden. Service Discovery ist besonders in Verbindung mit einem Cluster interessant.

9 Installation

Artemis ist mit der Programmiersprache Java realisiert und kann somit auf einer Vielzahl von Betriebssystemen eingesetzt werden. Besonders unterstützt werden Linux und Windows.

Nach dem Entpacken der Artemis Distribution muss ein Broker erstellt werden. Dazu wird in der Kommandozeile eine Create-Funktion aufgerufen. Nach wenigen Sekunden steht eine Broker Instanz zur Verfügung, die auf das gepackte Verzeichnis verweist. Mehrere Broker Instanzen können sich eine Installation teilen. Diese Aufteilung erleichtert die Migration auf neue Artemis Versionen.

Artemis gibt es auch als OSGi Bundle welches z.B. auf Apache Karaf oder ServiceMix ausgeführt werden kann.

Abbildung 6: Start einer Artemis Instanz von der Kommandozeile

10 Konfiguration

Die Konfiguration von Artemis erfolgt über eine zentrale XML Datei. Dort können z.B. neue Queues angelegt, Quotas gesetzt oder Protokolle konfiguriert werden. Die Konfigurationsdatei wird ständig überwacht und Änderungen werden ohne Neustart aktiv. Das Hot-Reload Feature ist besonders bei der Entwicklung und dem Erproben von neuen Konfigurationen hilfreich.

11 Spring Integration

Ein eingebetteter Artemis Server kann über eine Spring Konfiguration gestartet werden. Im Gegensatz zum ActiveMQ ist die Artemis Konfiguration keine Spring Konfiguration. Es ist davon auszugehen, dass Artemis nicht so einfach wie der ActiveMQ über Spring erweitert und verändert werden kann.

12 CDI Integration

Artemis kann als standalone oder embedded Broker in CDI integriert werden.

13 Sicherheit

Artemis ist in die Java Plattform integriert und unterstützt eine Authentifikation über JAAS und standardisierte Login Module. Das Sicherheitskonzept ist rollenbasiert und feinkörnig. Für einzelne Queues können Lese, Schreib und Admin Rechte an Gruppen vergeben werden. Selbstverständlich kann die Kommunikation mit TLS verschlüsselt werden.

14 Performanz

Um ein Gefühl für die Performanz des Artemis Brokers zu bekommen, habe ich einen einfachen Lasttest durchgeführt und die Bandbreite in Nachrichten pro Sekunde gemessen. Der Performanztest ist kein Ersatz für ein korrekt durchgeführten Benchmark, sollte aber für eine Idee über die Größenordnung ausreichen.

Beim Test habe ich gemessen, wie lange der Broker benötigt, um 100.000 kleine Nachrichten von einem Producer zu empfangen und zu persistieren. Ein einfaches Testprogramm habe ich einmal mit dem ActiveMQ und einmal mit dem Artemis durchgeführt.

Aufgrund der neueren Architektur und der asynchronen Verarbeitung von Artemis habe ich erwartet, dass Artemis mindestens um den Faktor 3 schneller fertig ist als ActiveMQ. Vielleicht nicht so schnell wie RabbitMQ oder Apache Kafka, aber mindestenz im Bereich von 10.000 Nachrichten pro Sekunde.

Tatsäch gemessen habe ich 3.318 Nachrichten pro Sekunde beim ActiveMQ und 3.291 beim Artemis. Das Ergebnis war für mich eine Überraschung. Artemis bewegt sich trotz der neuen Architektur in der Größenordnung des ActiveMQ Brokers und war im Test sogar etwas langsamer. Vielleicht sind die Einschränkungen des JMS APIs für beide Broker der limitierende Faktor.

Dreitausend Nachrichten pro Sekunde sind für die meisten betriebswirtschaftlichen Anwendungen mehr als genug. Besonders bei einem Broker, der Nachrichten puffert. Für Internet of Things oder Anwendungen in der Industrie 4.0 fehlen beiden Brokern die Reserven.

15 Test Unterstützung

Artemis eignet sich für automatisierte Unittests. Der Broker kann embedded in einem Test gestartet und gestoppt werden.

16 Migration vom ActiveMQ zu Artemis

Artemis unterstützt mit OpenWire das Message Protokoll des ActiveMQ. Das erlaubt es den Broker ohne die Änderung von Clients auszutauschen. Bei einer Migration ist zu beachten, dass bei einer ActiveMQ Installation vielleicht Funktionen verwendet wurden, die der Artemis Broker noch nicht bietet. Das Artemis Entwickler sind dabei, alle Funktionen, die der ActiveMQ bietet auch für Artemis bereitzustellen. Stand Sommer 2018 ist dies aber noch nicht erreicht.

17 ActiveMQ oder Artemis?

Die hier getroffenen Aussagen beziehen sich auf den Stand Sommer 2018. In nächster Zukunft könnte alles wieder anders aussehen.

Artemis bietet momentan die folgenden Vorteile:

• Artemis bietet ein Master/Slave Clustering vergleichbar mit dem Pure Master Slave der alten ActiveMQ Versionen. Wer momentan eine aktuelle ActiveMQ Version einsetzt hat das Problem, dass nur ein Shared Master Slave oder ein Cluster auf der Basis der LevelDB angeboten wird. Das Clustering mit der LevelDB wird aber nicht mehr weiter entwickelt. Wer Failover einsetzen möchte, sollte sich Artemis definitiv ansehen.
• Artemis bietet eine bessere Performanz. Allerdings schafft der ActiveMQ auch mehrere tausend Nachrichten pro Sekunde zu verarbeiten. Für die meisten Anwendungen reicht das aus.
• Artemis verfügt über eine modernere Architektur und Codebasis.

Wer momentan den ActiveMQ einsetzt und zufrieden ist, kann zunächst bei ActiveMQ bleiben. Wer jetzt Messaging neu einführen möchte, dem würde ich Artemis empfehlen, sofern er dort alle benötigten Funktionen findet.

18 Apache Artemis oder Kafka?

Apache Kafka besitzt eine modernere Architektur, bei der der Broker wesentlich einfacher realisiert ist als bei den bisherigen Messaging Lösungen. Consumer und Producer sind leichtgewichtiger und bereits gelesen Nachrichten können beliebig oft erneut gelesen werden. Gerade das erneute Lesen ist eine Schlüsselfunktion, die beim Messaging schmerzhaft vermißt wurde. Beispielsweise kann ein Consumer nach dem Auftreten von Fehlern Nachrichten erneut lesen, ohne den Betreiber des Producers bitten zu müssen, die Nachrichten irgendwie erneut zu senden. Kafka ermöglicht auch die zeitlich unbegrenzte Ablage von Nachrichten. Des weiteren wird Kafka nicht durch das eingeschränkte JMS API limitiert.

Artemis ist im Gegensatz zu Kafka ein richtiger Enterprise Broker. Artemis unterstützt JMS und läßt sich als Broker über JCA in einen Application Server integrieren. Der Zugriff auf Queues kann bei Artemis in einer Transaktion erfolgen. Konsistenz in einer verteilten Anwendung ist mit Artemis leicht herzustellen. Die Garantien At most once, At least once und Exactly once sind mit Artemis einfach zu erreichen. Mit Kafka sind ebenfalls weitreichende Garantien möglich, dafür muss aber einges bei der Entwicklung beachtet werden.

19 Fazit

Artemis ist ein Enterprise Broker mit JMS Support und der Möglichkeit über JCA in einen Application Server integriert zu werden. Zuverlässigkeit kann durch Failover über einen Cluster erzielt werden. Für die Lastverteilung oder eine geographische Verteilung der Broker kann ein Netzwerk aus Knoten aufgebaut werden.

Die Architektur des Artemis ist moderner und leistungsfähiger als beim ActiveMQ. Noch fehlen aber nützliche Features, die der ActiveMQ Broker bietet.

Apache Artemis ist definitiv die Wahl, wenn es um JMS und Enterprise Messaging geht. Wer auf JMS verzichten kann könnte auch einen Blick auf Apache Kafka vor einer Entscheidung für Artemis werfen.

Ob es Artemis schafft, den in die Tage gekommenen ActiveMQ abzulösen und die selbe Popularität zu erreichen, muss die Zukunft zeigen.