Microservices Basics Training – 4. Event Driven Architecture

Docs: 4.1 Getting Started

Mon, 01 Jan 0001 00:00:00 +0000

Source Code

The source-code used for this lab is in the folder /code/kafka

Online Repository Link: https://github.com/acend/microservices-lab/tree/main/code/kafka .

Task 4.1.1 - Getting your workspace ready

If you still have a previous lab running, stop it with docker-compose down.
Open your IDE and switch to the correct source-code location to start with.

Docs: 4.2 Docker Environment

Mon, 01 Jan 0001 00:00:00 +0000

Environment Setup

With completing this section the environment is configured. However, in the next few steps we will build the order microservice and its container. After this section you will not be able to start the environment as this container is still missing. You will be able to start it later.

Changes to the docker-compose file

Since we are going to use Apache Kafka as a message broker, there are some changes to our docker-compose.yaml file.

Apache Kafka Broker

To use Apache Kafka the following was added to our docker-compose.yaml file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24



 zookeeper:
 image: quay.io/debezium/zookeeper:2.3
 hostname: zookeeper
 container_name: debezium-zookeeper
 networks:
 - kafka
 ports:
 - 2181:2181
 - 2888:2888
 - 3888:3888

 kafka:
 image: quay.io/acend/microservices-lab-debezium-kafka:latest
 hostname: kafka
 container_name: debezium-kafka
 ports:
 - 9092:9092
 networks:
 - kafka
 depends_on:
 - zookeeper
 environment:
 - ZOOKEEPER_CONNECT=zookeeper:2181

Kafka Viewer

Further a simple kafka-viewer microservice was added to the docker-compose.yaml. The kafka-viewer is a small web-UI which displays messages passing through our kafka topics.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


 viewer:
 image: quay.io/acend/microservices-lab-kafka-viewer:latest
 ports:
 - 8082:8080
 networks:
 - kafka
 depends_on:
 - kafka
 environment:
 - QUARKUS_HTTP_PORT=8080
 - MP_MESSAGING_INCOMING_KAFKAMESSAGES_TOPICS=shop-order-request,shop-order-confirmation,shop-order-compensation
 - MP_MESSAGING_INCOMING_KAFKAMESSAGES_KEY_DESERIALIZER=org.apache.kafka.common.serialization.StringDeserializer
 - MP_MESSAGING_INCOMING_KAFKAMESSAGES_VALUE_DESERIALIZER=org.apache.kafka.common.serialization.StringDeserializer

Microservice Configuration

To ensure your microservices will connect to the Kafka broker an additional property has been added to both microservices. The property KAFKA_BOOTSTRAP_SERVERS=kafka:9092 in the environment section will ensure that the microservices will connect to our kafka message broker.

Task 4.2.1 - Inspecting the docker environment

Have a look at the /code/kafka/docker folder and get familiar with the docker environment specified in docker-compose.yaml.

Docs: 4.3 Reactive Messaging

Mon, 01 Jan 0001 00:00:00 +0000

4.3.1: The Reactive Manifesto

“Today’s demands are simply not met by yesterday’s software architectures.” - The Reactive Manifesto

Old fashioned applications - often built as monoliths - struggle to meet the requirements of todays workload dimensions. Applications should become scalable, robust and easy to maintain. Similar to the twelve-factor-app manifesto there is a Reactive Manifesto. It describes requirements to tackle problems for modern enterprise solutions.

The Reactive Manifesto defines that reactive systems are:

Responsive
Resilient
Elastic
Message Driven

We have already learned basics of messaging in a microservice architecture. Time to take a next step and make our messaging reactive. The approach we have seen in the chapter before is completely legitimate and there is nothing wrong with this approach.

4.3.2: Reactive Messaging

In the last chapter we learned about basic messaging concepts and how two microservices can communicate with a message broker. In reactive messaging we connect channels directly to components. Instead of having a Thread running manually, we can annotate functions to bind them to events sent in a specific channel or data stream. This makes our code more readable and act in a reactive manner. Let’s look at an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10



/* [...] */

@Incoming("data-inbound-reactive")
@Outgoing("data-outbound-reactive")
public String streamProcess(String value) {
 return value.toUpperCase();
}

