asynkron / protoactor-go

Proto Actor - Ultra fast distributed actors for Go, C# and Java/Kotlin
http://proto.actor
Apache License 2.0
5.08k stars 522 forks source link

cluster: manage cluster membership by using gossip based protocol #148

Closed RussellLuo closed 2 years ago

RussellLuo commented 7 years ago

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.

cpx86 commented 7 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? :)

RussellLuo commented 7 years ago

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.

rogeralsing commented 7 years ago

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..

RussellLuo commented 7 years ago

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.

rogeralsing commented 7 years ago

@RussellLuo yes, for go users, we could absolutely build something ontop of Hashicorp Memberlist, the lib they use inside Consul.

dahankzter commented 6 years ago

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.

cpx86 commented 6 years ago

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?

cupen commented 5 years ago

@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.:

rogeralsing commented 5 years ago

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

cupen commented 5 years ago

Yes! I totally agree with you. Golang has more mature libraries, protoactor-go would be a forerunner about cluster provider.

andreaugustoaragao commented 5 years ago

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.

cupen commented 4 years ago

@RussellLuo Hello.

rogeralsing commented 2 years ago

Gossip protocol is finally coming in.