Closed RussellLuo closed 2 years ago
More providers is nice - it's always a question of what we should support as part of the core library though, and what should be treated more as "extensions" for lack of a better word.
For example one option could be to support Consul as the default/bundled provider, and keep other providers in their own repos, either under this organisation or some other.
Personally I'm not 100% decided to be honest. @AsynkronIT/developers what do you others think? :)
Personally, I prefer the philosophy that does not force a strong dependence on any particular technology, which is also part of the design rationale of Orleans:
as part of Orleans's philosophy, we do not want to force a strong dependence on any particular technology, but rather have a flexible design where different components can be easily switched with different implementations.
So I wish the gossip based provider can become the default provider, which is also the default/core membership protocol like Akka and Orleans have adopted.
One of the main tennants of Proto.Actor is to not reinvent the wheel, if there are tools that solve a problem, then use those tools. Cluster membership is tricky to get right, it's a bug prone process.
We also have the aspect of being cross platform, Go Actors work with C# Actors etc. Having our own cluster membership implementation would require us to have the exact same implementation across languages. Any little difference could cause a cluster to fail.
So I would very much like to avoid providing that sort of plugin ourselves.
That being said, it is however very possible to build your own provider and use that..
We also have the aspect of being cross platform, Go Actors work with C# Actors etc. Having our own cluster membership implementation would require us to have the exact same implementation across languages.
Yes, I agree.
The gossip based implementation here will affect the possibility of being cross platform. We should not do this until we can find mature libraries, based on the exactly same gossip protocol, for all supported languages...
But for those who are always using Go, and do not care about cross platform compatibility, maybe the lightweight gossip based provider is a more competitive alternative.
@RussellLuo yes, for go users, we could absolutely build something ontop of Hashicorp Memberlist, the lib they use inside Consul.
I would like to push once more for this one. Having no external service needed to run an Actor cluster would be a great benefit. Can't it be in this repo even though it's Go only? Same could apply to the other languages, there are mature libs for at least Java. Surely .NET has something as well.
Creating embedded cluster providers for non-cross-platform users could make sense I think. I can't find any .NET implementation that seems mature, but for Go and Java at least maybe we can do something?
@RussellLuo It looks good to me. I'm a non-cross-platform user, but I‘m using etcd
;D.
@rogeralsing @cpx86 @dahankzter So, do we create cluster provider as a embedded library at this stage, like this? e.g.:
github.com/User/protoactor-go-cluster-gossip
github.com/User/protoactor-go-cluster-etcd
We could absolutely add Etcd and custom gossip managers. There even is a Go lib, MemberList, from Hashicorp, which is the same lib that Consul uses internally. which should be possible to leverage here
Yes! I totally agree with you.
Golang
has more mature libraries, protoactor-go
would be a forerunner about cluster provider.
Was this ever implemented? I’m looking for a distributed communications mechanism on Go without external dependencies and this library with gossip would fit the bill nicely.
@RussellLuo Hello.
Gossip protocol is finally coming in.
Currently,
protoactor-go
only supports cluster management via Consul. While this looks good and is feasible, but it forces a strong dependence on Consul at the same time.As far as I know:
So I think it maybe wonderful if we add a gossip based implementation of cluster provider, and also allow users create their own implementation.
Here I have already implemented a gossip_provider, and this is the example. I can submit a pull request if it's the way
protoactor-go
want to support.