Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIP: support Eureka discovery #303

Open
Roiocam opened this issue Sep 11, 2024 · 0 comments
Open

PIP: support Eureka discovery #303

Roiocam opened this issue Sep 11, 2024 · 0 comments

Comments

@Roiocam
Copy link
Member

Roiocam commented Sep 11, 2024

Pekko Improve Proposal: support Eureka discovery.

Motivation

AFAIK, Popular cluster discovery methods in pekko have:

  • Kubernetes API: strong RBAC requirements(required Kubernetes ClusterRole)
  • Kubernetes DNS: less RBAC requirements, still require specific platform
  • AWS ways: require specific platform
  • Config: generally used for development

We do contain a platform-free method that uses Consul, but it may lack maintenance so we may need another platform-free discovery method for the cluster bootstrap, I recommend Eureka, it was very popular in Spring ECO-System and simple enough.

Comparison

The eureka/consul service discovery approach has some advantages to the platform-binding discovery approach:

  • flexibility: By adopting a platform-independent service discovery solution, organizations are not tied to a specific platform or technology stack. This flexibility allows them to choose the most suitable infrastructure for their needs, whether it's on-premises, in the cloud, or a hybrid environment. It also enables easy migration between different platforms without significant changes to the service discovery mechanism.
  • Integration Options: Both Eureka and Consul offer APIs and integration points with other tools and frameworks commonly used in the ecosystem. This allows for seamless integration with service mesh frameworks, API gateways, and other service-oriented architecture components. The ability to integrate with existing tools and frameworks simplifies the adoption process and ensures compatibility with the existing technology stack.

But it also has disadvantages to the platform-binding discovery approach:

  • platform-bind discovery often has built-in registration and health monitoring, but the platform-free approach needs to manually register and renew(or sending heartbeat) by the application itself. (which currently lacking in Pekko)
  • reliability: using an external component like Eureka or Consul introduces an additional point of failure. If the service discovery server goes down or becomes unreachable, it can disrupt the entire service ecosystem.
  • scalability: the platform-binding discovery approach often provides built-in scalability features, such as load balancing and auto-scaling, which are not readily available in the platform-free approach. This means that additional effort and custom implementation may be required to achieve similar scalability benefits.

In conclusion, while the platform-free approach brings challenges in terms of reliability, scalability, complexity, but it also provides flexibility and platform independence.

Therefore, it is essential to carefully evaluate the specific requirements and constraints of the architecture before deciding on the most suitable service discovery approach.

Implementation requirements

  • Eureka Clients: based on HTTP
  • Eureka Registration on startup
  • Scheduling heartbeat periodically
  • ...(if there has more)

Relate works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant