Introduction
With the release of the ICM 7.8 the microservices were introduced, which can be deployed separately. A discovery service (Eureka) is responsible to provide real instances (IP and port) for the different services.
The solution contains following services:
- Recurring order service (as microservice)
- Scheduling service (as microservice)
- Basket service (inside ICM 7.8)
The ICM 7.8 contains service interfaces (internal and external). The external one is used by the Web Adapter only, to produce content for the outside world (e.g., real users) the internal interface is used by the microservice or ICM.
Note
Microservices provide their functionality internally, only to other services (incl. ICM). ICM is the API gateway for all external (user) requests. Conceptually, other gateways could provide other APIs, like a specific REST API.
The API gateway (ICM or another) has the responsibility to:
- Provide a stable API for the outside world
- Authorize the user request
- Forward the request to the action specific microservice (via service discovery)
- Collect information for monitoring and billing (if necessary)
Build
The builds of microservices are independent from the ICM. The component set a_responsive contains the deployment project microservices of our services for easier use in a developer environment. As an implementation partner, you can implement your own services with your preferred technology stack. Normally, the ICM must communicate with your service, therefore the service instances must be discoverable.
Deployment Scenarios
The component set a_responsive contains a sub-project called microservices. This is a component, which was introduced to simplify the deployment of the microservices and does not contain the microservices itself. For the project setup some adaptions are necessary: Recipe: Set Up Project Based on the Responsive Starter Store.
Typical deployment scenarios can be found here: Concept - Planning an Intershop 7 Deployment.
Development
- Single-Host Deployment
With a single-host deployment, all software components (and hence, all host types) are deployed on the same machine. The simple deployment is best suited for development and testing purposes. This deployment scenario is covered with the host typeall.
Production
- Multiple-Host Deployment
With a multiple-host deployment, only selected host types are deployed on individual machines. A multiple-host deployment allows full use of Intershop 7’s open architecture by distributing the components over as many machines and processors as you need, and configuring them optimally for your site.
The following example shows for simplicity reasons the multiple host deployment approach with only one instance of each type. Real life scenarios can contain of course more instances of each type.
Deployment Scenarios - Scheduling and Recurring Order
The microservices scheduling and recurring order may be deployed together or separately. See: Cookbook - Microservice Deployment (valid to 7.10) also for database configuration.
Development
In development environments microservices scheduling and recurring order are deployed together.
Production
In production environment the microservices scheduling and recurring order can be deployed together, in separate processes or on separate machines. Since they are registered at a Eureka server they can find each other.
Deploy all Microservices Together
The deployment project microservices at a_responsive contains this scenario. The environment.properties contains all service implementations.
services=Scheduling,RecurringOrder
Separately Deploy Microservices
It is possible to copy and adapt the microservices project to apply combinations, which fits best for the operational requirements. The environment.properties file contains a list of services, which are deployed together and the name of the other services.
For each combination or deployment project a specific name must be defined, which is used to register the instance at service discovery (Eureka).
services=Scheduling eureka.name=SchedulingService intershop.naming.service.RecurringOrder=RecurringOrderService intershop.naming.service.Scheduling=SchedulingService
services=RecurringOrder eureka.name=RecurringOrderService intershop.naming.service.RecurringOrder=RecurringOrderService intershop.naming.service.Scheduling=SchedulingService
Configuration
Additionally to the configuration for service discovery other environment specific configurations are necessary, e.g., database connections. The config directory is part of the classpath and will be read via resource loading algorithm. Both new services (recurring order and scheduling) reading their configuration from the environment.properties resource.
cat server/local/microservices/config/environment.properties
Database Configuration
Note
It is not recommended to use the derby database in a production environment.
The connection parameter are part of the configuration (environment.properties, which is deployed into <SERVER>/local/microservices/config/). It is possible to use for all services the same database or different connections, also in the case that both services are deployed together.
#example section using specific database connection for recurring oder service for postgres # RecurringOrdersPU.javax.persistence.jdbc.driver=org.postgresql.Driver # RecurringOrdersPU.javax.persistence.jdbc.url=jdbc:postgresql://<HOST>:<PORT>/postgres # RecurringOrdersPU.javax.persistence.jdbc.user=<USERNAME> # RecurringOrdersPU.javax.persistence.jdbc.password=<PASSWORD> #example section using specific database connection for scheduling service for derby # SchedulingPU.javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver # SchedulingPU.javax.persistence.jdbc.url=jdbc:derby:build/testdb;create=true # SchedulingPU.javax.persistence.jdbc.user=test # SchedulingPU.javax.persistence.jdbc.password=test #example section using one database connection for all services for derby javax.persistence.jdbc.url=<@databaseURL@> javax.persistence.jdbc.user=<@databaseUserName@> javax.persistence.jdbc.password=<@databaseUserPassword@> javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver
The configuration follows a simple pattern:
- javax.persistence prefix for all persistent units (PU)
- <PeristentUnitName>.javax.persistence for unit specific configurations
The configuration of the database is divided in two parts
- Selection of the database driver
- This step has to be executed before the publication of the project assembly. See Recipe: Set Up Project Based on the Responsive Starter Store for details.
- Definition of connection (URI, user, passwords etc)
- This step has to be executed before the deployment of the project assembly.
Selection of Database Driver
The database driver can be declared as dependency at the deployment project. As example remove the comment of the postgresql driver at line (8) and remove the line (5) of the derby driver. It is up to the DevOps team to use another database, which is JPA compliant.
dependencies {
runtime "com.intershop.microservice.lib:platform-scheduling"
runtime "com.intershop.microservice.lib:checkout-recurringorders"
/** driver for derby */
runtime 'org.apache.derby:derby:10.12.1.1'
/** driver for postgres */
// runtime 'org.postgresql:postgresql:9.4.1209'
/** driver for oracle */
/** this configuration uses the prepared oracle drivers **/
/** see 'Cookbook - Setup CI Infrastructure', 7.2.5 Process for Building the Oracle JDBC Drivers Component **/
//runtime 'com.intershop:ojdbc7:12.1.0.2.0.0'
}
Furthermore, the JDBC driver has to be adapted into the environment.properties. As example replace 'org.apache.derby.jdbc.EmbeddedDriver' by 'org.postgresql.Driver'.
javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver
Definition of Connection Parameters
The connection parameters contain placeholders (<@PLACEHOLDER@>), which are replaced during deployment.
javax.persistence.jdbc.url=<@databaseURL@> javax.persistence.jdbc.user=<@databaseUserName@> javax.persistence.jdbc.password=<@databaseUserPassword@>
There are two ways to define values to replace the placeholders:
- In a development scenario the developer/environment.properties needs to be adapted. Cookbook - Microservice Deployment (valid to 7.10)
- In a production scenario the settings.gradle needs to adapted. Cookbook - Deployment Tools ICM 7.8 | Recipe: Microservice Deployment