[Dark Horse Programmer] - Complete set of microservices - Practical part 1

Table of contents:

1. Microservice technology stack tutorial 1
2. Microservice technology stack tutorial 2
3. Understanding microservices-service architecture evolution
4. Understanding microservices - Comparison of microservice technologies
5. Understanding microservices-SpringCloud
6. Service Splitting-Case Demo
7. Service splitting-service remote invocation
8. Eureka-provider and consumer
9. Eureka-eureka principle analysis
10. Eureka-Build eureka service
11. Eureka-Service Registration
12. Eureka-service discovery
13. Ribbon-Load Balancing Principle
14. Ribbon-load balancing strategy
15. Ribbon - Hungry Loading
16. Nacos-Understanding and Installing Nacos
17. Nacos-Quick Start
18. Nacos-service multi-level storage model
19. Nacos-NacosRule load balancing
20. Nacos-weight setting of service instance
21. Nacos-Environment Isolation
22. Nacos-Nacos and Eureka comparison

1. Introduction to Microservice Technology Stack 1

Why should you learn microservices framework knowledge?

What microservice knowledge do you need to learn?

2. Introduction to Microservice Technology Stack 2 

What microservice knowledge do you need to learn?

 

learning path

3. Understand microservices-service architecture evolution

Monolithic architecture:Concentrate all business functions for development in one project and deploy them as a package.

The advantages and disadvantages of monolithic architecture are as follows:

• advantage:
  • Simple architecture
  • Low deployment cost
• shortcoming:
  • High degree of coupling (difficult to maintain and upgrade)

Distributed architecture

Distributed architecture: The system is split according to business functions. Each business function module is developed as an independent project and is called a service.  

Advantages and disadvantages of distributed architecture:

advantage:

• Reduce service coupling

• Conducive to service upgrade and expansion

shortcoming:

• The service calling relationship is complicated

Although the distributed architecture reduces service coupling, there are still many issues to consider when splitting services:

• How to define the granularity of service splitting?

• How to call between services?

• How to manage service calling relationships?

People need to develop a set of effective standards to constrain distributed architectures.

Microservice architectureFeatures:

• Single responsibility: Microservices are split into smaller granularities. Each service corresponds to a unique business capability and achieves a single responsibility.

• Autonomy: independent team, independent technology, independent data, independent deployment and delivery

• Service-oriented: services provide unified and standard interfaces, independent of language and technology

• Strong isolation: Service calls must be isolated, fault-tolerant, and downgraded to avoid cascading problems.

 

The above characteristics of microservices are actually setting a standard for distributed architecture, further reducing the coupling between services and providing service independence and flexibility. Achieve high cohesion and low coupling.

Therefore, it can be considered thatmicroservice is a well-architected distributed architecture solution .

But how to implement the plan? What technology stack to choose? Internet companies around the world are actively trying their own microservice implementation solutions.

Among them, the most eye-catching one in the Java field is the solution provided by Spring Cloud.

Summarize:

• What are the characteristics of monolithic architecture?
  • Simple and convenient, highly coupled, poor scalability, suitable for small projects. For example: student management system
• What are the characteristics of distributed architecture?
  • Loose coupling and good scalability, but the architecture is complex and difficult. Suitable for large-scale Internet projects, such as: JD.com, Taobao
• Microservices: a good distributed architecture solution
  • Advantages: smaller splitting granularity, more independent services, and lower coupling
  • Disadvantages: The architecture is very complex, making operation, maintenance, monitoring, and deployment more difficult.

4. Understand microservices - Comparison of microservice technologies

Microservices require a technical framework to implement. Internet companies around the world are actively trying their own microservice implementation technologies. The most well-known ones in China are SpringCloud and Alibaba's Dubbo.

Microservice technology comparison:

Business needs

5. Understand microservices-SpringCloud

• SpringCloud is currently the most widely used microservice framework in China.
• Official website address: https://spring.io/projects/spring-cloud
• SpringClaud integrates various microservice functional components and implements automatic assembly of these components based on SpringBoot, thus providing a good out-of-the-box experience:

6. Service Splitting-Case Demo

Things to note when splitting services

1. Single responsibility: different microservices, do not develop the same business repeatedly
2. Data independence: do not access the databases of other microservices
3. Service-oriented: Expose your business as an interface for other microservices to call

Service split example

Taking the microservice cloud-demo in the pre-course materials as an example, its structure is as follows:

cloud-demo: parent project, management dependencies

• order-service: order microservice, responsible for order-related business

• user-service: User microservice, responsible for user-related business

Require:

• Both the order microservice and the user microservice must have their own databases and are independent of each other.