/* [...] */

If you read this example it’s pretty clear what is happening. We are connecting with a Connector to a Channel (Queue or Topic) we call “data-inbound-reactive” and define it as the inbound connector for this method. On the other side we connect the outcome of this method to the “data-outbound-reactive” stream. Whenever the “data-inobund-reactive” stream sends an message we perform a transformation to uppercase and return the value into the “data-outbound-reactive” channel. Simple as that!

4.3.2.1: Connectors

Connector can:

retrieve messages from a remote broker (inbound)
send messages to a remove broker (outbound)

A connector can, of course, implement both directions.

Inbound connectors are responsible for:

Getting messages from the remote broker,
Creating a Reactive Messaging Message associated with the retrieved message.
Potentially associating technical metadata with the message. This includes unmarshalling the payload.
Associating a acknowledgement callback to acknowledge the incoming message when the Reactive Messaging message is acknowledged.

Important: Reactive matters! The first step should follow the reactive streams principle: uses non-blocking technology, respects downstream requests.

Outbound connectors are responsible for:

Receiving Reactive Messaging Message and transform it into a structure understand by the remote broker. This includes marshalling the payload.
If the Message contains outbound metadata (metadata set during the processing to influence the outbound structure and routing), taking them into account.
Sending the message to the remote broker.
Acknowledging the Reactive Messaging Message when the broker has accepted / acknowledged the message.

4.3.2.2: Connectors Event Driven Architecture

With this reactive messaging approach we can build our applications on an event driven approach. Some interaction or trigger emits an event to a certain channel. Subscribers of this channel consume the message and react based on the event received. This loosens the coupling in our application and lowers the cohesion between logically seperated components.

In an event driven approach everything that happens in our application gets triggered by an event. Events in the event-driven software model describe what happens within a software system. If we imagine our application as a set of logically ordered processes every task in these processes gets triggered by such an event and might emit another new event. This concept is very intuitive to apply because it is a very natural way of thinking about how everyday things and tasks work.

Some typical patterns in event-driven architecture:

4.3.2.3: Connectors Event notification

In this approach, microservices emit events through channels to trigger behaviour or notify other components about the change of a state in the application. Notification events do not carry too much data and are very light weight. This results in a very effective and ressource friendly communication between the microservices.

4.3.2.4: Connectors Event-carried state transfer

Instead of only notifying about events this approach sends a payload as a message to another component containing every information needed to perform actions triggered by this event. This model comes very close to the typical RESTful approach and can be implemented very similar. Depending on the amount of data in the payload the network traffic might suffer under the amount of data transferred.

4.3.2.4: Connectors Event-sourcing

The goal of event-sourcing is to represent every change in a system’s state as an emitted event in chronological order. The event stream becomes the principle source of truth about the applications state. Changes in state, as sequences of events, are persisted in the event stream and can be ‘replayed’.

Docs: 4.4 Event Driven with Kafka

Mon, 01 Jan 0001 00:00:00 +0000

In this stage we will have a look at the setup of a microservice and we will implement the order microservice.

Stock Microservice

The order and stock microservice have a similar setup. Therefore, we will only work on the order microservice. If you have to make changes to the stock microservice it is clearly stated.

The tasks we need to complete are the following:

Update dependencies
Create and consume shop-order-request events
Create and consume shop-order-confirmation events
Create and consume shop-order-compensation events

Task 4.4.1 - Update dependencies

First we are going to declare the dependencies we are going to use in this chapter. Add the following dependencies to your pom.xml:

GroupId	ArtifactId	Description	Detailed information
`io.quarkus`	`quarkus-smallrye-reactive-messaging-kafka`	Reactive Messaging with Apache Kafka	Using Apache Kafka with Reactive Messaging
`io.quarkus`	`quarkus-smallrye-context-propagation`	Context Propagation in Quarkus	Context Propagation in Quarkus
`io.opentracing.contrib`	`opentracing-jdbc`	OpenTracing JDBC Instrumentation	OpenTracing JDBC Instrumentation
`io.opentracing.contrib`	`opentracing-kafka-client`	OpenTracing Kafka Client	OpenTracing Kafka Client

