peXi - Zwischenstand Prototyp

nospam@example.com (Marc Jakubowski) — Mon, 16 Feb 2009 10:29:00 +0100

In den vergangenen Tagen habe ich mich mit der Implementierung eines ersten Prototyps beschäftigt.

Versuchsaufbau

Das Szenario ist zunächst so trivial wie möglich, zeigt jedoch bereits an welchen Stellen Probleme auftreten werden, so dass man diese schon frühzeitig bei der Architekturüberlegung berücksichtigen kann.

Im Prinzip sieht das Szenario wie folgt aus:

Sender schickt Message an Middleware Server
Server nimmt Message entgegen und legt sie in eine Queue
Engine holt Message aus Queue und schickt sie an Empfänger
Empfänger nimmt Message entgegen und speichert sie im Filesystem

Dieser einfache Aufbau beschränkt sich also erst einmal auf die asynchrone Verarbeitung von Testnachrichten vom Sender über die Middleware bis zum Empfänger.
Die verwendeten Komponenten werden im Folgenden näher beschrieben:

Komponenten

Sender

Script, welches über den Browser aufgerufen werden kann und dann per Zend_Http_Client beliebig viele HTTP-Post Nachrichten an den Middleware Server sendet. Der Einfachheit halber wird lediglich der Parameter "message" mit dem Wert von uniqid() gesendet, also noch keine "sinnvolle" Nachricht.
Die Nachrichten werden stumpf rausgefeuert, ohne speziell auf die Antwort des Servers zu reagieren.

Server

Script, welches vom Sender angesprochen wird und die gepostete Nachricht entgegen nimmt. Der Nachrichteninhalt wird in einer Queue gespeichert, welche eine InnoDb Tabelle mit den Feldern "id", "message" und "status" ist. Bei erfolgreichem Speichern in die Queue wird ein HTTP Response Code 200 an den Sender zurückgeschickt, ansonsten ein Fehlercode.

Engine

Die Engine ist die Hauptkomponente der Middleware und besteht aus einem langlaufenden PHP-CLI Script (per "while (true) { ... }"), welches kontinuierlich die Queue abfragt, ob neue, unverarbeitete Nachrichten vorhanden sind.
Ist dies nicht der Fall, wartet das Script 5 Sekunden vor der nächsten Abfrage.

Sind neue Nachrichten vorhanden, wird eine Beliebige selektiert und wiederrum per Zend_Http_Client als HTTP-Post Nachricht mit den Parametern "id" und "message" an den Receiver gesendet. Je nach Response Code wird die Nachricht in der Queue als "verarbeitet", "fehlerhaft" oder "neu" (zum erneuten Verarbeiten) markiert.

Receiver

Script, welches von der Engine angesprochen wird und die gepostete Nachricht entgegen nimmt. Der Nachrichteninhalt wird in einer Textdatei im Filesystem mit dem Namen der "id" und Inhalt der "message" abgelegt. Sollte die Datei wider Erwarten bereits existieren wird ein Fehlercode zurückgesendet.

Analyse

Da ich (noch) auf einem Windows Rechner entwickle, sind Aussagen über Performance nur schwer zu treffen, zunächst ging es mir um den reibungslosen Ablauf des Prozesses.

Der lansamste Teil in diesem Versuchsaufbau ist das Versenden der Nachrichten per HTTP-Post, da für jede eingehende und ausgehende Nachricht der Middleware HTTP Verbindungen zu Scripten aufgebaut werden müssen.

Da die Engine ein langlaufender Prozess ist, kann es passieren, dass je nach Konfiguration und Anzahl der verarbeiteten Nachrichten das Memory Limit erreicht wird.

Um eine parallele Verarbeitung mit mehreren Prozessen zu simulieren, habe ich testweise bis zu 6 Instanzen des Engine Scripts gestartet wobei sofort das Problem von Race Conditions auftrat.

Schlussfolgerungen

Benutzung einer Unix Umgebung, um bessere Aussagen über die Performance treffen und Forking nutzen zu können.

Testen von anderen Methoden zur Nachrichtenübertragung, z.B. per "cUrl", persistente HTTP Verbindungen und Versenden von mehreren Nachrichten auf einmal.

Abarbeitung der Queue mit Verwendung von Transaktionen und Locking um Race Conditions zu vermeiden.

Parallele Verarbeitung der Messages durch Prozess Forking.

Weiteres Vorgehen

Als nächstes werde ich synchrone Nachrichten implementieren, das heißt, dass die Nachrichten nicht in der Queue gespeichert werden um von der Engine abgearbeitet zu werden, sondern dass das Server selbst die Verarbeitung auslöst, um die Antwort des Empfängers an den Sender zurückgeben zu können.