• Both the order service and the user service expose Restful interfaces to the outside world.

• If the order service needs to query user information, it can only call the Restful interface of the user service and cannot query the user database.

Import Sql statement:

First, import the cloud-order.sql and cloud-user.sql provided in the pre-class materials into mysql:  

The initial data in the cloud-user table is as follows:

The initial data in the cloud-order table is as follows:

The cloud-order table holds the id field in the cloud-user table.​ 

The project structure is as follows:

Configure the JDK used by the project:

7. Service splitting-service remote invocation

In the order-service service, there is an interface for querying orders based on ID:

Query the order based on the id, and the return value is the Order object, as shown in the figure: (where user is null)

In user-service, there is an interface for querying users based on id:  

The query results are as shown in the figure:

Modify the order query business based on ID in order-service. It is required to query the user information based on the userId contained in the order while querying the order, and return it together.​  

Therefore, we need to initiate an http request to user-service in order-service and call the http://localhost:8081/user/{userId} interface.​ 

The general steps are as follows:

• Register an instance of RestTemplate to the Spring container
• Modify the queryOrderById method in the OrderService class in the order-service service to query the User based on the userId in the Order object.
• Fill the queried User into the Order object and return it together

First, we register the RestTemplate instance in the OrderApplication startup class in the order-service service: 

Modify the queryOrderById method in the OrderService class under the cn.itcast.order.service package in the order-service service:

8.Eureka-Provider and Consumer 

In a service call relationship, there are two different roles:

• Service provider: A service called by other microservices in a business. (Provide interfaces to other microservices)
• Service consumer: A service that calls other microservices in a business. (Call interfaces provided by other microservices)

However, the roles of service providers and service consumers are not absolute, but relative to the business. If service A calls service B, and service B calls service C, what is the role of service B?

• For the business of A calling B: A is a service consumer and B is a service provider
• For the business of B calling C: B is a service consumer and C is a service provider

Therefore, service B can be both a service provider and a service consumer.

Summarize:

Service calling relationship

• Service provider: Exposes interfaces for other microservices to call
• Service consumer: calls interfaces provided by other microservices
• The roles of provider and consumer are actually relative
• A service can be both a service provider and a service consumer at the same time

9.Eureka-eureka principle analysis

If our service provider user-service deploys multiple instances, as shown in the figure:

Let’s think about a few questions:

• When order-service initiates a remote call, how does it know the IP address and port of the user-service instance?

• There are multiple user-service instance addresses, how to choose when calling order-service?

• How does order-service know whether a user-service instance is still healthy or has gone down?

These problems need to be solved by using the registration center in Spring Cloud. The most well-known registration center is Eureka, whose structure is as follows:

Answer each of the previous questions.

Question 1: How does order-service know the user-service instance address?

The process of obtaining address information is as follows:

• After the user-service service instance is started, register your information with eureka-server (Eureka server). This is called service registration

• eureka-server saves the mapping relationship between service names and service instance address lists

• order-service pulls the instance address list based on the service name. This is called service discovery or service pull

Question 2: How does order-service select a specific instance from multiple user-service instances?

• order-service selects an instance address from the instance list using the load balancing algorithm

• Initiate a remote call to the instance address

Question 3: How does order-service know whether a certain user-service instance is still healthy or has been down?

• The user-service will initiate a request to the eureka-server at regular intervals (default 30 seconds) and report its own status, which is called a heartbeat.

• When no heartbeat is sent for a certain period of time, eureka-server will consider the microservice instance to be faulty and remove the instance from the service list.

• When order-service pulls the service, the faulty instance can be eliminated.

Note: A microservice can be both a service provider and a service consumer. Therefore, eureka uniformly encapsulates service registration, service discovery and other functions into the eureka-client.

10.Eureka-Build eureka service

So, our next hands-on steps include:

First build the registration center server: eureka-server, which must be an independent microservice 

Under the cloud-demo parent project, create a submodule:

Fill in the module information:

Then fill in the service information:  

Introduce the starter dependency provided by SpringCloud for eureka:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Write a startup class for the eureka-server service. Be sure to add an @EnableEurekaServer annotation to enable eureka's registration center function:

Write an application.yml file with the following content:

Start the microservice and visit in the browser:http://127.0.0.1:10086

You should see success when you see the following results:

11.Eureka-Service Registration

Next, we register user-service to eureka-server.

In the pom file of user-service, introduce the following eureka-client dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

In user-service, modify the application.yml file and add the service name and eureka address:

In order to demonstrate a scenario where a service has multiple instances, we add a SpringBoot startup configuration and start a user-service.

First, copy the original user-service startup configuration:

