Service Discovery
Automatically detect new services to improve performance.
Last updated
Was this helpful?
1.2
Automatically detect new services to improve performance.
Last updated
Was this helpful?
Service discovery is important but hard. Microservices constantly communicate with instances of other microservices, intensifying the volume and frequency of communications.
Grey Matter's service-level visibility and telemetry improves service inventory and dependency analysis.
Control performs service discovery in the mesh and acts as the Envoy xDS server to which all proxies connect.
Service discovery lets services communicate transparently with a member of a cluster without knowing its identity, or even how many members there are.
When a service joins or leaves the cluster, it joins or leaves the load-balancing list.
Grey Matter supports *several service discovery implementations, with more to come. These include a central server or servers that maintain a global view of addresses (Kubernetes keeps this central server), and clients that connect to the central server to update and retrieve addresses.
*Except for flat-file cases; we farm out that functionality to some other service discovery system.
Service discovery is arguably the first piece of infrastructure you should adopt when moving to microservices.
When choosing your service discovery architecture, consider the following:
What is the best strategy for deploying service discovery clients?
What types of resources and services will you ultimately want to address in your service discovery system?
What languages and platforms need to be supported?
Regardless of your choice, the implementation of an automated, real-time service discovery solution will simplify your microservices architecture.
Here is a short explanation of the workings of each of our service discovery implementations.
Grey Matter's Kubernetes service discovery scheme keeps track of labels placed on pods when they're deployed. Our software uses the Kubernetes API to ask "what pods are in this namespace?" Then we use the labels to match those pods to "clusters", so services can talk to other services just by saying "send this request to some instance of this cluster". When pods die, they get removed from Kubernetes' service discovery list, and therefore from our software's list of running instances for a cluster.
For existing infrastructures already using Consul, you can easily configure Grey Matter to discover services from the existing catalog without migration to Kubernetes or any other platform. Infrastructures with services running in heterogeneous environments, or looking to leverage features such as health checking, load-balancing, or distributed service configuration management can use Consul as a central service registry from which Grey Matter will discover.
We also support service discovery for flat-file cases.
Grey Matter monitors cloud-native environments in real-time. Grey Matter can detect and address meaningful conditions in seconds.
Feature
Details
Service Registry
Grey Matter's service registry tracks all running services and their health status to organize a dynamic microservice environment.
Service Registration
The service registry registers and deregisters all service instances using self-registration, or third-party registration (where another system component manages the registration of service instances).
Health Checks
Health checks find running nodes and services that can't handle requests. A service that has a health check API endpoint returns the health of the service. The API endpoint handler performs various tests, such as:
Status of connections to the infrastructure services used by the service instance
Status of the host, such as disk space
Application-specific logic
A service registry or load balancer routinely invokes the endpoint to check the health of the service instance. A service instance failure generates an alert and subsequent requests route to healthy instances.
Multi Datacenter
Grey Matter supports multiple datacenters out of the box with no complicated configuration. Look up services in other datacenters or keep the request local. Advanced features like Prepared Queries enable automatic failover to other datacenters.
DNS Query Interface
Grey Matter does not use DNS for service discovery, though nothing we do precludes doing so. Service discovery using a built-in DNS server helps existing applications integrate, as almost all applications support using DNS to resolve IP addresses. Using DNS instead of a static IP address allows services to scale up/down and route around failures easily.
HTTP API with Edge Triggers
Grey Matter provides an HTTP API to query the service registry for nodes, services, and health check information. The API also supports blocking queries, or long-polling for any changes. This allows automation tools to react to services being registered or health status changes to change configurations or traffic routing in real time.
The server supports several service discovery options and platforms.
Many cloud infrastructure use Envoy's or to keep track of instances and upstream clusters. Since Grey Matter Control uses xDS as the configuration discovery mechanism, Grey Matter inherits all Envoy configs. Moreover, any Grey Matter proxy can act as a vanilla Envoy proxy instance, and any Envoy proxy can integrate with Grey Matter Control.
We are always working on new implementations for service discovery! to discuss your implementation requirements.
Have a question about how Grey Matter performs service discovery? to discuss your specific use case.
