If you use the additional Solr Cloud assembly for Intershop 7.9 refer to Concept - Service Registration and Discovery with Solr Cloud (valid to 7.9).
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, 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.
For SolR there is an newly created cartridge (ac_eureka_solr) which capsules the logic for registering all SolR services.
A microservice can use the ServiceRegistry to register itself. So all other components can use the microservice or vice versa.
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.
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).
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
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.