[Big Talk Cloud Native] Load Balancing - Small restaurant traffic has increased

I. Introduction

This is the second part of the "Dahua Cloud Native" series. The first one, "The Relationship Between Dumplings, Docker, and Kubernetes" , was well received by everyone after its launch. Many friends contacted me to cheer me on, and also got the CSDN header. The support of the blogger Nezha, thank you! I will keep writing!

After the book introduced "The Relationship Between Dumpling Cooking, Docker, and Kubernetes", Xiaona (my wife) asked: Why not develop the service into one application? What are you doing distributed? It feels huge and complicated, doesn't it? Why do you do this? So Dahua Cloud Native Part 2 - Load Balancing, start now!

Second, from the roadside stalls

I worked overtime on Friday night, and it was very late when I got off work. I called Xiaona and planned to have a barbecue, so I went to the "husband and wife stall" that we often go to for barbecue. After arriving, I found that the "husband and wife booth" has been upgraded, and now it has become a "husband and wife restaurant". Since it was relatively late, there were not many people in the store, so I chatted with the proprietress. Talk about yesterday, today and tomorrow of the small restaurant!

The proprietress introduced: "We were just married at the roadside stall, and we had limited funds, so we wanted to open a roadside barbecue stall. My husband was in charge of cooking skewers, and I was in charge of serving cashiers and serving food. Some money!". The proprietress is modest, and when I get older, I might also make a living on kebabs, who makes me love to eat it! The proprietress said that the reason why I can get to today is mainly because of the following points:

• Her stall rarely has long waits for dishes. Because the capacity of the tables, chairs and benches of the booth is usually limited, and there are usually not so many guests, the upper limit of the total demand for food is basically fixed, which is relatively easy to coordinate.
• The communication is smooth and fast, the ordering and ordering roared, and the other side started to do it. When it's done, shout again and serve.
• Short and sharp, easy to turn around. The reason why the couple chose to start from a roadside stall is because the boat is small and easy to turn around. It is possible that if you find that there are few passengers in this location, you can immediately stop the operation or change the place to operate.

Hey, don't say, the couple is a bit like some software service start-up companies at this stage. When they first started their business, the application services they usually made were monolithic applications. The author has also seen some small startups come up with the idea of ​​microservice cloud native, which I think is unrealistic. The structure of the enterprise is developed step by step, don't always think about eating a fat man in one bite. If JD.com and Taobao wanted to be what they are today from the very first day they started as an app service, they would definitely not live today. It's like a person who has never opened a restaurant before opening a five-star restaurant for the first time. Nine times out of ten, he will fail!

The characteristics of the single application I mentioned here are actually similar to the characteristics of roadside stalls:

• The number of requests that can be accepted is limited. First, there are not so many users in terms of demand. Second, the resources of startups are limited, and the memory and CPU configuration of the server are limited.
• The view layer, control layer, and persistence layer of a single application are all in one application, which is easy to call and respond quickly. There is no remote RPC call between services, and the response speed is faster. Specifically, the response result of a service request is faster.
• The development is simple, the start-up is quick, and the team of three or five people is easy to use. The boss decides to quit, and he can turn around at any time, which is basically not too painful.

I still have to congratulate the lady boss for making a fortune and summarizing experience!

3. Opening a restaurant and load balancing

Some time ago, someone was willing to line up to eat the barbecue made by their husband and wife. When the husband and wife thought about it, the two of us couldn't do it. What should we do? Recruit people and expand.

• Who are you hiring? Of course, it's the chef. The wife who serves the dishes and the cashier can still do it herself. The main reason is that the husband's job can't stand up. Yes, then hire a chef.
• Can't let the extra guests eat standing up? Rent a nearby store and add more tables, chairs and benches.

In the same way, what should I do if a single application service in a software application can't handle user needs? Add servers, deploy more services, and load balance.

Talk about client-side load balancing and server-side load balancing

• The young couple has deployed three chefs (including the husband) for the restaurant in one breath, which is enough. The wife gave the single-numbered order to Chef Zhang and the double-numbered order to Chef Li. Both of them couldn't do it, so they gave the order to the husband. Anyway, outsiders don't need to be white, and their family can take a break when they can. She will give it to whoever she says, and she has her own set of algorithms. This mode is "client load balancing" , the wife calls the "chef" service as a client, remembers that there are several chefs in total, and then forwards the user request to one of the chefs according to her own algorithm. When each service of our common Spring Cloud requests other microservices, it maintains a list of microservices within it, and then selects a service from the microservices to perform remote service calls according to the request target and algorithm.
• One day, the two chefs put forward their opinion: I am too tired to do this and have no time to spare. Either my husband should work harder or his salary should be raised. The husband and wife together are not very strong now, it is better for the husband to do more. Then the wife does not need to remember the "odd and even numbers of the order", and uses an app to input customer orders, which can realize the balanced distribution of orders to chefs. "This model is "server-side load balancing"" . In terms of software architecture, the app is a load balancer. Common software load balancers include nginx and haproxy. There are also some hardware load balancers, which are better in performance and of course charge more "better". The architecture is shown in the following figure:

Pros and Cons:

• The "benefit" is that the processing power of the application has increased and it can process more orders.
• The "disadvantage" is that the communication cost has increased. The problem that was solved by shouting, now needs to be forwarded by the app (load balancer). Whether it is a remote service call or request forwarding, it is time-consuming.

That is to say: the restaurant (application service) now has an increased capacity to handle request throughput, but the processing speed of a single request actually decreases. In fact, this is the result of service splitting, and service splitting is "exchanging time for space" . You finesse!

4. Communication after dinner

After eating the skewers, I gave Xiaona the above set of theories, and she was very interested: "The software architecture is really inseparable from real life, there are living examples everywhere." I took advantage of the situation and bragged: "Where is this going? Next time, I will take you to a big hotel to meet the world, a big hotel with micro-services!".