navigation

Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 3: Email service and Gateway

Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 3: Email service and Gateway

by
November 21, 2017
Dreamix, frontpage, Java
7 Comments

After Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 1: Service registry and Config server and Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 2: Message Broker and User service here is what comes next:

Email Service

Next step with building our system is the email service. It will be a microservice configured to listen for the USER_CREATED_TOPIC that comes from the user service. Here we will build an UserDto and will configure the Kafka consumer to transform the incoming payload to it. Similarly to the user microservice here we will have EmailService where the business logic will be executed. This EmailService will be using the UserDto from the payload, will transform it to Mail entity, will save it in the database and will send the mail.

In addition to Eureka Discovery; JPA; H2; Kafka; Config Client; to the new Spring Boot project(ms-mail) in SPRING INITIALIZR it is necessary to add Mail dependency as well. So the pom.xml looks like:

/pom.xml

Sending mails is configured to use gmail. It is necessary to replace username and password with real values. This is the mail which will be used as a sender of the confirmation.

/ms-mail.yml

To be able to read the messages from Kafka, we need to configure ConsumerFactory and wrap KafkaListenerContainerFactory. As well as the ProducerFactory it needs some configuration properties to be set. @EnableKafka is needed to enable detection of @KafkaListener annotations on any Spring-managed beans.

/ReceiverConfig.java

Then in the method annotated with @KafkaListener we add the logic we want to be invoked when a message is received.

/Receiver.java

As mentioned above EmailService is the place where we transform the incoming payload, send the email and save it for future reference.

/EmailServiceImpl.java

To test if everything is fine, build and run the project:

  • 1. Verify Service registry (Eureka) is running (http://localhost:8761)
  • 2. Config server (Spring Cloud Config) is running and ms-user and ms-email configuration is available (http://localhost:8888/ms-user/default)
  • 3. Build the project: mvn clean install
  • 4. run java-jar ms-mail-0.0.1-SNAPSHOT.jar
  • 5. Create new user with the following:

  • 6. Verify user was created: check if an email was received on email@example.com

Gateway (Zuul)

As you can see from the previous example, to register an user you should know the details about its service (server ip/port) to query it. Imagine a really complex system with dozens of microservices working together. To solve this we will create a new service(Zuul) that will be the front door for all other microservices. Clients will call this microservice and it will delegate the requests to the appropriate one.

Building Zuul service with Spring Boot is as easy as for the previous microservices. With SPRING INITIALIZR create new (ms-gateway) project and Eureka Discovery; Config Client and Zuul dependencies

/prom.xml

We configure the microservice Cloud config client

/bootstrap.yml

Add also @EnableEurekaClient to enable EurekaClient configuration as well for the other microservices. The Zuul functionality is enabled with @EnableZuulProxy annotation in the Application.java file.

Some routing configuration is necessary to be added, for the Zuul to know which request to which service should be redirected. We do this in git config file.

/ms-gateway.yml

With this configuration any request to 8765:/api/user will be redirected to the ms-user microservice. And Zuul will take its address and port from Eureka.

To test if everything is fine, build and run the project:

  • 1. Create new user

  • 2. Verify an user was created

We saw how to easily build microservice system which sends emails on registration with Netflix OSS, Apache Kafka and Spring Boot. The full implementation of these 3 parts can be found in the GitHub. Feel free to give your comments and give suggestions based on your experience.

You can find more information on the topic in the next part of this blog:

Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 4: Security

Iskren Ivanov

Java Expert at Dreamix

More Posts

Do you want more great blogs like this?

Subscribe for Dreamix Blog now!

  • cblin

    Your article is great, thank you !

    The only thing I disagree with is the ms-mail : one ms should not be responsible to listen to the bus AND to deal with the mail protocol.

    That is ms-mail should simply provide a REST API to send mail

    Then, ms-user-welcome_email should simply listen to the bus and call the REST API via discovery

    That way, for example, you can completely outsource the email delivery to a third party provider

    I know this project is only an example but this can lead to confusion if you dont talk about that (which directly relates to https://12factor.net/backing-services)

    What do you think ?

    • Iskren Ivanov

      Yep, I agree but yet trying not complicate it. Thanks for the remark.

  • Dmitrii Rodionov

    Great article, thanks! Could you please add one more article and setup authorization for the services?

    • cblin

      I would also like that, especially with JWT and explaining how it works with Zuul

      • Iskren Ivanov

        Thanks for the interest guys. I’ll add new part with auth server setup. Hopefully will be ready in a week or two

  • Jegan

    Hi Ji,

    Thanks for your great article with clear explanation.

    I’ve doubt that if i create the JSP Pages then it should be placed in the ms-gateway/src/main/webapp/WEB-INF/pages and action path should starts with http://localhost:8765/api/user/{dynamic_path}.

    Is it correct or JSP pages can be placed in any of the service application than ms-gateway?

    Thanks,
    Jegan

    • Iskren Ivanov

      Hey, Jegan,

      there are 2 approaches for the UI in the microservice world.
      – The one approach is every microservice to have its own frontend and all to be “assembled” to work together
      – The other approach is to build one frontend that calls the other microservices to take data from them.

      The two approaches has positive and negative sides. The first one is the more “microservice” approach. In any case it is not good idea to place the UI in the gateway.
      I personally prefer the monolith one, creating separate UI project
      you can google “composite vs monolith microservice ui” for more information

      Regards
      Iskren