Add akka-like messaging

[prolic]

Add akka-like messaging

[codeliner]

Question is: The concept of Akka wouldn't work in PHP's shared nothing architecture, right?
So we would need something like amp or reactPHP to handle incoming requests in a non-blocking way and keep the PHP process alive and then pthreads for the Akka stuff. Am I right?

Or can we use ZeroMQ to create a lightweight link between a prooph/micro service (normal PHP process, global state is reset after request) and a process manager (long-running stateless PHP process)?

[bweston92]

How would these aggregates talk, remembering everything is eventually consistent?

[prolic]

I don't know yet. Akka works with threads and locks them.

[max-voloshin]

I doubt we should implement Akka in PHP, but I am sure we can use core principles of Actor Model in PHP software.

Our team currently use in-house solution for background messaging processing with concurrency control (e.g. aggregate consumes only one message at the same time) and scheduling feature. We use PHP daemon process with child processes and DB for storing messages.

In the near future, we plan to rethink and summarize our experience via open source toolkit: REMBO (yeah, it's empty repo now, but you can "Watch" for updates :) ). Most likely we will optionally use mentioned AMP for better performance and scalability.

Draft:

$system = new ExampleSystem();
$message = new ExampleMessage();
$consumer = new ExampleConsumer();

$system->produce($message);

$system->produce(new ScheduleCommand($message, When::once(new DateTimeImmutable('2017-01-01'))));
$system->produce(new ScheduleCommand($message, When::after(3)->seconds()));
$system->produce(new ScheduleCommand($message, When::every(5)->minutes()));
$system->produce(new ScheduleCommand($message, When::every(10)->hours()->since(new DateTimeImmutable('2017-01-01'))));
$system->produce(new ScheduleCommand($message, When::every()->days()));

$system->produce(new DirectMessage($message, $consumer));

$system->produce(new ScheduleCommand(new DirectMessage($message, $consumer), When::after(10)->minutes()));
$system->produce(new ScheduleCommand(new DirectMessage($message, $consumer), When::every()->hours()));

In this case $consumer implements AddressableConsumer interface that allows using this consumer in DirectMessage. This will lead to consuming this message via this consumer in a background process. Bonus: we can rely on "one message at the same time" control.

P.S. BTW I think rembo and prooph will perfectly complement each other on DDD/Microservices field in the future.

[codeliner]

@max-voloshin Looks very interesting. Watch configured for REMBO ;)

but I am sure we can use core principles of Actor Model in PHP software.

I guess, I need to read more about the Actor Model. Anyone aware of a good blog post or something?

rembo and prooph will perfectly complement each other on DDD/Microservices field

👍

[max-voloshin]

I guess, I need to read more about the Actor Model. Anyone aware of a good blog post or something?

https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

[codeliner]

nice, thx 👍

[codeliner]

short update: I'm still in the process of learning and thinking more about the Actor Model.
Besides that @sandrokeil and me are playing with different ways to call other php processes.

We started with Symfony Process which simply uses exec under the hood.

But there are much better options of course. One of these options is the fast-cgi-client written by @hollodotme . Here is a very interesting block post: https://hollo.me/php/experimental-async-php-volume-2.html

We're trying to run an Actor insight a PHPFastCGI Daemon by @AndrewCarterUK

The Actor should run in an event loop (amp)

Now we want to test if we can send a message from one PHP process to this Actor with the help of the fast-cgi-client.
On the other end the PHPFastCGI Daemon would turn that message into a PSR-7 request and pass it to a handler (the mailbox of the Actor) which also runs in the amp event loop.
Once the message (PSR-7 request containing a prooph message in the body) is queued the Actor can pull that message from the queue, process it and create new messages which are again sent to an Actor via the fast-cgi-client (it supports async messaging of course)

[codeliner]

@max-voloshin

In this case $consumer implements AddressableConsumer interface that allows using this consumer in DirectMessage.

I'd be very interested how this works under the hood. Can you provide more details?

[max-voloshin]

I'd be very interested how this works under the hood. Can you provide more details?

@codeliner, looks like my previous comment was a bit premature, so it took some time to describe overall concept :) I would appreciate you read "Initial thoughts about Reliable Embedded Message Broker for PHP" and give feedback about it.

short update: I'm still in the process of learning and thinking more about the Actor Model.
Besides that @sandrokeil and me are playing with different ways to call other php processes.

Any update on your experiments?

@prolic, I noticed your comment in prooph/event-store#267 (comment):

I am plannig on providing an akka like actor to the php world. This will be highly experimental in the first development stage.

May you explain your expectations from this solutions? Do they match with rembo's description at some point?

@codeliner, @prolic it would be great if we had overlapping goals and expectation, so we could join our efforts.

[prolic]

I am thinking about using an implementation of the gossip protocol in php and socket connections for communications across processes / servers. But there is nothing done yet, and we are working on releasing the new event-store v7 and related components, so any discussions about how, what, ... has to be delayed, until we have to time to address this again.

All I can say now, I have some plans, I know a lot of people think "you can't do this in PHP" - and I'll prove them wrong :-) I will have something in very early alpha stage maybe in six months. Until then - it's time to work on current prooph components.

[codeliner]

@max-voloshin very interesting blog post about Rembo. Looking forward to working code. With event sourcing we take a slightly different route. Our write model only produces messages/domain events (no application state) and the event store acts as a "inbox repository". the new projection features included in the upcoming event store v7 release can be used to pull messages from the event store and forward them to some workers (among other usage scenarios).
If you have a first open source version of Rembo available, please let me know and we think about integrations. In the meanwhile we need to focus on prooph components marketing. We want to increase visibility and therefor provide more how-tos about the things we already have.

So also no real updates on the Actor Model experiments. We had to stop them for now due to huge amount of other work on the desk. I'm still very interested in the topic but I do think that I need to focus on other topics first. I guess the actor model can become very complex to manage in a production system. For now I'll favor our new prooph/micro approach:
One php-fpm pool and a lightweight code base for one aggregate type, because one transaction should only be handled and should only effect one aggregate.
Then we'll use the event store like described above to asynchronously build read models and talk to other aggregates. That is a more or less simple set up and a powerful solution, too. We want to provide a management UI to make prooph/micro even more easy to use, but that is a different story.

[codeliner]

Just found kraken-php framework, which is actor-based and ships w/ all basic functionality that you need for event sourced actors (addressable containers, message channels, messagebox, supervision, ...)
I think kraken-php is experimental, but at least a demo of event sourced actors in PHP would be nice.

[prolic]

For now this is out of scope of micro, closing therefore.