Dependencies Task Hint

The following dependencies have to be added.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


<dependencies>
 ...
 <dependency>
 <groupId>io.quarkus</groupId>
 <artifactId>quarkus-smallrye-reactive-messaging-kafka</artifactId>
 </dependency>
 <dependency>
 <groupId>io.quarkus</groupId>
 <artifactId>quarkus-smallrye-context-propagation</artifactId>
 </dependency>
 <dependency>
 <groupId>io.opentracing.contrib</groupId>
 <artifactId>opentracing-jdbc</artifactId>
 </dependency>
 <dependency>
 <groupId>io.opentracing.contrib</groupId>
 <artifactId>opentracing-kafka-client</artifactId>
 </dependency>
 ...
</dependencies>

Task 4.4.2 - Emit the first event

We are now going event driven. Let’s create our first message and emit an event whenever a new order comes in. We create a new @ApplicationScoped class ch.puzzle.mm.kafka.order.order.boundary.ShopOrderRequestProducer in the order microservice for emitting events to our shop-order-request topic. In order to to emit messages to a topic manually we have to define a channel. To send things (payload or Message) from imperative code to a specific channel you need to use: @Channel annotation on an Emitter type field. The @Channel lets you indicate to which channel you are going to send your payloads or messages. The Emitter is the object to use to send these payloads or messages.

In the ShopOrderRequestProducer class we define a @Channel("shop-order-request") on an Emitter<ShopOrderDTO> emitter. We then create a method which creates the requests and takes a ShopOrderDTO as a parameter. The method simply emits an event to the shop-order-request channel with emitter.send(Message.of(shopOrderDTO)).

Emit Event Task Hint

The class should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


@ApplicationScoped
public class ShopOrderRequestProducer {

 @Inject
 @Channel("shop-order-request")
 Emitter<ShopOrderDTO> emitter;

 @Traced
 public void createRequest(ShopOrderDTO shopOrderDTO) {
 emitter.send(Message.of(shopOrderDTO));
 }
}

We need to update configurations to establish the communication to our message broker and define the connectors from the channels to the topics in our message broker:

Add the following properties to the application.properties file:

1
2
3
4
5
6
7


kafka.bootstrap.servers=kafka:9092

mp.messaging.outgoing.shop-order-request.connector=smallrye-kafka
mp.messaging.outgoing.shop-order-request.topic=shop-order-request
mp.messaging.outgoing.shop-order-request.key.serializer=io.quarkus.kafka.client.serialization.JsonbSerializer
mp.messaging.outgoing.shop-order-request.value.serializer=io.quarkus.kafka.client.serialization.JsonbSerializer
mp.messaging.outgoing.shop-order-request.incerceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor

In order to have our OpenTracing traces injected into the message headers we will need to add some code around the message emitter to make it work properly. Update your class to the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


@ApplicationScoped
public class ShopOrderRequestProducer {

 @Inject
 @Channel("shop-order-request")
 Emitter<ShopOrderDTO> emitter;

 @Inject
 Tracer tracer;

 @Traced
 public void createRequest(ShopOrderDTO shopOrderDTO) {
 HeadersMapInjectAdapter headersMapInjectAdapter = new HeadersMapInjectAdapter();
 try (Scope scope = tracer.buildSpan("create-request").startActive(true)) {
 tracer.inject(scope.span().context(), Format.Builtin.TEXT_MAP, headersMapInjectAdapter);
 OutgoingKafkaRecordMetadata<ShopOrderDTO> metadata = OutgoingKafkaRecordMetadata.<ShopOrderDTO>builder()
 .withKey(shopOrderDTO)
 .withTopic("shop-order-request")
 .withHeaders(headersMapInjectAdapter.getRecordHeaders())
 .build();
 emitter.send(Message.of(shopOrderDTO, Metadata.of(metadata)));
 }
 }
}

Now we can simply replace the REST call we made with help of the rest-client in the previous chapter with the emitting of the event by injecting the ShopOrderRequestProducer into our ShopOrderService and using its createRequest method to emit an event to the kafka topic. Please remove the update of the status flag as well from the ShopOrderService::createShopOrder. The updating of the status flag in the order should be done when we received the confirmation event from the stock microservice.