Dazu muss der Verarbeitungsteil, der bislang fest in der Engine implementiert ist ausgelagert werden, damit dieser direkt vom Server Script aufgerufen werden kann. Dies hat außerdem den Vorteil, dass eine Umstellung der Engine auf Forking einfacher zu implementieren ist, da dann jeder nebenläufige Prozess eine eigenständige Verarbeitung auslöst.

Falls jemand weitere Ideen zur Optimierung hat, bitte per Kommentar mitteilen

PHP Message-orientierte Middleware

nospam@example.com (Marc Jakubowski) — Fri, 13 Feb 2009 11:32:00 +0100

Bei meinem früheren Arbeitgeber hatte ich die Gelegenheit Projekte mittels SAP Exchange Infrastructure zu realisieren.
Bei dem Produkt handelt es sich um eine in Java und ABAP implementierte Message-orientierte Middleware, die es ermöglicht eingehende Nachrichten der verschiedensten Formate in andere Formate zu transformieren und an beliebige Empfänger zu verteilen, also ideal zun Datenaustausch in einer heterogenen Umgebung.

Da ich von den Möglichkeiten dieser Software ziemlich beeindruckt war, es jedoch nicht realistisch ist, sich so ein Teil zu lizensieren, schaute ich mich nach ähnlichen Lösungen um. Da gäbe es zum Beispiel IBM WebSphere, welches für den privaten Gebrauch aber ebenso ausscheidet.

Message Queues

Bei reinen Message Queues sind JMS und Apache ActiveMQ als OpenSource Lösungen die verbreitetsten.

Die Suche nach in PHP implementierten Middlewares oder Message Queues war sehr ernüchternd. Zwar gibt es zu den oben genannten und anderen Lösungen oft Bibliotheken, um mit PHP darauf zugreifen zu können, den Aufwand diese Systeme aufsetzen zu müssen erspart dies aber nicht.

Die einzig brauchbare PHP Message Queue scheint dropr zu sein, welche bereits bei Jimdo im Produktiveinsatz verwendet wird um Nachrichten zwischen global verteilten Servern auszutauschen.

Wenn jemand weitere brauchbare Lösungen kennt, bitte einen Kommentar hinterlassen.

Das Rad neu erfinden

Als Entwickler reizt es mich jetzt natürlich selbst in PHP eine entsprechende Middleware zu entwickeln
Ob dies nun sinnvoll ist oder nicht, sei mal dahingestellt, von der technischen bzw archtitekturellen Seite ist es auf jeden Fall eine interessante Herausforderung.
Im Prinzip soll sich der Funktionsumfang an der SAP XI orientieren, wobei es wohl etwas vermessen wäre die Komplexität des Systems genau so abbilden zu können, von daher wird es eine ziemlich abgespeckte Variante werden.

Funktionalität

Ein ausgearbeitetes Konzept gibt es noch nicht, wird es vielleicht auch nie geben, da ich es iterativ angehen werde um nach und nach den Komplexitätsgrad zu erhöhen.
Einen groben Überblick der zu bedenkenden Komponenten gibt es im Wiki zum Google Code Projekt peXi - PHP Exchange Infrastructure.

Im Groben soll das System später einmal folgendes können:

Synchrone/Asynchrone Verarbeitung
Unterstützung vieler Nachrichtenformate/Protokolle
(Zwischen-/Persistente) Speicherung in Queues
Senden an beliebige Empfänger
Transformation von Nachrichten in Zielformat
Erstellen von Szenarien
Abbildung von Systemlandschaften

In dem Zusammenhang gilt es natürlich auch noch folgende Themen zu beachten:

Skalierbare Architektur
Performanceoptimierung
Sicherheit / Authentifizierung / Zugriffskontrolle
Monitoring
Usability der Konfigurationsoberfläche

Das reicht dann auch erstmal

Entwicklung eines Prototyps

Als erstes gilt es einen simplen asynchronen Prototyp zu erstellen, der aus diesen Komponenten bestehen wird:

Sender: Sendet HTTP Messages an Server
Server: Empfängt Messages und speichert diese in einer Queue
Engine: Daemon, der periodisch die Queue nach neuen Messages checkt um diese an Empfänger zu schicken
Empfänger: Nimmt Messages entgegen und speichert diese im Filesystem

Ein erster rudimentärer Test funktionierte bereits. Nun gilt es die einzelnen Komponenten Stück für Stück zu isolieren und auzubauen und eine ordentliche Architektur zu entwickeln.

Hilfe und Ideen sind gerne willkommen

Octavians Nutwerk - Middleware