YouTube.eclipse Vert.x-building Reactive Microservices in Java-Chapter 04

[email protected] [email protected] 2018 2018

Eclipse Vert.x

Eclipse Vert.x

Chapter 04

Chapter 04

Message Based Microservices

00. HTTP Main Issues

a. Reactive Microservices must be: •  Autonomous

•  Asynchronous • Resilient

• Elastic

b. HTTP based microservices as demonstrated on chapter 03 is not

Reactive Microservices, because it does not provide the resilience and elasticity.

c. It does not provide the resilience, because if the first microservice (HttpMicro01 class) fails, we won’t be able to recover by calling another one.

d. It does not provide the elasticity, if we are under load, creating a new instance of the HttpMicro01 won’t help us, because HttpMicro02 is configured to target the HttpMicro01 microservice explicitly.

e. HTTP based microservices can be Reactive Microservices if we provide some infrastructure to route virtual URLs to a set of service and a load-balancing strategy to provide elasticity and

00. Message Based MSA

a. The Vert.x Event Bus is messaging backbone for creating Message Based Microservices Architecture (MSA) that allowing the different components of an application to interact using messages.

b. Messages are sent to addresses and have a set of headers and a body.  An address is an opaque string representing a destination. Message

consumers register themselves to addresses to receive the messages. c. The Vert.x Event Bus is also clustered, meaning it can dispatch

messages over the network between distributed senders and

consumers. nodes are connected to enable shared data structure, hard-stop failure detection, and load-balancing group communication.

d. The Vert.x Event Bus provides three types of delivery semantics:

1. The send method: allows a component to send a message to an address. If more than one consumer is registered on this address, Vert.x applies a round-robin strategy to select a consumer.

2. The publish method to deliver the message to all consumers registered on the address.

3. The send method with a reply handler. This request/

response mechanism allows implementing message-based asynchronous.

00. Sequence Diagram

We will create two verticle classes with following

sequence diagram to demonstrate Message

based Microservices

 MsgMicro02 MsgMicro01

HTTP Request

Address: “AdrMsg”, Message:”Firmansyah”

Reply: “hello Firmansyah”

Reply: “hello Indonesia”

HTTP Response

01. Create MsgMicro01 Class

a. Create a directory

called “chapter04”

b. Generate the project structure using maven

inside chapter04 folder:

mvn io.fabric8:vertx-maven-plugin:1.0.5:setup \ -DprojectGroupId=io.vertx.chapter04 \

-DprojectArtifactId=msg-micro01-vertx-app \ -Dverticle=io.vertx.chapter04.MsgMicro01 \ -Ddependencies=infinispan

This command generates:

1.

The Maven project structure,

2.

Configures the vertx-maven-plugin, and

3.

Creates a verticle class (

),

4.

Adds the Infinispan dependency, an in-memory data grid that will

be used to manage the cluster. Once generated, we may

need to configure Infinispan to build the cluster. The

01. Create MsgMicro01 Class

c. Modify io.vertx.chapter04.MsgMicro01 Class

1.

Update

method :

@Override