Emit event

The createOrder function could look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 public ShopOrder createOrder(ShopOrderDTO shopOrderDTO) {
 List<ArticleOrder> articleOrders = shopOrderDTO.articleOrders.stream().map(s -> new ArticleOrder(s.articleId, s.amount)).collect(Collectors.toList());
 articleOrders.forEach(articleOrder -> articleOrder.persist());

 // store order to shopOrder table
 ShopOrder shopOrder = new ShopOrder();
 shopOrder.setStatus(ShopOrderStatus.NEW);
 shopOrder.setArticleOrders(articleOrders);
 shopOrder.persist();
 shopOrderDTO.id = shopOrder.id;

 // fire event
 shopOrderRequestProducer.createRequest(shopOrderDTO);

 return shopOrder;
 }

Task 4.4.3 - Consume the first event

When we create a valid shop-order-request to the topic, the stock microservice will handle the event and confirm the order in case of succession or compensate the order in case of failure. It then emits events to either the shop-order-confirmation topic or the shop-order-compensation topic. Let’s create our consumer for these two cases in the order microservice.

Create a class ch.puzzle.mm.kafka.order.order.boundary.ShopOrderConfirmationConsumer which will handle all incoming events in the shop-order-confirmation topic. Define a function CompletionStage<Void> consumeOrders(Message<ShopOrderDTO> message). We annotate the consumeOrders function with @Incoming("shop-order-confirmation") to indicate that incoming events in the shop-order-confirmation channel will be handled by this function. Inside the function we want our ShopOrderService to confirm the order, which updates the status to COMPLETED. Be careful though, the changing of the status will follow in a database commit which is a blocking operation. With quarkus reactive messaging blocking operations are only allowed in reactive context when executed from a worker thread. Spawning worker threads can be achieved by using the quarkus-smallrye-context-propagation class SmallRyeManagedExecutor which propagates the context properly into the new threads.

The consumer could look something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17



@ApplicationScoped
@Traced
public class ShopOrderConfirmationConsumer {

 @Inject
 ShopOrderService shopOrderService;

 @Inject
 SmallRyeManagedExecutor executor;

 @Incoming("shop-order-confirmation")
 public CompletionStage<Void> consumeOrders(Message<ShopOrderDTO> message) {
 executor.runAsync(() -> shopOrderService.confirmOrder(message.getPayload().id));
 return message.ack();
 }
}

To connect the defined channel in the @Inbound annotation to the kafka broker we need to add a few lines to the application.properties:

1
2
3
4
5



mp.messaging.incoming.shop-order-confirmation.connector=smallrye-kafka
mp.messaging.incoming.shop-order-confirmation.topic=shop-order-confirmation
mp.messaging.incoming.shop-order-confirmation.value.deserializer=ch.puzzle.mm.kafka.order.order.boundary.ShopOrderDeserializer
mp.messaging.incoming.shop-order-confirmation.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor

We add some boilerplate code around the consumer to make the propagation of the tracing headers work:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29



@ApplicationScoped
@Traced
public class ShopOrderConfirmationConsumer {

 private final Logger logger = LoggerFactory.getLogger(ShopOrderConfirmationConsumer.class.getName());

 @Inject
 ShopOrderService shopOrderService;

 @Inject
 Tracer tracer;

 @Inject
 SmallRyeManagedExecutor executor;

 @Incoming("shop-order-confirmation")
 public CompletionStage<Void> consumeOrders(Message<ShopOrderDTO> message) {
 Optional<IncomingKafkaRecordMetadata> metadata = message.getMetadata(IncomingKafkaRecordMetadata.class);
 if (metadata.isPresent()) {
 SpanContext extract = tracer.extract(Format.Builtin.TEXT_MAP, new HeadersMapExtractAdapter(metadata.get().getHeaders()));
 try (Scope scope = tracer.buildSpan("consume-confirmation").asChildOf(extract).startActive(true)) {
 executor.runAsync(() -> shopOrderService.confirmOrder(message.getPayload().id));
 return message.ack();
 }
 }
 return message.nack(new RuntimeException());
 }
}

