Microservices with Spring Cloud

[00:00:00]
>> Josh Long: So I'm going to close this out. This is all modulith is how you build modular systems in a single jvm. Obviously, even with that, even this monolithic example, I still had easy interop with external modules right through the externalized module. And I talked to a database and there's other moving parts, but sometimes, sometimes, sometimes, sometimes you've got to build a distributed system.

[00:00:24]
There's more than one service in your system. Just do you have more than one service in your system? I mean, I was kind of being facetious, but yeah, of course you do. Even if you're not intentionally building a microservice system today, there's a lot of moving parts in most people's systems.

[00:00:39]
And there are things that sort of naturally fall out of that arrangement that you need to care for, right. Things that are just a natural part of the complexity of building these kinds of systems. And so we have a project called Spring Cloud. Spring Cloud is a set of extensions for building distributed systems and microservices layered on top of Spring Boot, okay.

[00:00:59]
And there's several different things that you can use there to make your life a little bit easier. So I'm going to talk to you about just a few of them right here. Okay, so let's go back here. Start Spring IO. What we're going to do is I want to do.

[00:01:10]
I need to set up some moving parts, some infrastructure, olkay. First things first. If I have more than one service, I'm going to want to have a single place to get my configuration. When I say configuration, I mean keys and values. You've seen me talk about environment variables or property files, whatever.

[00:01:26]
But I also mentioned in passing things like HashiCorp Vault or the Spring Cloud Config Server. I love the Spring Cloud Config server. So let's create one of these. Okay, Config Server Web Enter Open uio. Here we go. So now what this is going to do is it's going to give me a API that will babysit or mediate access to a directory full of configuration or a hosted sort of repository of configuration, right.

[00:01:56]
As long as it's git, I'm using a git repository. And this will run in Port 8888, which is, you know, bad luck in the Far East. Sorry about that. And it's just the default port. So okay, the last thing you need to do is to say, enable Config Server.

[00:02:12]
So Enable Config Server, point to a directory full of config. That directory exists on my desktop Here, it's a directory full of config files. You can see it's got to get. The code is public. Please feel free to take it. All right, so GitHub. Sorry, did I start this?

[00:02:36]
I didn't start this. So now we're going to localhost 8888 and I'm going to go for the configuration for the Auth server in the default profile. Okay, so you can see it says Auth and then we have this concept of a profile. A profile in Spring is a label that you can attach to objects to determine whether they're loaded or not.

[00:02:59]
For now, actually, for most of what you do, just stick with the default profile. You don't need to worry about it much, but it can be useful in some rare cases. So the Auth is the name of the service and then the default profile. When I ask for the Auth configuration, what I get is two property sources that contains the details of whatever's in application properties and whatever's in Auth YAML.

[00:03:24]
Now I'm going to set up another service which is going to consume this configuration. It's going to identify itself as Auth, for example, and say, hey, I need configuration. For me, I'm called Auth. What is my configuration? Well, since this lives in the config server, I can change the configuration without having to change the.

[00:03:42]
I don't have to redeploy the service. So let's try that. Let's create a simple service here. Start Spring IO and I'll call this service again because I'm great with names. I'll use the config client, I'm going to use the web support, I'm going to use the discovery client support.

[00:03:59]
So I've got that. I'll go ahead and leave the discovery client in there. I'll use the web, I'll use the config client, open that up just like before. In order to do service registration and discovery, I need a service registry, something like Hashicorp Console. Something like Zookeeper Apache, Zookeeper, something like Netflix Eureka, etc.

[00:04:19]
So Netflix Eureka is, by the way, a lot of these patterns came from Netflix, right? This is a project that was originally built on the integrations that we built on top of Netflix, and this project came out in 2015. Netflix, remember, they have famously deployed on AWS their entire time, right?

[00:04:36]
It's always been aws, but there are things you need to do to tame the cloud environment on aws, right? Even today. So they built a lot of infrastructure to sort of make that more approachable to Russell, that complexity down. And we they open source a lot of it.

[00:04:53]
We then packaged it up as Spring Cloud components. These components are reusable, they're open source, but they also inspired abstractions because there are several other players in a lot of these different spaces. So I'm going to use Eureka, which is from Netflix. It's a service registry. So I'm going to go back here, start Spring IO, I'm going to build a Eureka.

[00:05:12]
I'll use the Eureka service registry. I'll use the web support, I'll use the config client. Okay, here we go. Enter UAO Eureka. Okay, so now application properties. Well, first of all, you go to the Eureka Java code. You say, enable Eureka server. I guess I don't need to Eureka.

[00:05:40]
Did I add the wrong one? Wrong one. I want the Eureka server. Copy and paste. Okay, Command shift. I reload, go back to my Java code. Enable Eureka server. Okay, that's the hard part. Well, maybe this is also difficult. So I'll do port 8761 and I'll tell it not to register with itself.

[00:06:17]
Register with Eureka, false. Now I'm going to start up this code. I did a lot of code there. I don't like doing that much code for no reason, but I did. I've also told it to get its config from the config server. So now this is the first thing that will act as a config client actually.

