Service Discovery
Service Discovery
Eureka
Spring Cloud
Spring Cloud– is an open-source library–makes it easy to develop JVM applications for the cloud. One of the many advantages
of running an application in the cloud is easy availability of a variety of services. Instead of managing hardware, installation,
operation, backups, etc., you simply create and bind services with a click of a button or a shell command.
How do applications access these services? For example, if you have a relational database bound to your application, you will
need to create a DataSource object based on that service. This is where Spring Cloud helps. It removes all the work needed to
access and configure service connectors and lets you focus on using these services. It also exposes application instance
information (host address, port, name, etc.).
Spring Cloud does all this in a cloud-independent manner through the concept of a Cloud Connector. While it provides
implementations for Cloud Foundry and Heroku, you (or the cloud provider) can extend it to other clouds by implementing an
interface and taking advantage of the rest of the library.
Netflix & Spring Cloud
Netflix :Netflix, a pioneer in the microservices space, has built many such tools to build cloud native application.
Eureka is a service registry, which registers all of a microservice’s instances and supplies each microservice with instance
information to use in discovering others. Hystrix, the Hystrix Dashboard, and Turbine provide fault tolerance using circuit
breakers and enable monitoring of circuits across microservices and instances. These components have been battle-tested
in a production environment facing some of the most demanding traffic requirements in the world, and are available as
open-source software.
Spring Cloud Services
Spring Cloud Services for Pivotal Cloud Foundry (PCF) packages server-side components of Spring Cloud projects,
including Spring Cloud Netflix and Spring Cloud Config, and makes them available as services in the PCF Marketplace.
This frees you from having to implement and maintain your own managed services in order to use the included projects.
You can create a Config Server, Service Registry, or Circuit Breaker Dashboard service instance on-demand, bind to it and
consume its functionality, and return to focusing on the value added by your own microservices.
Spring Cloud Dependencies
https://cloudnative.tips/spring-dependency-management-539e02c306bd
curl https://spring-cloud-service-broker.cfapps.io/actuator/info
Service Discovery-Fundamentals
In any distributed architecture, we need to find the physical address of where a
machine is located. This concept has been around since the beginning of distributed
computing and is known formally as service discovery.
Service discovery is critical to microservice, cloud-based applications for two key
reasons.
Benifits :First, it offers the application team the ability to quickly horizontally scale up and
down the number of service instances running in an environment. The service consumers
are abstracted away from the physical location of the service via service discovery. Because
the service consumers don’t know the physical location of the actual service instances, new
service instances can be added or removed from the pool of available services.
Service Discovery-Fundamentals
The second benefit of service discovery is that it helps increase application
resiliency. When a microservice instance becomes unhealthy or unavailable, most
service discovery engines will remove that instance from its internal list of
available services. The damage caused by a down service will be minimized
because the service discovery engine will route services around the unavailable
service.
Service Discovery Architecture
The architecture of service discovery To begin our discussion around service
discovery architecture, we need to understand four concepts. These general
concepts are shared across all service discovery implementations:
Service registration—How does a service register with the service discovery
agent?
Client lookup of service address—What’s the means by which a service client
looks up service information?
Information sharing—How is service information shared across nodes?
Health monitoring—How do services communicate their health back to the
service discovery agent?
Service Discovery Architecture
As service instances start up, they’ll register their physical location, path, and port
so that they can be accessed by with one or more service discovery instances.
While each instance of a service will have a unique IP address and port, each
service instance that comes up will register under the same service ID. A service
ID is nothing more than a key that uniquely identifies a group of the same service
instances.
A service will usually only register with one service discovery service instance.
Most service discovery implementations use a peer-to-peer model of data
propagation where the data around each service instance is communicated to all
the other nodes in the cluster.
Service Discovery Architecture
With this approach, the service discovery engine will be invoked every time a call
to a registered microservice instance is made. Unfortunately, this approach is
brittle because the service client is completely dependent on the service discovery
engine to be running to find and invoke a service.