Extend the ShopOrderService with the confirmOrder method:

1
2
3
4
5
6
7



 @Transactional
 public void confirmOrder(Long id) {
 ShopOrder shopOrder = ShopOrder.findById(id);
 shopOrder.setStatus(ShopOrderStatus.COMPLETED);
 shopOrder.persistAndFlush();
 }

Task 4.4.4 - Compensation

Now it is up to you to do the same for the shop-order-compensation events. Create a consumer listening on the “shop-order-compensation” topic to compensate your failed orders. Create a class ShopOrderCompensationConsumer in the same package as the ShopOrderConfirmationConsumer and update your application.properties to connect your defined connectors to the kafka broker.

Create a class ch.puzzle.mm.kafka.order.order.boundary.ShopOrderCompensationConsumer which will confirm and compensate orders.

Compensation consumer

The class should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


@ApplicationScoped
@Traced
public class ShopOrderCompensationConsumer {

 @Inject
 ShopOrderService shopOrderService;

 @Inject
 Tracer tracer;

 @Inject
 SmallRyeManagedExecutor executor;

 @Incoming("shop-order-compensation")
 public CompletionStage<Void> consumeOrders(Message<ShopOrderDTO> message) {
 Optional<IncomingKafkaRecordMetadata> metadata = message.getMetadata(IncomingKafkaRecordMetadata.class);
 if (metadata.isPresent()) {
 SpanContext extract = tracer.extract(Format.Builtin.TEXT_MAP, new HeadersMapExtractAdapter(metadata.get().getHeaders()));
 try (Scope scope = tracer.buildSpan("consume-compensation").asChildOf(extract).startActive(true)) {
 compensateOrder(message.getPayload());
 return message.ack();
 }
 }
 return message.nack(new RuntimeException());
 }

 private void compensateOrder(ShopOrderDTO shopOrderDTO) {
 executor.runAsync(() -> shopOrderService.compensateOrder(shopOrderDTO.id));
 }
}

Do not forget to update your application.properties as well to connector your defined connector @Incoming("shop-order-compensation") to your kafka broker and topic.

1
2
3
4


mp.messaging.incoming.shop-order-compensation.connector=smallrye-kafka
mp.messaging.incoming.shop-order-compensation.topic=shop-order-compensation
mp.messaging.incoming.shop-order-compensation.value.deserializer=ch.puzzle.mm.kafka.order.order.boundary.ShopOrderDeserializer
mp.messaging.incoming.shop-order-compensation.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor

Task 4.4.5 - Add business to your service

In the business parts of the ShopOrderService you will add logic to confirm and compensate your orders! Add the two following functions to your service:

ShopOrderService::compensateOrder: Find order with id id, set status to ShopOrderStatus.INCOMPLETE and save and flush.
ShopOrderService::confirmOrder: Find order with id id, set status to ShopOrderStatus.COMPLETED and save and flush.

Business hint

These two functions could look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Transactional
public void compensateOrder(Long id) {
 ShopOrder shopOrder = ShopOrder.findById(id);
 shopOrder.setStatus(ShopOrderStatus.INCOMPLETE);
 shopOrder.persistAndFlush();
}

@Transactional
public void confirmOrder(Long id) {
 ShopOrder shopOrder = ShopOrder.findById(id);
 shopOrder.setStatus(ShopOrderStatus.COMPLETED);
 shopOrder.persistAndFlush();
}

Docs: 4.5 Running the Lab

Mon, 01 Jan 0001 00:00:00 +0000

In the previous section we implemented the microservice. Let’s build and run it.

Building

The kafka-order microservice provides a multistage Dockerfile.multistage.jvm for building the java application and creating a docker container.

Task 4.5.4 - Build docker container

Docker Version

Depending on your docker version you have to specify the output format. If you get a warning that there is no output specified for docker-container driver just add -o type=docker to your command line.

Change to base directory of this lab <PROJECT_ROOT>/code/kafka and run docker build.

1

docker build -f kafka-order/src/main/docker/Dockerfile.multistage.jvm -t microservices-lab-kafka-order:latest kafka-order

Running

Task 4.5.2 - Starting with Docker Compose