[00:06:31]
So I'm not sure if I put this in the config server. So I'm going to go ahead and create a new. This is a service called Eureka. I'm going to create a new config file in my directory full of configuration called Eureka Properties. Okay, so paste that in.

[00:06:50]
Git Add Eureka git, commit Eureka git push, okay. Okay, authorize, good. All right, so now I've got a Eureka instance. So let's restart it. It's going to start up. It's going to draw the configuration from that property file by default. That means it's going to run in Port 8761.

[00:07:20]
There's Eureka. This is a full blown service registry that I just with that one annotation. So this is Spring boot standing up a web service that actually does service registration discovery. Remember I drew the configuration, there's no config here, right. All I did was I said, hey, microservice, draw your configuration from the config server running on the default host and port the way you would specify that is by overriding this part right here.

[00:07:48]
If you don't specify it, it goes to localhost8888. That config server is over here. I can go back to Eureka and there's the config files called Eureka Properties and Application Properties. So whatever the name of the microservice, the name is Eureka. It'll look for Eureka in there and it'll return the property file called Eureka Properties or Eureka YAML.

[00:08:13]
All microservices, no matter what they're called, will see whatever is in Application Properties. Only the microservice called Eureka will. We'll see what's in Eureka Properties. So far, so good. So this is a composite, and if you have the duplicate key, if you have server port equals foo and it's server port equals bar over here, then the more specific file overrides the least specific one.

[00:08:33]
Okay, so I've got a Eureka service registry, and that service registry is in turn drawing its config from the config server. Now I want to create a microservice that talks to both the config server and the Eureka service registry to advertise if its location. A service registry is a great way to advertise what services are available.

[00:08:51]
Remember, DNS is not your friend. It's always DNS, right. DNS is flaky. It encourages caching, which is great for the overall large web, but it's really bad for dynamic turbulent volatile microservice systems and cloud native systems, where things come and go all the time. So you don't want DNS.

[00:09:08]
DNS is the enemy, right. Use a service registry. So I've got this. Where's my. I've got the config server. I've got my service. Well, this is going to draw its configuration from the config server. Same thing. I just put that in there. Okay, and I don't even know what's in the config server for service.

[00:09:26]
Let's go find out. Okay, you can see if it's modulus, I'm ready to go, if I've GraphQL, I'm ready to go, etc. So pretty good. Pretty standard stuff. Nothing special though. Is there any. No prescription on the port? Nope. Okay, good. So this is a service in the service.

[00:09:41]
I'm going to inject the current port. I'm going to get the current port. So I'll say void on startup and I'm going to listen for the web server initialized event, okay. Why am I going to do that? Because I want to get the current port and stash it so that I have a value.

[00:10:01]
So event get web server, get port. I'll say this port set. Is that okay? And I shall create a rest controller at response body. And I'll go over here, I'll say get mapping. Hello, whatever, right. Map string, string. Hello. Hello, okay. Okay, hello from port. There you go, okay.

[00:10:47]
Pretty straightforward. Put that in there. So now let's start this service up. I want this to run on a random port. So I'm going to modify the config file here, right? I'll just say start on a random port. Server port equals zero means start on a random port.

[00:11:00]
Yeah, it just picks any port that's not used. So I'm going to start this up. Remember its name is service. So if I go now to service registry, my Eureka instance over here, there's an instance of service, right? And here's the host and port, the domain, et cetera.

[00:11:17]
Not bad. The problem with this, like let's say stop it, okay? Now the service is down, eventually it'll disappear, but it's down, it's flagging. We can't establish a heartbeat with it anymore. The problem with this is that Eureka doesn't distinguish between multiple nodes on the same host and port.

[00:11:34]
Sorry, the same host, you need to distinguish by port. So what I would do is I'll say Eureka id. Instance ID is equal to. I'll use UUID and then spring application name. Okay, that'll give this instance a random name or somewhat randomized name, right? So now if I refresh, you can see it says random-service.

[00:11:58]
Okay, so now if I run the program again, I'm going to run the same service multiple times. So I'll say you have to tell Intellij to run multiples, right? It doesn't do it by default. So where is that config thing? Allow multiple instances apply. So now I start this again there I got two instead of rewriting the existing one.

[00:12:27]
So now I go back over here. Now there's two instances of the service in the service registry. So now if I go to one of these host and ports, that's the actuator input. By the way, if you have the actuator, it'll check that and surface information there. So it's saying one instance was Living on Port 49918.

[00:12:48]
So if I go there, I can get, hello, I've got the service registry. You can programmatically interact with that service registry. You can ask IT questions, We can do things for you with that service registry as well. For example, if I want to make a REST request from a client, I can do client side load balancing.

[00:13:08]
Before I make the REST call, the client will look at the service registry and say, which service instance is available? I'll take that one. Please send the request that way. And you can do round robin, you can do sticky sessions, you can do all sorts of different kinds of load balancing in the client.

[00:13:22]
This means that, remember, there's no such thing as one true load balancing. Just because one service is using load balancing that's round robin doesn't mean that's good for everybody else. And this is the problem with having centralized gateways that do that kind of stuff. It's not one size fits all.