Service Registry
Functional Description
Responsibilities
The 2-Immerse system architecture is built from a number of defined services, each scoped with specific roles and responsibilities. These services will be designed to scale elastically, running the required number of instances to meet dynamic load requirements. The array of services types and instances need to collaborate and interoperate with each other to deliver the 2-Immerse experience.
The Service Discovery component is responsible for maintaining a dynamic service registry of deployed service instances, together with querying interfaces to share addressable attributes of healthy service instances across the service community hosted in the system. The service registry catalogue contains metadata to describe service types as a functional entities, together with a list of operational service instances for a given service type within the system. The Service Registry is an essential component required to provide effective Service Discovery within an elastically scalable system infrastructure.
There are two main approaches to Service Discovery, either client-side or server side discovery, each with their own benefits and drawbacks. These approaches are well documented and can be researched across many website resources.
Server side discovery is preferred for 2-Immerse, this will support:
- Interoperability of cloud hosted services, providing the required discovery for the array of service types and instances that need to interoperate within the server/cloud ecosystem. Server side Service Discovery can be scaled into a quorum of discovery instances to accommodate increasing levels of discovery requests as the 2-Immerse system scales.
- Tracking the operational health of registered service instances.
- Brokering access control policies between services.
- Load balancing service transaction requests across operational instances.
- Providing an administration console to visualise the operational status of service instances within the system.
- Client API Gateways. An API gateway provides a single addressable endpoint (URL domain name) for external clients to communicate with server side services. The API gateway provides a set of functional interfaces that require transactions with a collection of server side services to fulfil them. An API gateway can be either agnostic or specific to a client device type, the latter option provides tailored APIs to suit the specific requirements of the correlating device type. Client devices are configured with the domain name of the correlating API gateway to connect with. These API gateways employ their own load balancing mechanism to build a quorum of gateway instances capable of servicing the volume of connected client devices. An API gateway quorum interfaces with the server side Service Discovery component to capture the addressable attributes of the available server service instances; facilitating subsequent service transactions within the context of executing client interface functions.
There are a number of established Service Discovery components, examples include:
- Netflix Eureka, a component originally used within Netflix OSS as part of a client side Service Discovery approach. Eureka has subsequently been adopted within the Spring Cloud infrastructure employed by server side discovery of Spring Cloud micro-services.
- Consul is a set of open source components, providing tools for service registration and discovery. Cisco has released Mantl as an open-source stack of tools used to build micro-service infrastructures. Mantl utilises a variety of tools for system integration, including Consul.
Cisco proposes adopting Mantl as the tool set employed to build and integrate the server side infrastructure for 2-Immerse. The open source stack provides opportunities to explore and understand the technical details of tools as required, and offers flexibility to provision the infrastructure through commercial cloud vendors (i.e. Cisco Intercloud Service or AWS) or private on-premise lab environments.
Considering the availability and adoption of existing tools for Service Discovery, the following sections seek to capture a high-level abstraction of key interface verbs to clarify the respective roles required from service discovery.
Service Discovery Verbs
Service Registry: Register
A provisioned service instance will call this to register availability as a hosted service within the system. The calling service will pass a collection of attributes to identify and address itself, including but not limited to:
- Service Type
- IP address (resolvable to Service Discovery)
- Port
- Health Check URL – Pre-defined and integrated end-point to retrieve health attributes.
The service registry will group this service instance with other instances of the same service type, then assigns and returns a unique service instance ID.
Service Registry: Renew
A registered service instance will call this to renew a registered status, operating as a service registration heart beat. The calling service will pass the registered service instance ID. Failure to post a heart beat within a configurable time frame results in automatic removal of the service instance from the registry.
Service Registry: De-register
A registered service instance or system administration console calls this to remove a service instance from the registry. The calling component will pass the registered service instance ID.
Service Registry: List All Services
A Service Discovery client will call this to query back all registered service type IDs and correlating instance IDs.
Service Registry: List All Service Instances
A Service Discovery client will call this to query back all registered service instances for a specified service type. The calling client uses this action to refresh a local cache of available service type instances.
The calling component will pass the service type ID.
Service Registry: Query Service Instance
A Service Discovery client will call this to query back service instance attributes sufficient to notify of service state and to facilitate an interface transaction with service instance end-points. The calling component will pass the registered service instance ID.
Service Registry: Put Service Instance Off-line
A registered service instance or system administration console calls this to set an off-line status for a specified service instance. The calling component will pass the registered service instance ID. This status is included within the dataset returned as part of service instance query. An off-line status indicates a temporary out of service state, typically to perform maintenance.
Service Registry: Put Service Instance On-line
A registered service instance or system administration console calls this to transition a specified service instance from an off-line to an on-line status. The calling component will pass the registered service instance ID.
Service Registry: Perform Health Checks
A Service Discovery client will call this to trigger a round-robin query of all registered service instances to pull back status attributes. The calling component can optionally pass a service type ID to filter queries to correlating service type instances. Note: The Service Discovery component will be configured to periodically retrieve status attributes of registered services. This action provides a manual override to trigger retrieval on demand.
Service Registry: Get Health Status
A Service Discovery client will call this to retrieve attributes describing the operational health of registered service instances. The calling component can optionally pass parameters to shortlist health status retrieval to a specific service type or instance ID.
Service Discovery: Configure
Used by a System Administration entity to override default values of operational attributes of Service Discovery instances. This will be specific to the tool adopted by 2-Immerse, but should include:
- Hosting attributes to facilitate flexible deployment within a cloud environment
- Service Registration attributes i.e. renew heart beat intervals, service health check intervals etc.
Service Discovery: Start
Called by a System Administration console to launch a Service Discovery instance. The mechanism is parameterised to start a new Service Discovery quorum with a master instance, or start an additional instance as part of an existing Service Discovery quorum.
Service Discovery: Stop
Called by a System Administration console to terminate a Service Discovery instance. Addressing a master Service Discovery instance will terminate the correlating quorum of instances, otherwise the single Service Discovery instance will be terminated within the quorum.
Service Discovery: Get Status
Called by a System Administration console to retrieve status attributes of a Service Discovery quorum. The available attributes will depend on the Service Discovery tool adopted by 2-Immerse. The attributes shall provide insight to the instances and their operational status within the quorum, including aggregated information regarding transaction times achieved across service discovery requests made from calling components.
Service Discovery Collaborators
Server Service Instances
Provisioned service instances will interface with Service Discovery to manage inclusion and status in the System Registry. Server service instances use Service Discovery to acquire the addressable attributes of available service instances they need to collaborate with to fulfil service functions.
External Client API Gateway
Use all the Service Discovery verbs to query for service instance end-points available within the server system. An API Gateway uses service discovery to acquire the addressable attributes of available service instances and implement algorithms to load balance requests across them.
System Administration Console
Use all the Service Discovery verbs to monitor and control the state of the Service Discovery quorum and registered system services.
API Specification
We have adopted Consul as the Service Registry implementation, as it is part of the mantl platform. Consul provides a REST API which is documented at https://www.consul.io/docs/agent/http.html
The mantl platform also includes Træfɪk; a modern HTTP reverse proxy and load balancer made to deploy microservices with ease. It supports several backends to manage its configuration automatically and dynamically. Using Træfɪk enables allows straightforward client access to microservices.