Enter a shell and change your directory to the <PROJECT_ROOT>/code/kafka/docker folder.

If you have any previous lab running stop these containers

1

docker-compose down --remove-orphans

Start the microservices with

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


docker-compose up -d
Starting docker_order_1 ... done
Starting docker_stock_1 ... done
Starting docker_viewer_1 ... done
Starting debezium-kafka ... done
Starting debezium-zookeeper ... done
Starting docker_prometheus_1 ... done
Starting docker_grafana_1 ... done
Starting docker_alertmanager_1 ... done
Starting docker_stock-db_1 ... done
Starting docker_order-db_1 ... done
Starting docker_jaeger_1 ... done

Docs: 4.6 Using the Lab

Mon, 01 Jan 0001 00:00:00 +0000

Test your microservice

If your microservices are all up and running, open two tabs in your browser. View the kafka-viewer microservice on http://localhost:8082 and open up the Jaeger UI on http://localhost:16686 . The kafka-viewer will open up an active connection to your kafka topics and show you messages passing through the topics. In the Jaeger UI you can follow your traces through the system.

Now fire a request against the order API to create a new shop order. Let’s do a POST request to our /shop-orders endpoint and create a shop order with 2 pieces of article 1 and 3 pieces of article 2.

Request Task Hint

Create the POST request with curl.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16



curl --request POST \
 --url http://localhost:8080/shop-orders \
 --header 'Content-Type: application/json' \
 --data '{
 "articleOrders": [
 {
 "articleId": 1,
 "amount": 2
 },
 {
 "articleId": 2,
 "amount": 3
 }
 ]
}'

Check your browser and see what insights the kafka-viewer and the Jaeger UI give us. You can clearly see where the event was passing through our system in the Jaeger UI. The trace passes from the order microservices’ ShopOrderResource REST resource to the shop-order-request topic on kafka (seen in the kafka viewer) with some content like:

1

{"articleOrders":[{"amount":2,"articleId":1},{"amount":3,"articleId":2}],"id":100017}

Will then be passed to the shop-order-confirmation topic to be again confirmed by the order microservice! Our workflow now works.

Task 4.6.1 - Follow your traces through the code

Can you follow the traced produced and observed in the Jaeger UI through your own code?

Task 4.6.2 - Compensation instead of confirmations

Can you try to get a compensation event to test your compensation workflow as well? Try to provoke an error to make the stock microservice deny the order!

Compensation Hint

Create the POST request similar to the one before, but let the article amounts go nuts! That way the stock microservice will throw a ArticleOutOfStockException.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16



curl --request POST \
 --url http://localhost:8080/shop-orders \
 --header 'Content-Type: application/json' \
 --data '{
 "articleOrders": [
 {
 "articleId": 1,
 "amount": 20
 },
 {
 "articleId": 2,
 "amount": 30
 }
 ]
}'

Task 4.6.3 - Observability test

Can you identify where the problem was in the previous request by just using our observability stack?

Observability Hint

Of course you can! Head over to the Jaeger UI and inspect the latest traces. You will directly see a trace with two errors. If you open the trace and inspect the spans you can investigate the error that happened and you will find the wanted ArticleOutOfStockException.

Task 4.6.4 - Enhance and Test observability (optional)

Optional Section

The following content is optional. If you have time, feel free to proceed.

Your task now is to enhance the observability in your order microservice. We would like to see metrics to see how many messages we produce and consume in the microservice. In order to do this you will add metrics to your microservice to track:

order_requests_produced
order_confirmation_consumed
order_compensation_consumed

Hint: In other labs you have already exposed custom metrics. Try to implement your own now!

Observability Hint 2

You can annotate your existing functions which handle incoming and outgoing messages with your custom metric like this:

1
2
3
4
5
6


 @Counted(name = "kafka_order_requested", absolute = true, description = "number of orders requested", tags = {"application=kafka-order"})
 @Traced
 public void createRequest(ShopOrderDTO shopOrderDTO) {
 ...
 }
 }

You can implement the consuming counterpart just the same!

Can you identify with your newly implemented metrics after rebuilding and rerunning your system how many messages were confirmed and compensated after some requests?