Hey, what's up, everyone?
And welcome to daily code buffer. In this video, we are going to see a complete microservice
architecture in springboard. So we'll be creating a couple of
microservices, and then we'll be creating a service registry, and we will connect
those microservices with service registry. We'll be creating an API gateway so that all our requests will be
traversed through an API gateway. We'll create our micro service
as a resilient micro service. We'll be creating a circuit breaker, and also we'll be creating a
distributed lock tracing as well. So without any further Ado, let's get
started and create our microservices. So this is a complete architecture
that we are going to build it today. So we'll be creating a two micro services that is a Department
service and a user service. Every user will be tagged
to any of the Department. We'll be saving a user from one service, and we'll be saving a Department from one
service, and we'll create a couple of methods to get the Department and to
get the user information as well. We'll create a method to fetch
the user with its Department. So we'll have a call from user service to a Department service
using a rest API call. So from there, we'll get an idea how to connect and how to call a
different micro services. And then what we'll do is we'll
create a service registry. Okay, you can see that in the diagram. We'll create a service registry. All the micro services will be connected
to that particular service registry. So when there are multiple micro services, all the micro services will be tacked
to a particular service registry. We can get an idea, what are the different micro services available and the
status of all the micro services? And then what we'll do,
we'll create an API gateway. So API gateway will be just a gateway for all the APIs that we have
in our micro services. So all the request shouldn't be
directly going to micro services. They should be going from one API gateway, and from there they should be travels
according to the micro services URL pattern or whatever the other
information we can give for that. So we'll create this API gateway, and this
API gateway will be responsible to travel through the appropriate micro
services that we have created. Now, once we do that, suppose if there is
any failure in any of the micro services, like, suppose a Department service is not
working or a user service is not working, and we are calling a Department
service from our user service as well. So when we are calling a Department service from a user service, suppose
the Department service is not working. So we should get to know like, okay,
Department service is not working. So we should directly send a message to a particular user who is
trying to access it. So for that, what we'll do is we'll
create a timeout for the particular API. If you're not getting a response in a particular time frame, then we should call
a fallback method that fall back method will notify the user or notify the
other micro services like this. Microsoft is not working, so you can
proceed ahead with the other approach. Now, once we implement this historic
circuit breaker, we should also be able to visualize how much my APIs or how much my
endpoints are failing and how much are getting successful and also which of
my micro services is not working. So for this, we will implement
a historic dashboard. So from that historic dashboard, we will be able to identify which all
services are not working. Now, once we are done with that,
we will implement a config server. Considering we have a multiple micro service like hundreds and
thousands of microservices. And for all the microservices, there might
be some few of the configurations that would be repeated for
all the micro services. Okay, so it's not a best practice to add the configuration in
all the micro services. Suppose if there is a change in any one of them, then we need to go to all
the microservices and change it. So rather what we'll do, we'll create a
cloud config server, we'll create a Git repository, and all our configuration will
save there, and we'll create a cloud config server which will read that Git
repository, and it will give all the configurations to all the micro
services connected to it. So that will be easier for us to maintain
the configurations just change at one place and it will be available
to all the microservices. After that what we will do. We will add the distributed login. So if there are multiple micro services,
we should be able to identify which micro services is failing and where
our request is traversing. So for that we will use
Zipkin and Sluth libraries. We will create a Zipkin server, and then we will implement the Zipkin client and
Sleuth libraries in all our microservices. So from there we will be able to
implement a distributed login. Now this youth provides a
multiple options over there. We will be able to identify which
of the services been called. What is the trace ID? What is the span ID the service will contain from which service
this log has been traced? Trace ID will be a unique ID
along the entire request. So if you are requesting
to get a user details. So our call is like to get a user details alongside to get a Department
details from the Department service. So that request will contain two service
ideas like user service, Department service, and for both of them,
trace ID would be unique. That is a single one. And for both of them there will be a different span IDs, one span ID for our
user service, and one span ID for our Department service, and there will
be export details as a fourth flag. So we will see all this in
action when we start our demo. So all the details will help us to
identify how micro services work together and how we can create the micro services
from our monolithic application. And we will get an idea how to deconstruct our entire monolith application
into a different micro services. And we'll get an idea how to create a resilient micro services using
a different circuit breaker. Zipkin sleuth libraries for
a distributed log phrasing. We can also implement El Kiss tech
for a centralized logging purpose. So there are many things that we can do for implementing our micro
service architecture. So let's get started while creating our simple microservices that is a
Department service and a user service. And then we will go forward and implement the other API gateways and a
circuit breaker and everything. So let's go to a computer and let's
start building the micro service. So here we are in our desktop and we'll go to the browser and we'll start by
creating the Department micro service. We'll just go to our screen initializer, and here we'll give the
details like the code buffer. We'll do the description as Department service,
and we will give the package name as Department and packaging would
be war Java version eleven. And yeah, we'll add the dependency. Yeah, we'll add the web dependency. We'll be doing a GPA call to our database. So both the web services will be having their different databases
for the demo purpose. I'm using the actual database, but you can
use any of the database that you prefer. I'll just include JPA library. I'll include H two. I'll include Lombok for creating the POJOs spring web spring data,
JPA H two and Lombok. So this is all what I need as of now. So let's just create the project and I will open this project
in our intelligent idea. So you can see that our project
is open in our intelligent idea. Let's go and create the classes
and packages over here. Okay. So in your main resources, let's first
create the application YAML file, create the application YAML file,
and then let's create the packages. Okay, we'll go to Java. This is my main class. Let's create the packages over here. We'll create the entity package for our entities controller package service package and a repository package. Now let's create the entities over here in our entities package will create
the entity Department, right. Because they're creating
the Department service. They are notate with entity, and we'll
create the different properties. Private long Department ID, private private string Department name, private string Department address, private string Department code. And now my Department ID
would be primary key. So I will annotate with aspirate ID
and it will be auto generated. So I will just give generated value
strategy equals to generation type auto. Now we'll also use zombie over here to
create the Geta setters and constructors. Okay, so I'll just annotate with add rate, data rate, all ALG constructor
and editor know alls constructor. My entity is ready.
Now. Let's create the repository. I will create the repository over here
Department. I will annotate this
with other repository. And this will extend
and we'll give the typo.