Then, in the pop-up window, fill in the information:

Now, two user-service startup configurations will appear in the SpringBoot window:

However, the first one is port 8081 and the second one is port 8082. Start two user-service instances:

View the eureka-server management page:

12.Eureka-Service Discovery

Next, we modify the logic of order-service: pull user-service information from eureka-server to realize service discovery.

As mentioned before, service discovery and service registration are all encapsulated in the eureka-client dependency, so this step is consistent with service registration.

In the pom file of order-service, introduce the following eureka-client dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Service discovery also needs to know the eureka address, so the second step is consistent with service registration, which is to configure eureka information:

In order-service, modify the application.yml file and add the service name and eureka address:

Finally, we are going to pull the instance list of user-service service from eureka-server and implement load balancing.

But we don’t need to do these actions, we just need to add some annotations.

In the OrderApplication of order-service, add a @LoadBalanced annotation to the RestTemplate bean:

Modify the queryOrderById method in the OrderService class under the cn.itcast.order.service package in the order-service service. Modify the accessed URL path and replace the IP and port with the service name:

Spring will automatically help us obtain the instance list from the eureka-server side based on the userservice service name, and then complete the load balancing.

13.Ribbon-Load Balancing Principle

The bottom layer of Spring Cloud actually uses a component called Ribbon to implement the load balancing function.

Then the request we sent is obviouslyhttp://userservice/user/1, why did it becomehttp://localhost:8081?  

Why can we access it just by entering the service name? You also need to obtain the IP and port before.

Apparently someone helped us obtain the IP and port of the service instance based on the service name. It is LoadBalancerInterceptor. This class will intercept the RestTemplate request, then obtain the service list from Eureka based on the service id, and then use the load balancing algorithm to obtain the real service address information and replace the service id.

We conduct source code tracking:

You can see that the intercept method here intercepts the user's HttpRequest request and then does several things:

- `request.getURI()`: Get the request uri, in this case http://user-service/user/8
- `originalUri.getHost()` : Get the host name of the uri path, which is actually the service id, `user-service`
- `this.loadBalancer.execute()`: Process the service id and user request.

`this.loadBalancer` here is of type `LoadBalancerClient`, let’s continue to follow.

Continue to follow the execute method:

The code is like this:

• getLoadBalancer(serviceId): Get the ILoadBalancer based on the service id, and the ILoadBalancer will take the service id to get the service list from eureka and save it.

• getServer(loadBalancer): Use the built-in load balancing algorithm to select one from the service list. In this example, you can see that the service of port 8082 has been obtained

After being released, I visited and tracked it again and found that I got 8081:

Sure enough, load balancing was achieved.

In the code just now, you can see that the service is obtained through a `getServer` method for load balancing:

Let’s continue to follow up:

Continuing to trace the source code chooseServer method, I found this piece of code:

Let’s see who this rule is:

The default value of the rule here is oneRoundRobinRule, see the introduction of the class:

Isn't this what polling means? At this point, we have a clear understanding of the entire load balancing process.

Summarize:

The bottom layer of SpringCloudRibbon uses an interceptor to intercept the request sent by RestTemplate and modify the address. Let’s sum it up with a picture:

The basic process is as follows:

• Intercept our RestTemplate request http://userservice/user/1
• RibbonLoadBalancerClient will get the service name from the request url, which is user-service
• DynamicServerListLoadBalancer pulls the service list from eureka based on user-service
• eureka returns the list, localhost:8081, localhost:8082
• IRule utilizes built-in load balancing rules and selects one from the list, such as localhost:8081
• RibbonLoadBalancerClient modifies the request address, replaces userservice with localhost:8081, gets http://localhost:8081/user/1, and initiates a real request

14.Ribbon-load balancing strategy 

Load balancing rules can be modified by defining IRule implementations in two ways:

• Code method: In the OrderApplication class in order-service, define a new IRule:

@Bean
public IRule randomRule(){
    return new RandomRule();
}

• Configuration file method: In the application.yml file of order-service, adding new configuration can also modify the rules:

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 

 Note that the default load balancing rules are generally used without modification.

15.Ribbon-Hungry Loading

Ribbon uses lazy loading by default, that is, the LoadBalanceClient will not be created until the first access, and the request time will be very long.

Hungry loading will be created when the project starts, reducing the time of the first visit. Enable hungry loading through the following configuration:

ribbon:
  eager-load:
    enabled: true
    clients: userservice

16.Nacos-Understanding and installing Nacos

[Dark Horse Programmer] - Complete Microservices - Nacos Installation Guide - CSDN Blog

17.Nacos-Quick Start 

