In this article, you’ll learn how to build Spring Boot and Spring Cloud microservices to create a Java microservice. The service will be a straightforward weather tool that delivers the current temperature in a specific city or zip code.
It will have a private weather resource server, a Eureka discovery server, and a public gateway API. Additionally, you will utilize Split to create a feature flag and see how this may be Hire java developers used to regulate the runtime behavior of applications.
The weather resource server will use the OpenWeatherMap API to obtain the most recent weather information.
Before you begin, let’s take a deeper look at some of the many components of this project.
API Gateway and Eureka Discovery Server
The publicly available service will be the API gateway. The service that will serve as the entry point into the microservice is this one.
The sample application will deliver processed weather information such as zip code and city names’ temps. The weather resource server, a private service in the microservice network, is where the weather data will be retrieved from.
The URI for the exclusive weather resource server won’t be hardcoded into the API gateway. Instead, a Eureka discovery server will be used to search for the address.
However, in a more extensive framework, the Eureka server enables server instances to register
themselves as they are introduced to the network and de-register themselves when they go down.
This eliminates the requirement for a discovery server in our tiny, single-instance microservice the microservice network’s equivalent of a phone directory.
The discovery server offers two key advantages:
- It separates customers and service providers without using DNS.
- Client-side load balancing is made possible.
Please note that the weather resource server does not provide weather data. As an alternative, it will get it via the OpenWeatherMap API.
The weather resource server will also implement two versions of the API. You’ll learn how to leverage Split’s feature flag service to dynamically activate and disable the V2 API in real-time
without needing to redeploy code.
Spring Security 5’s HTTP Basic authentication implementation on the API gateway will also be demonstrated.
Requirements
You must ensure that a few tools are installed before you begin.
Split: If you don’t already have an account, create one for free. The feature flags will be implemented in this manner.
HTTPie: A potent command-line tool for making HTTP requests is called HTTPie. Install it in line with the instructions on their website.
Java11: This project makes use of Java 11. Just as well will work with OpenJDK 11. You may find instructions on the OpenJDK page. Homebrew may also be used to install OpenJDK. A practical alternative for establishing and managing Java versions is SDKMAN.
Create the Weather Resource Server
The weather resource server is the first element of the microservice network you will build. This private network service will be accessible to the general public through the API gateway service. In a minute, you’ll construct the API gateway service.
Your OpenWeatherMap API key is required for this service. Make sure you’ve created a free account previously.
The API key may be found by logging into your OpenWeatherMap account, visiting the API key page, or choosing My API Keys from the account drop-down menu.
Make three Spring Boot projects in a parent directory, like split-spring-cloud-microservice.
You must generate a few files from the weather-service directory and set up the program.
Make a file that contains the weather resource server’s V1 version.
For the weather resource server’s V2 version, create a controller.
Also Check: iPhone app development agency
The API Gateway and the Eureka Server should be created
Once more, get a pre-configured starter using Spring Initializr. Run the following command from a Bash shell within the instructional project’s parent directory.
This file contains a public method callable at the endpoint /temperature/zip/zip and the Feign client interface for contacting the V1 weather resource server. There are no V2 methods or endpoints available for this currently.
In the next section, you’ll learn how to add the V2 API methods and execute a controlled rollout using Split and feature flags.
For the weather data, create the data model file.
The file on the weather resource server is precisely the same as this one.
It would help if you established the Eureka discovery server, the last component. Run the following command from the parent directory once more to get a beginning project.
The single reliance, in this case, is cloud-eureka-server, which adds the required reliances to build a discovery service.
Test the Weather App Microservice
Launch the projects by typing./min. Spring-boot:
- Leave a Bash shell quickly.
- Start the private weather resource server, then the API gateway, and then the Eureka server.
- Don’t mess it up; if you start things in the incorrect sequence, the dead will rise from their graves and rule the earth.
Visit http://localhost:8761 to access the Spring Eureka dashboard once all three services have started.
Implement a Controlled Rollout Using Split and Feature Flags
You will now employ Split’s feature flag implementation. Code may be dynamically controlled at runtime using feature flags.
Consider them dynamic variables that may change their status in real-time manually or automatically based on a wide range of customizable settings on the Split dashboard. There are many possible use cases for feature flags, but in this example, you’ll use one to mimic a controlled rollout of the V2 API.
Log into your Split dashboard.
The divided v2-deployment’s name. User traffic should now be selected.
V2 should be used for the on-therapy and v1 for the off-treatment.
You will use Spring Security 5 setup for HTTP basic auth with an in-memory user store to add a basic authentication scheme to the API gateway application so that you can deal with people.
Add the Split SDK dependency between the dependencies> and /dependencies> tags in the pom.xml file of the API gateway project.
Your application.properties file has to contain the Split API key that you have. The API keys must be compatible with the setting where you specified your Split. Default Staging should be the environment if you follow this instruction.
The ability of Split to track events registered through the Split client is the last item I want to demonstrate. The track() method on the Split client allows users to submit any event data to the Split servers, where it is logged.
The Split SDK documentation provides further information on this. This comprehensive feature allows metrics to be calculated based on tracked events and alarms to be set off.
Except for a brief demonstration of the track() function and an introduction to the API, this tutorial won’t delve too deeply into this skill.
Conclusion
There were a lot of territories you covered in this session. You learned how to use Spring Cloud to build a scalable.
How to build a microservices network that makes use of a Eureka discovery server to register and lookup services, implements a private web service that makes use of external APIs, and repackages the data for use by downstream services, and has a public API gateway that makes the service available to outside clients.
You can also hire professional expert spring boot developers in this field to develop these services.
You learned how to develop structured HTTP clients using Feign. You also learned how to use Spring Security 5 to create HTTP Basic auth to protect the app and how Split’s implementation of feature flags enables dynamic runtime modification of application behavior. You’ve now got a brief overview of Split’s event-tracking API.
| You may also read : Humanity and Technology |
2 thoughts on “How to Build a Microservice Using Spring Boot?”
Comments are closed.