public void start() {

// Receive message from the address 'AdrMsg'

vertx.eventBus().<String>consumer("AdrMsg", message -> { JsonObject json = new JsonObject()

.put("served-by", this.toString());

// Check whether we have received a payload in the // incoming message if (message.body().isEmpty()) { message.reply(json.put("message", "hello")); } else { message.reply(json.put("message", "hello " + message.body())); } }); }

01. Create MsgMicro01 Class

Notes:

•

This code retrieves the

from the vertx object and

registers a consumer on the address

. When a

message is received, it replies to it. Depending on whether or not

the incoming message has an empty body, we compute a

different response. As in the example in the previous chapter, we

send a JSON object back.

•

We added the served-by entry in the JSON for knowing from

which instance of MsgMicro01 class will reply the message if we

clustered MsgMicro01 class.

d. Run the MsgMicro01 Class:

mvn compile vertx:run \

-Dvertx.runArgs="-cluster -Djava.net.preferIPv4Stack=true"

02. Create MsgMicro02 Class

a. Create a directory called

“consumer” inside

chapter04 folder

b. Generate the new project structure using

maven inside consumer folder:

mvn io.fabric8:vertx-maven-plugin:1.0.5:setup \ -DprojectGroupId=io.vertx.chapter04 \

-DprojectArtifactId=msg-micro02-vertx-app \ -Dverticle= io.vertx.chapter04.MsgMicro02 \ -Ddependencies=infinispan,rx

02. Create MsgMicro02 Class

c. Modify io.vertx.chapter04.MsgMicro02 inside

the start method with following logic:

1. Use the event bus to send a message to the

address and extract the body of the reply.

2. Use the zip operation to retrieve the two responses and build

the final result.

3. In the subscribe method, we print the final result to the console

or print the stack trace.

4. Add an HTTP server, when an HTTP request is received, we

send a message to the

twice and return the built

result as a HTTP response.

d. Run the MsgMicro02 Class:

mvn compile vertx:run \

-Dvertx.runArgs="-cluster -Djava.net.preferIPv4Stack=true"

e. Browse URL http://localhost:8082/ and

look at the application output.

03. Elasticity Demo

a. Use Ctrl + C to shut down all the application.

b. Package MsgMicro01 app as a fat jar file

mvn clean package

c. Open two different terminals in the chapter04

directory and issue the following command (in

each terminal):

java -jar target/msg-micro01-vertx-app-1.0-SNAPSHOT.jar --cluster -Djava.net.preferIPv4Stack=true

d. Package MsgMicro02 app as a fat jar file

mvn clean package

e. Open a terminal in the consumer directory and

issue the following command

java -jar target/msg-micro02-vertx-app-1.0-SNAPSHOT.jar --cluster -Djava.net.preferIPv4Stack=true

03. Elasticity Demo Notes

a.

Elasticity can be achieved more easily using message

microservices compare to HTTP microservices,

especially using Vertx Tool.

b.

HTTP microservices is not enforcing elasticity,

because the HTTP microservice was targeting a

specific instance of the microservice using a

hard-coded URL (IP Address and Port).

c.

The two instances of MsgMicro01 are used. The Vert.x

cluster connects two instances, and the event bus is

clustered. Thanks to the event bus round-robin, the

Vert.x event bus dispatches messages to the available

instances and thus balances the load among the

different instances listening to the same address.

d.

So, by using the event bus, we have the elasticity

04. Resilience Demo

a.

Use Ctrl + C to shut down all the application.

b.

Modify

start()

method on

io.vertx.chapter04.MsgMicro01 Class

c.

Modify

start()

method on

io.vertx.chapter04.MsgMicro02 Class

d.

Launch MsgMicro01 app in the chapter04 directory

using following command:

mvn compile vertx:run Dvertx.runArgs="cluster -Djava.net.preferIPv4Stack=true"

e.

Launch MsgMicro02 app in the consumer directory

using following command:

mvn compile vertx:run Dvertx.runArgs="cluster -Djava.net.preferIPv4Stack=true"

04. Resilience Demo Notes

a.

Even though the system get failure or / and don't get

the response, we don’t crash, we don’t limit our

scalability, and we can still handle requests.

b.

We implement retry to retrieve the value if it gets a

failure in the form of a timeout or an explicit failure.

c.

We implement timeout to improve the user

experience, we should always reply in a timely fashion

to the user, even if we don’t receive the responses

from the service.

d.

Now we can reload the page and will always get a

result, even if there are failures or timeouts.

Remember that the thread is not blocked while calling

the service, so we can always accept new requests

and respond to them in a timely fashion.

Thank You!

 Any questions? You can find me at

[email protected]

Credits

PPT: ALLPPT.com