This concept is only valid for the additional Solr Cloud assembly for Intershop 7.9. If this assembly is not used, refer to Concept - Service Registration and Discovery.
An Intershop installation consists of different software components which need to communicate to process requests. These are especially:
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:
These problems should be solved by a general service registration and discovery component.
|SRD||Service registration and discovery|
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.
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, its high availability and partition tolerance.
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.
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.
A microservice can use the ServiceRegistry to register itself. So all other components can use the microservice and vice versa.
The registration of the application 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.
The Intershop microservices project can be used as blueprint. 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.
The microservices are registered at eureka by their name. To retrieve a microsersvice's 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.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.