Introduction

An Intershop installation consists of different software components which need to communicate to process requests. These are especially:

• Web Adapter (needs configuration service and application server)
• Web Adapter agent (needs configuration service)
• Application server (needs database server and SolR server)

There exist configuration files and options to tell each component a start point to lookup the other instances. These are mainly a URL with a hard coded IP/host name or only a IP/host name.

The problem with hard coded host identification arise within dynamic installations which may start, stop and create new instances of used components. These are mainly cloud based environments where different components are part of dynamic virtual machines (VM).

Problems may occur if:

• The IP address of a VM changes after a VM restart
• A configured IP address may be invalid by VM shutdown or removal
• New component instances may be created as new VM without knowing the IP address

These problems should be solved by a general service registration and discovery component.

Glossary

Operations and Processes

Register a Component

• A component is started
• Component lookup the SRD configuration
• Component sends own registration information (type, IP/URL, meta data) to the SRD process

Refresh Registration

• A component "pings" the SRD process to keep the registration "active" in a configurable loop
• If the "ping" is missing for a period of time the component becomes invalid and will be removed (crash ect.)

Unregister a Component

• The component notifies the SRD process to remove the own configuration

Lookup a Component

• A "source" component wants to communicate with another "target" component
• The source component sends a query with the necessary information (type, meta data) to the SRD process
• The SRD process returns all, one or no matching registered component information

Automated Installation

• The SRD component can be installed with our automated deployment concept
• Configuration through a deployment setting file

Resilience

The SRD is the crucial part of the system. Therefore the SRD must have a fail-safe system like having two or more SRD systems running in the cloud and if one fails, the other takes over.

Or if there are temporary network problems, like partitioning, the SRD should still be able to deliver component registration information.

Also the components must be designed in a manner, that a temporary missing depending component will not cause it to stop working. A fall-back mechanism must be created there.

Intershop's Service Registration and Discovery

For microservices we need a central point for the service discovery. There exists some open source libraries/tools to achieve this. For example: Eureka, Consul, Zookeeper.

Intershop has chosen Eureka for SRD because it is open source, high availability and partition tolerance.

System Components

Appserver

For the appserver a new cartridge (ac_eureka) was introduced which includes all functionality to register the appserver to Eureka. Other components like the Web Adapter can use this information.

Web Adapter Agent

The Web Adapter agent uses the information of Eureka to create the webadapter.properties file, which will then be used by the Web Adapter to retrieve all available application server.

SolR

For SolR there is an newly created cartridge (ac_eureka_solr) which capsules the logic for registering all SolR services.

Microservices

A microservice can use the ServiceRegistry to register itself. So all other components can use the microservice or vice versa.

Service Registration to Eureka

The registration of the application server, SolR server and the Web Adapter agent are done already. Furthermore the Intershop microservice are registered, but this project can be used as blueprint to write own microservices and register them at eureka.

Project Specific Microservices and Their Registration at Eureka

Within this project there is a Guice module to register the microservice to Eureka. Just use this module to create your Injector.

Injector injector = Guice.createInjector(new LocalEurekaModule());

Furthermore the eureka-client.properties needs to be in the classpath. For more information about Eureka configuration please refer to https://github.com/Netflix/eureka/wiki/Configuring-Eureka. For more information about microservice deployment please refer to Cookbook - Microservice Deployment (valid to 7.10).

Use the Service Registry to Obtain a Microservice

The microservice are registered at eureka by their name. To retrieve the microsersvices location in the network (host and port), the registration name is used.

So a WebTargetFactory is used to create a javax.ws.rs.client.WebTarget for communication to the service.

Injector injector = Guice.createInjector(new LocalEurekaModule());
WebTargetFactory clientFactory = injector.getInstance(WebTargetFactory.class);
WebTarget webTarget = clientFactory.createWebTarget("service://" + SERVICE_NAME + "/");

For additional information refer to https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/WebTarget.html

Open Questions

• Allowed status and transitions needs to be defined
• Should the DummyRegistry deliver values to work with (not only return null)