Ankündigung

Einklappen
Keine Ankündigung bisher.

event bus mit PHP

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • event bus mit PHP

    Hallo Entwickler!

    In einem aktuellen Projekt entwickele ich eine Synchronisation zwischen zwei und vielleicht mal mehr PHP-Anwendungen.
    Die Systeme sollen möglichst entkoppelt bleiben, deshalb bietet sich eine Ereignis-orientierte Architektur an: Bei einer Änderung der Daten feuert das verursachende System ein Ereignis ab, dass von interessierten Systemen verarbeitet wird. Ich denke also an ein Publish-Subscribe-System, auch "event bus" genannt.

    Meine Frage an die Experten hier: Kennt ihr eine Event-Bus-Implementierung in PHP?

    Danke für die Hilfe!

    Beste Grüße,
    André


  • #2
    Du könntest per Web-Service Requests an die zu benachrichtigenden System schicken (Push) oder die System in regelmäßigen Abständen nachfragen lassen (pull)

    Kommentar


    • #3
      Danke für Dein Input!
      Ich brauche ein System, das die Ereignisse speichert und verteilt. Wie diese verteilt werden, ist mir zunächst nicht so wichtig.
      Beispiel:
      In System 1 wird ein Benutzer angelegt. Das System erzeugt ein Ereignis "Benutzer angelegt". Dieses Ereignis soll an alle Systeme weitergeleitet werden, die sich dafür interessieren. Das macht der Event Bus.

      Kommentar


      • #4
        Zitat von boehlke Beitrag anzeigen
        Ich brauche ein System, das die Ereignisse speichert und verteilt. Wie diese verteilt werden, ist mir zunächst nicht so wichtig.
        Letzteres ist doch das hauptsächlich wichtige ...?

        Beispiel:
        In System 1 wird ein Benutzer angelegt. Das System erzeugt ein Ereignis "Benutzer angelegt". Dieses Ereignis soll an alle Systeme weitergeleitet werden, die sich dafür interessieren. Das macht der Event Bus.
        Na also, dann ist doch wohl die „Verteilung“ der Events, die Benachrichtigung über ihr Eintreten, sehr wohl das wichtigste an der ganzen Sache.

        (Das „Melden“ des Events ist ja simpel, da muss System 1 ja nur über einen Request dem Event Bus ein mal Bescheid geben.)

        Zu überlegen wäre, ob der Event Bus ein dauernd laufendes Script/Programm sein muss, oder ob da „aufrufen“ beim Melden eines neuen Events reicht. Vermutlich ersteres, denn die Zustellung der Eventmeldung an alle anderen Systeme muss ja im Zweifelsfalle nicht augenblicklich klappen, ggf. reagiert eines dieser Systeme gerade nicht/ist ausgelastet, so dass die Nachricht kurze Zeit später noch mal gesendet werden muss.


        Per Google finde ich auf die Schnelle zum Thema nur folgendes, Ajax/PHP Distributed Event Bus - ich weiß nicht, wie AJAX-lastig dieser Artikel ist, und was davon du auf dein System übertragen kannst - aber schau mal rein.

        Kommentar


        • #5
          Zitat von ChrisB Beitrag anzeigen
          Zu überlegen wäre, ob der Event Bus ein dauernd laufendes Script/Programm sein muss, oder ob da „aufrufen“ beim Melden eines neuen Events reicht. Vermutlich ersteres, denn die Zustellung der Eventmeldung an alle anderen Systeme muss ja im Zweifelsfalle nicht augenblicklich klappen, ggf. reagiert eines dieser Systeme gerade nicht/ist ausgelastet, so dass die Nachricht kurze Zeit später noch mal gesendet werden muss.
          Das ist eine wichtige Überlegung. Alle Ereignisse müssen mindestens so lange gespeichert werden, wie es einer interessierte Partei nicht weitergeleitet wurde. Wenn eine empfangendes System z.B. bei der Verarbeitung des Ereignisses abschmiert oder wie Du geschrieben hast ausgelastet ist, dann muss das Ereignis aufgehoben werden.

          Zitat von ChrisB Beitrag anzeigen
          Letzteres ist doch das hauptsächlich wichtige ...?

          Per Google finde ich auf die Schnelle zum Thema nur folgendes, Ajax/PHP Distributed Event Bus - ich weiß nicht, wie AJAX-lastig dieser Artikel ist, und was davon du auf dein System übertragen kannst - aber schau mal rein
          Ja genau, dort wird das beschrieben, was ich mir vorstelle.

          Es sieht so aus, als müsste ich das selbst implementieren. Ich werde im ersten Schritt mit einem Singleton arbeiten, das die Ereignis-Verteilungslogik kapselt. Ich gehe erst einmal davon aus, dass die Systeme auf demselben Rechner liegen und dass der Event Bus beide direkt aufrufen kann.

          Ich schlage folgenden Aufbau vor:

          Ereignis-Erzeugung läuft etwa so ab:
          PHP-Code:
          require_once '.../EventBus.php';
          EventBus :: getInstance()->fireEvent(new UserCreatedEvent($uid$name)); 
          Ereignis-Empfang wird konfiguriert.
          listeners.ini
          Code:
          listener1.class = .../UserCrudListener.php
          listener1.eventtype0 = UserCreatedEvent
          listener1.eventtype1 = UserChangedEvent
          listener1.eventtype2 = UserDeletedEvent
          UserCrudListener.php
          PHP-Code:
          class UserCrudListener implements EventListener {
            public function 
          handleEvent(Event $oEvent) {
              
          $oEventSource $oEvent->getSource();
              echo 
          "Event fired by " $oEventSource->getID() . "\n";
              if(
          $oEvent instanceof UserCreatedEvent)
                ....
            }

          Der EventBus arbeitet mit serialize/unserialize, um nicht zustellbare Ereignisse zu speichern. "Zweitzustellung" ist zunächst nicht vorgesehen.

          Geht das noch einfacher?

          Grüße
          André

          Kommentar


          • #6
            Die ini-Datei sieht etwas seltsam aus. Dreh doch die Speicherung lieber um, also etwa so (Mal xml, damit es sich einfacher abbilden lässt)
            Code:
            <events>
              <event id="UserCreatedEvent">
                <listeners>
                  <listener class="UserCrudListener" />
                </listeners>
              </event>
            </events>
            Evtl. könnte/sollte man im Listener-Objekt direkt ein Callback hinterlegen, also so etwa:
            Code:
            <events>
              <event id="UserCreatedEvent">
                <listeners>
                  <listener class="UserCrudListener" function="onCreated" />
                </listeners>
              </event>
            </events>

            Kommentar


            • #7
              Eine XML-Konfigurationsdatei ist in dem Fall wirklich schöner. Danke.

              Kommentar


              • #8
                Das ist eine wichtige Überlegung. Alle Ereignisse müssen mindestens so lange gespeichert werden, wie es einer interessierte Partei nicht weitergeleitet wurde. Wenn eine empfangendes System z.B. bei der Verarbeitung des Ereignisses abschmiert oder wie Du geschrieben hast ausgelastet ist, dann muss das Ereignis aufgehoben werden.
                Fargt sich natürlich, wie lange man das Event vorhält. Um beim Beispiel zu bleiben:

                In System 1 wird ein Benutzer angelegt.
                Stellen wir uns ein zweites Ereignis vor:

                In System 1 wird dieser Benutzer wieder gelöscht.
                Jetzt ergibt sich bereits eine Abhängigkeit von vollständigkeit. Event 2 kann vielleicht noch ohne Wissen über 1 abgearbeitet (ignoriert) werden, aber anders herum ergibt sich schon ein ganz anderer Tenor. Auf der anderen Seite - wenn ein System lange nicht antwortet (und das ist wohl der einzige Weg, wie die Events bestätigt werden können) ergibt sich eine riesige Queue von Events, die auch noch für jeden Client separat gespeichert und zusammengestekllt werden muss.

                Alles nicht so trivial.
                --

                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                --

                Kommentar


                • #9
                  Zitat von nikosch Beitrag anzeigen

                  Jetzt ergibt sich bereits eine Abhängigkeit von vollständigkeit. Event 2 kann vielleicht noch ohne Wissen über 1 abgearbeitet (ignoriert) werden, aber anders herum ergibt sich schon ein ganz anderer Tenor. Auf der anderen Seite - wenn ein System lange nicht antwortet (und das ist wohl der einzige Weg, wie die Events bestätigt werden können) ergibt sich eine riesige Queue von Events, die auch noch für jeden Client separat gespeichert und zusammengestekllt werden muss.

                  Alles nicht so trivial.
                  Hmm, die Ereignisse müssen also in Ihrer vorgesehenen Reihenfolge verarbeitet werden. Noch ein Grund, ein fertiges System zu nehmen, das es nicht gibt.

                  Die Architektur ist einfach die sauberste, die mir einfällt. Lässt sich gut debuggen, erweitern und warten. Ich denke, es lohnt sich.

                  Kommentar


                  • #10
                    Wozu soll das ganze denn dienen?
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      Zitat von nikosch Beitrag anzeigen
                      Wozu soll das ganze denn dienen?
                      Es soll zur Datensynchronisation von zwei unabhängigen System dienen. Und für eine Single-Sign-On-Umsetzung.
                      Anforderung ist, dass
                      - die Systeme möglichst wenig verändert werden und
                      - möglichst unabhängig bleiben.

                      Dadurch, dass in den Systemen an relevanten Stellen nur ein Ereignis erzeugt und abgesetzt wird, sind nur punktuelle Änderungen nötig. Das Feuern der Ereignisse geht schnell, weil der Event Bus dazwischen hängt. Deshalb bleiben die Systeme unabhängig.

                      Ergibt das Sinn?

                      Kommentar


                      • #12
                        Warum gibts nicht einfach eine gemeinsame Ressource, bspw. eine gemeinsame Userdatenbank?
                        --

                        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                        --

                        Kommentar


                        • #13
                          Zitat von nikosch Beitrag anzeigen
                          Warum gibts nicht einfach eine gemeinsame Ressource, bspw. eine gemeinsame Userdatenbank?
                          SPOF, der alles lahm legt?
                          Wenn "nur" der Eventmanager lahm liegt können die anderen Systeme weitestgehend weiterlaufen, macht also durchaus Sinn.
                          VokeIT GmbH & Co. KG - VokeIT-oss @ github

                          Kommentar


                          • #14
                            Naja, das kann man sehen wie man will. Zumindest wäre hier die Datenkonsistenz gewährleistet. Was vielleicht wichtiger für den skizzierten Anwendungsfall ist, als die Verfügbarkeit, die man im Zweifel vielleicht technisch untermauern könnte (Spiegelung).
                            --

                            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                            --

                            Kommentar


                            • #15
                              Zitat von nikosch Beitrag anzeigen
                              Naja, das kann man sehen wie man will. Zumindest wäre hier die Datenkonsistenz gewährleistet. Was vielleicht wichtiger für den skizzierten Anwendungsfall ist, als die Verfügbarkeit, die man im Zweifel vielleicht technisch untermauern könnte (Spiegelung).
                              Die beiden Anwendungen sind unabhängig voneinander gewachsen und werden weiterhin unabhängig voneinander entwickelt (verschiedene Unternehmen arbeiten daran, wir und ein anderes Unternehmen).
                              Es sind sehr Datenbank-lastige Anwendungen. Die Benutzer/Mitarbeiter-Daten z.B. werden an vielen Stellen benutzt. Diese ganzen Zugriffe zu vereinheitlichen, wäre aufwendig und fehleranfällig.
                              Am wichtigsten jedoch ist -denke ich-, dass durch die klare, gute dokumentierbare Schnittstelle die beiden entwickelnden Unternehmen weitgehend unabhängig bleiben. Wir müssen wenig kommunizieren und können unser eigenes Süppchen kochen! Denn eins ist aufwendiger als alles andere: Verschiedene Ideen über große Distanz hinweg zu vereinheitlichen, wiederum meine Erfahrung.
                              Schließlich sind es die Ideen in einem Softwaresystem, die es ausmachen, oder? Wesentlich ist das, was zwischen den Codezeilen steht, die Denkweise. Und eine Denkweise zu ändern, ist sogar anatomischer Aufwand (Gehirn neu organisieren). Davor scheuen sich die meisten, meiner Erfahrung nach! Sie gehen lieber unter, siehe Microsoft-Anhänger

                              Kommentar

                              Lädt...
                              X