Nacos is a component of SpringCloudAlibaba, and SpringCloudAlibaba also follows the service registration and service discovery specifications defined in SpringCloud. Therefore, there is not much difference between using Nacos and using Eureka for microservices.

The main differences are:

• Dependencies are different

• The service address is different

Introduce the SpringCloudAlibaba dependency in<dependencyManagement> in the pom file of the cloud-demo parent project:

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

 Then introduce the nacos-discovery dependency into the pom files in user-service and order-service:

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

Note: Don’t forget to comment out the eureka dependency.

Add the nacos address in application.yml of user-service and order-service:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

Note: Don’t forget to comment out the address of eureka

After restarting the microservice, log in to the nacos management page and you can see the microservice information:

18.Nacos-service multi-level storage model

Aservice can have multipleinstances, for example Our user-service can have:

• 127.0.0.1:8081

• 127.0.0.1:8082

• 127.0.0.1:8083

If these instances are distributed in different computer rooms across the country, for example:

• 127.0.0.1:8081, in Shanghai computer room

• 127.0.0.1:8082, in Shanghai computer room

• 127.0.0.1:8083, in Hangzhou computer room

Nacos divides the instances in the same computer room into a cluster.

In other words, user-service is a service. A service can contain multiple clusters, such as Hangzhou and Shanghai. Each cluster can have multiple instances, forming a hierarchical model, as shown in the figure:

When microservices access each other, they should try to access the same cluster instance because local access is faster. Only when the current cluster is unavailable will other clusters be accessed. For example:  

The order-service in the Hangzhou computer room should give priority to the user-service in the same computer room.​  

Modify the application.yml file of user-service and add cluster configuration:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

After restarting the two user-service instances, we can see the following results in the nacos console:

We copy a user-service startup configuration again and add properties:

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

 After starting UserApplication3, check the nacos console again:

19.Nacos-NacosRule load balancing

The default `ZoneAvoidanceRule` does not implement load balancing based on priority within the same cluster.

Therefore, Nacos provides an implementation of `NacosRule`, which can prioritize instances from the same cluster.

1) Configure cluster information for order-service

Modify the application.yml file of order-service and add cluster configuration:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

2) Modify load balancing rules

Modify the application.yml file of order-service and modify the load balancing rules:

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

20.Nacos-weight setting of service instance

In actual deployment, the following scenario will occur:

• The performance of server equipment varies. Some machines where instances are located have better performance, while others have worse performance. We hope that machines with good performance will bear more user requests.
• But by default, NacosRule is randomly selected within the same cluster and does not consider machine performance issues.
• Therefore, Nacos provides weight configuration to control access frequency. The greater the weight, the higher the access frequency.
• In the nacos console, find the instance list of user-service and click Edit to modify the weight:

In the pop-up editing window, modify the weight:

NOTE: If the weight is modified to 0, the instance will never be accessed

21.Nacos-Environmental Isolation

Nacos provides namespace to implement environment isolation function.

• There can be multiple namespaces in nacos
• There can be groups, services, etc. under the namespace.
• Different namespaces are isolated from each other. For example, services in different namespaces are not visible to each other.

 By default, all services, data, and groups are in the same namespace, named public:

We can click the new button on the page to add a namespace:

Then, fill out the form:

You will see a new namespace on the page:

Configuring namespace for microservices can only be achieved by modifying the configuration.

For example, modify the application.yml file of order-service:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

After restarting order-service, access the console and you can see the following results:

When accessing order-service at this time, because the namespace is different, userservice cannot be found and the console will report an error.

22.Nacos-Nacos and Eureka comparison

Nacos service instances are divided into two types:

• Temporary instance: If the instance is down for more than a certain period of time, it will be removed from the service list. This is the default type.

• Non-temporary instance: If the instance goes down, it will not be removed from the service list and can also be called a permanent instance.

Configure a service instance as a permanent instance:

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

 The overall structures of Nacos and Eureka are similar, including service registration, service pulling, and heartbeat waiting, but there are also some differences:

• What Nacos and eureka have in common

  • Both support service registration and service pulling.

  • All support service providers’ heartbeat method for health testing.

• The difference between Nacos and Eureka

  • Nacos supports the server to actively detect the provider status: temporary instances adopt heartbeat mode, and non-temporary instances adopt active detection mode.

  • Temporary instances with abnormal heartbeats will be removed, while non-temporary instances will not be removed.

  • Nacos supports message push mode for service list changes, and the service list is updated in a more timely manner.

  • The Nacos cluster uses AP mode by default. When there are non-temporary instances in the cluster, CP mode is used; Eureka uses AP mode.