The TeaStore consists of five distinct services and a Registry service as shown in Figure 1.
All services communicate with the Registry.
Additionally, the WebUI service issues calls to the Image-Provider, Authentication, Persistence and Recommender services.
The Image provider and Recommender both connect to a provided interface at the Persistence service.
However, this is only necessary on startup (dashed lines).
The Image provider must generate an image for each product, whereas the Recommender needs the current order history as training data.
Once running, only the Authentication and the WebUI access, modify, and create data using the Persistence.
All services communicate via representational state transfer (REST) calls, as REST has established itself as the de-facto industry standard in the micro-service domain.
The services are deployed as web-services on Apache Tomcat.
Yet, the services can be deployed on any Java application server able to run web-services packaged as war files.
As an alternative to deploying the war files, we provide convenient Docker images, containing the entire Tomcat stack.
Each service is packaged in its own war file or Docker image.
The TeaStore uses the client-side load balancer Ribbon, to allow replication of instances of one service type.
Ribbon distributes REST calls among running instances of a service.
Instead of using Netflix Eureka, the TeaStore uses its own registry that supplies service instances with target instances of a specified target specific service type.
To enable this, all running instances register and unregister at the registry, which can be queried for all running instances of a service.
This allows for dynamic addition and removal of service instances during run-time.
Each service also sends heartbeats to the registry.
In case a service is overloaded or crashed and therefore fails to send heartbeat messages, it is removed from the list of available instances.
Subsequently, it will not receive further requests from other services.
This mechanism ensures good error recovery and minimizes the amount of requests sent to unavailable service instances that would otherwise generate request timeouts.
As the TeaStore is primarily a benchmarking and testing application, it is open source and available to instrumentation using available monitoring solutions.
Pre-instrumented Docker images for each service that include the Kieker monitoring application [31], [32] as well as a central trace repository service, are already available.
We choose Kieker, as it requires no source code instrumentation and the instrumentation can be adapated at runtime.
However, as the TeaStore is open source, other monitoring solutions, such as Prometheus or Logstash can also be utilized.
Generally, all requests to the WebUI by a user or load generator are handled in a similar fashion.
The WebUI always retrieves information from the Persistence service.
If all information is available, images for presentation are fetched from the Image provider and embedded into the page.
Finally a Java Server Page (JSP) is compiled and returned.
This behavior ensures that even non-graphical browsers and simple load generators that otherwise would not fetch images from a regular site cause image I/O in the TeaStore, ensuring comparability regardless of the load generation method.
Figure 2 shows the service calls for a user request for a product information page.
After receiving the HTTP request, the WebUI checks the user’s login status by calling the Auth service.
Next, it queries the Persistence for the corresponding product information, based on a unique identifier.
Afterwards, the WebUI requests advertisement options for the current product from the Recommender, which generates a recommendation based on the learned historical order data.
The call to the Recommender takes the current login status into account.
Specifically, a logged in user receives personalized recommendations, whereas an anonymous user is served recommendations based on general item popularity.
Having received all product information, the WebUI queries the image provider to supply a full size image of the product shown in detail and preview images for the recommendations.
The image data is embedded in the HTML response as base-64 encoded strings.
