I am just getting started with Akka.Net, I want to use it to create micro services, which I'm also just getting started with as well. I've read that one of the best practices with micro services is have them be as isolated as possible. So don't shared anything between the services, such as code or data storage. Akka.net uses classes/messages to communicate, so those class would need to be shared among all the services, which would introduce some form of coupling. I don't see how I can have a fully decoupled set of services using akka.net, unless i'm gonna pass a primitive datatype, such as a string (as json) and then deserialize it to objects in each service. but then I lose all the validation that a class would offer. What are my options to using akka.net to create a loosely coupled micro service architecture system?
If this is the case, you are free to use different message types for each internal actor system. The only things that would need to be shared are the messages that transfer data between the microservices themselves.
hi guys, is there any "obvious" reason why an actor could terminate a method (or finishes a message processing) when invoking an await Method(); ? I trying to figure that out but so far I had no luck. I call an I/O operation inside a Receive<RequestMessage> and I can't see any log line or anything going on, really weird. It just start processing the next message in the mailbox
I have used both Receive Async and PipeTo and both print when the message starts to be processed but nothing else
`private void Subscribed()
{
Logger.Debug($"{Self.Path.Name} node is ready");
{
Logger.Debug($"{Self.Path.Name} node is ready");
Receive<RequestMessage>(e => ProcessRequest(e));
Receive<ResponseMessage>(p => SendResponseBack(p));
}
private void ProcessRequest(RequestMessage requestMessage)
{
Logger.Debug($"{Self.Path.Name} started request processing");
_aDependency.ProcessAsync(requestMessage.Data)
.ContinueWith(e => new ResponseMessage(e.Result), TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously)
.PipeTo(Self, Context.Sender);
}
private void SendResponseBack(ResponseMessage response)
{
Context.Sender.Tell(response, Self);
Logger.Debug($"{Self.Path.Name} finished request processing");
}`
that's the code and I'm not entirely sure what am I doing wrong. The Subscribed method gets invoked when the node joins the cluster and I can see that happening. Then the started processing log line is also printed. But immediately after the next message starts. The operation should take 2 seconds so I should expect to see the "finished" at some point but I see nothing. Also there is nothing related to the logging printed by the dependency inside the method which makes me think that the ProcessAsync simply doesn't start
you can ignore all of the above
And it does not support custom fields/properties inside exceptions
@alexvaluyskiy Exception does indeed have a public parameterless constructor. However it's TargetSite field is of MethodBase type, which in turn has a protected constructor. Guess this might be it, however I didn't dig further once I've realized that jamming the entire Exception object in a message sent over the network isn't really something that I want to do.
Do you guys know of any issue when getting asking for the currentTopics? Once I have a publisher joining a cluster I need to send two messages to check that a specific topic is available to publish. I have added a retry mechanism but that doesn't help. I actually need to send two messages to that actor to make this to work
i'm working with Cluster Sharding
I have the example working, but in my project, it is not distributing the work on to my other worker node
hmm, do I have to create a cluster sharding region on each worker?
hmm, i did that, now the work that was being done on my command node has moved to my worker node... and it's stopped executing on my command node
@Youenn-Bouglouan Thanks for your response, I did not want to have any code shared between the micro services, as that shared code will introduced some form of coupling between the services. If I must share the messages that's passed between each actor system/ services, how would I deal with message versioning?
@NyronW I don't know whether it's the right way to do this or not, but in my system I've just put all the actors and messages in one shared library. This way I avoid the problem with incompatible message versions and I can do cool stuff like fan-out deployment since all my actors have access to each other's definitions. My microservies are essentially empty projects with varying hocon configurations, all they do by themselves is instantiating the actor system.
Also, the microservices aren't actually coupled with each other. They just all depend on same library.
@JohnnyTheAwesome Thanks for your feedback, that is a very interesting option to deploy the micro services using akka.net , However I want each service to be fully independent of each other, so that each service can be developed, maintained and deployed independently, potentially by different teams
I was thinking that I could create some sort of messaging protocol similar to a soap envelope (but as json) that includes meta data in the data sent between each service and then each service will implement its own logic to parse the message and use which every property that they need.
you shouldn't need to do that yourself
just publish your messages as a nuget package
then consume that package in both publisher and consumer
but there is no need to wrap them, because akka can transmit them directly
and in your example, you just proven that yourself, by saying type:"MyEvent" you're already thinking of a shared message library, or you'll end up with different kind of MyEvent class on each end point, which can be bad
Thanks guys, you're absolutely correct, I was creating a solution to a problem that doesn't exist, I will create a shared library to store the message used throughout the entire system and all services will need to reference that package/library. If a message needs to be significantly updated such as change property name or contructor arguments, then each service will need to be updated as well
the slightly harder and messier way is to implement protobuf protocol versioning :P
@NyronW I think you gave up too easily there! Loose coupling seems like a good idea; a public interface that hides internal implementation seems like a good idea. Having a shared library used to "store the message used throughout the entire system" seems (depending on how you meant that statement) like a bad idea - like you're building a monolith by another name. Now if you meant that you were only going to publish shared, "interface" classes, then I'm probably okay with that - but then you're obviously limiting your ability to amend those classes for internal-implementation purposes. I would have thought some strategies for dealing with this are already known and would have been proposed already in this conversation. I can see that it's possible to extend a public message class for internal use by wrapping it as a property of an internal-only message class (and I can see how sticking to an immutability paradigm helps with that); I would also have thought that something like Automapper could be useful at a boundary to copy between public-facing and internal message classes (though perhaps that's just a poor man's serialisation mechanism?). Still, I haven't used Akka extensively myself (and I also happen to think that SOAP gets a bum-rap), so your mileage definitely might vary!
At least not in the same way scala does