Monolithic Architecture#

Develop all business functionality in a single project and deploy as a single package.

Advantages:

• Simple architecture
• Low deployment cost

Disadvantages:

• High coupling (maintenance and upgrade are difficult)

Distributed Architecture#

Split the system by business function, with each business function module developed as an independent project, called a service.

Advantages:

• Reduces service coupling
• Facilitates service upgrades and scalability

Disadvantages:

• The calling relationships between services become intricate

Although distributed architecture reduces service coupling, there are many questions to consider when partitioning services:

• How to define the granularity of service decomposition?
• How do services call each other?
• How to manage the calling relationships between services?

People need to establish a practical and effective set of standards to constrain distributed architectures.

Microservices#

Characteristics of a microservice architecture:

• Single Responsibility: Microservice decomposition is smaller; each service corresponds to a unique business capability, achieving single responsibility
• Autonomy: Teams, technologies, and data are independent, with independent deployment and delivery
• Service-Oriented: Services provide standardized interfaces, independent of language and technology
• Strong isolation: Service calls are isolated, fault-tolerant, and degradable to avoid cascading issues

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

Therefore, one can regard microservices as a well-architected distributed architecture solution.

SpringCloud#

SpringCloud is currently the most widely used microservice framework in China. Official website: https://spring.io/projects/spring-cloud。

SpringCloud integrates various microservice functionality components and, based on SpringBoot, provides auto-configuration for these components, delivering a good out-of-the-box experience.

Components include:

• Service registration and discovery: Eureka, Nacos, Consul
• Remote service invocation: OpenFeign, Dubbo
• Service tracing/monitoring: Zipkin, Sleuth
• Unified configuration management: SpringCloudConfig, Nacos
• Unified gateway routing: SpringCloudGateway, Zuul
• Traffic control, degradation, protection: Hystix, Sentinel

Inter-service Remote Calls#

Implemented by calling RestTemplate

1. Register a RestTemplate instance in the startup item

   1
   @Bean
   2
   public RestTemplate restTemplate() {
   3
       return new RestTemplate();
   4
   }

2. Calls within services

   1
   @Autowired
   2
   private RestTemplate restTemplate;
   3
   
   4
   public Order queryOrderById(Long orderId) {
   5
       // 1. Query the order
   6
       Order order = orderMapper.findById(orderId);
   7
       // 2. Remote query User
   8
       String url = "<http://localhost:8081/user/>" + order.getUserId();
   9
       User user = restTemplate.getForObject(url, User.class);
   10
       // 3. Put into order
   11
       order.setUser(user);
   12
       // 4. Return
   13
       return order;
   14
   }

Providers and Consumers#

In the service invocation relationship, there are two distinct roles:

Service Provider: In a business flow, the service that is called by other microservices. (Provides interfaces to other microservices)

Service Consumer: In a business flow, the service that calls other microservices. (Calls interfaces provided by other microservices)

Eureka Structure and Role#

The registry center is used to solve the problem of consumers calling providers that have multiple instances deployed.

• Question 1: How does order-service know the instance addresses of user-service?
  • After the user-service instance starts, it registers its information to the eureka-server (Eureka server). This is service registration.
  • The eureka-server maintains a mapping from service names to the list of instance addresses.
  • order-service pulls the instance address list by service name. This is service discovery or service pulling.
• Question 2: How does order-service pick a specific instance among multiple user-service instances?
  • order-service uses a load-balancing algorithm on the instance list to select an address.
  • It makes a remote call to that address.
• Question 3: How does order-service know whether a user-service instance is still healthy or down?
  • The user-service sends heartbeats to the eureka-server at regular intervals (default every 30 seconds) to report its status.
  • If heartbeats are not received for a certain period, the eureka-server marks the microservice instance as failed and removes it from the service list.
  • When order-service pulls the service list, faulty instances are excluded.

Building Eureka-Server#

1. Create the Eureka-Server service

Create a submodule under the parent project, a Maven project

1. Import Eureka dependency - server

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

1. Write the startup class

Add @EnableEurekaServer to enable Eureka registry center functionality

1
@SpringBootApplication
2
@EnableEurekaServer
3
public class EurekaApplication {
4
    public static void main(String[] args) {
5
        SpringApplication.run(EurekaApplication.class, args);
6
    }
7
}

1. Write the configuration file

1
server:
2
  port: 10086
3
spring:
4
  application:
5
    name: eureka-server
6
eureka:
7
  client:
8
    service-url:
9
      defaultZone: <http://127.0.0.1:10086/eureka>

1. Start the service

Access the configured Eureka service path

Service Registration#

1. Dependency import - client

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

1. Configuration file

1
spring:
2
  application:
3
    name: userservice
4
eureka:
5
  client:
6
    service-url:
7
      defaultZone: <http://127.0.0.1:10086/eureka>

1. Start multiple service instances

In SpringBoot, duplicate the startup configuration; configure -Dserver.port=8082 in VM options

Service Discovery#

As a consumer, order-service follows the same first two steps as the provider.

1. Service pulling and load balancing

Load balancing: simply add @LoadBalanced to the RestTemplate bean

1
@Bean
2
@LoadBalanced
3
public RestTemplate restTemplate(){
4
    return new RestTemplate();
5
}

Getting the service:

1
public Order queryOrderById(Long orderId) {
2
    // 1. Query the order
3
    Order order = orderMapper.findById(orderId);
4
    // 2. Remote query User
5
//        String url = "<http://localhost:8081/user/>" + order.getUserId();
6
    String url = "<http://userservice/user/>" + order.getUserId();
7
    User user = restTemplate.getForObject(url, User.class);
8
    // 3. Put into order
9
    order.setUser(user);
10
    // 4. Return
11
    return order;
12
}

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

Ribbon Load Balancing#

1
@Bean
2
public IRule randomRule(){
3
    return new RandomRule();
4
}

1
userservice: # Configure load balancing rule for a specific microservice
2
  ribbon:
3
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # Load balancing rule

1
ribbon:
2
  eager-load:
3
    enabled: true
4
    clients: userservice

Services registration to Nacos#

1
<dependency>
2
    <groupId>com.alibaba.cloud</groupId>
3
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
4
    <version>2.2.6.RELEASE</version>
5
    <type>pom</type>
6
    <scope>import</scope>
7
</dependency>

1
<dependency>
2
    <groupId>com.alibaba.cloud</groupId>
3
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
4
</dependency>

1
spring:
2
  cloud:
3
    nacos:
4
      server-addr: localhost:8848

Service Hierarchical Storage Model#

A service can have multiple instances. If these instances are distributed across different data centers nationwide, Nacos groups the instances within the same data center into a cluster.

When microservices communicate with each other, they should try to access the same cluster’s instances as much as possible because local access is faster. If the current cluster is unavailable, access other clusters.

• Configuration

Modify application.yml to add cluster configuration:

1
spring:
2
  cloud:
3
    nacos:
4
      server-addr: localhost:8848
5
      discovery:
6
        cluster-name: HZ # cluster name

Nacos provides a NacosRule implementation that can prefer selecting instances from the same cluster.

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

• Weight configuration

In actual deployments, you may encounter situations like:

Servers have different hardware performance; some machines are more capable, others less so. You want the higher-performing machines to handle more user requests.

But by default, NacosRule selects randomly within the same cluster and does not consider machine performance.

Therefore, Nacos provides weight configuration to control access frequency; higher weight means higher access frequency.

• Environment isolation

Nacos provides namespaces to achieve environment isolation.

• nacos can have multiple namespaces

• within a namespace there can be groups, services, etc.

• different namespaces are isolated from each other; services in different namespaces are not visible to each other

• Service instances

Nacos service instances come in two types:

• Ephemeral (temporary): If an instance goes down for a period, it will be removed from the service list; this is the default type.
• Non-ephemeral: If an instance goes down, it will not be removed from the service list and can be considered permanent.

Configure a service instance as non-ephemeral:

1
spring:
2
  cloud:
3
    nacos:
4
      discovery:
5
        ephemeral: false # set to non-ephemeral

Differences Between Nacos and Eureka#

Nacos and Eureka have similar overall structures—service registration, service pulling, and heartbeat waiting—but there are some differences:

• Common points
  • Both support service registration and service pulling
  • Both support heartbeat-based health checks for service providers
• Differences
  • Nacos supports server-side active monitoring of provider status: ephemeral instances use heartbeat mode; non-ephemeral instances use active checks
  • Ephemeral instances with abnormal heartbeats will be removed; non-ephemeral instances will not be removed
  • Nacos supports push-based notifications for service list changes, making updates more timely
  • Nacos clusters default to AP; when non-ephemeral instances exist, CP mode is used; Eureka uses AP mode

Pulling Configuration from Microservices#

Microservices pull configurations managed in Nacos and merge them with local application.yml configurations to complete startup.

But if application.yml has not yet been read, how to determine the Nacos address?

Therefore Spring introduces a new configuration file: bootstrap.yaml, which is read before application.yml.

1. Importing nacos-config dependency

1
<!--nacos配置管理依赖-->
2
<dependency>
3
    <groupId>com.alibaba.cloud</groupId>
4
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
5
</dependency>

1. Add bootstrap.yml

1
spring:
2
  application:
3
    name: userservice # service name
4
  profiles:
5
    active: dev # development environment; here it's dev
6
  cloud:
7
    nacos:
8
      server-addr: localhost:8848 # Nacos address
9
      config:
10
        file-extension: yaml # file extension

Here the Nacos address will be obtained from spring.cloud.nacos.server-addr, and then

${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension} is used as the file id to read configurations.

1. Reading Nacos configuration

1
@Value("${pattern.dateformat}")
2
private String dateformat;
3

4
@GetMapping("now")
5
public String now(){
6
    return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));
7
}

Configuration Hot Update#

After changing configurations in Nacos, microservices can apply the changes without restarting, i.e., configuration hot updating.

• Method 1: add @RefreshScope annotation

• Method 2

  Use @ConfigurationProperties instead of @Value annotations.

  1. In the user-service, add a class to read the pattern.dateformat property:

  1
  package cn.itcast.user.config;
  2
  
  3
  import lombok.Data;
  4
  import org.springframework.boot.context.properties.ConfigurationProperties;
  5
  import org.springframework.stereotype.Component;
  6
  
  7
  @Component
  8
  @Data
  9
  @ConfigurationProperties(prefix = "pattern")
  10
  public class PatternProperties {
  11
      private String dateformat;
  12
  }

  1. In UserController, use this class instead of @Value:

  1
  @Autowired
  2
  private PatternProperties patternProperties;
  3
  
  4
  @GetMapping("now")
  5
  public String now(){
  6
      return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
  7
  }

Configuration Sharing#

In fact, when the microservice starts, it will read multiple configuration files from Nacos, for example:

• [spring.application.name]-[spring.profiles.active].yaml, e.g., userservice-dev.yaml
• [spring.application.name].yaml, e.g., userservice.yaml

And [spring.application.name].yaml does not include an environment, so it can be shared across environments.

Configuration sharing priority:

When the same property appears in both Nacos and the service’s local configuration, the priority differs:

Nacos Clusters#

Proxy multiple Nacos servers via Nginx

Configure cluster.conf in Nacos’s conf, adding Nacos cluster addresses.

Feign Replaces RestTemplate#

1. Import dependencies

   1
   <dependency>
   2
       <groupId>org.springframework.cloud</groupId>
   3
       <artifactId>spring-cloud-starter-openfeign</artifactId>
   4
   </dependency>

2. Add annotation

   Add @EnableFeignClients in the startup class

3. Create Feign client

   In the service, create an interface:

   1
   @FeignClient("userservice")
   2
   public interface UserClient {
   3
       @GetMapping("/user/{id}")
   4
       User findById(@PathVariable("id") Long id);
   5
   }

   This client is mainly based on Spring MVC annotations to declare remote call details, such as:

   • Service name: userservice
   • HTTP method: GET
   • Path: /user/{id}
   • Parameter: Long id
   • Return type: User

   In this way, Feign can help us send HTTP requests without manually using RestTemplate.

4. Usage

   In the service class, call the method:

   1
   @Autowired
   2
   private UserClient userClient;
   3
   
   4
   public Order queryOrderById(Long orderId) {
   5
       // 1. Query the order
   6
       Order order = orderMapper.findById(orderId);
   7
       // 2. Remote query User
   8
       User user = userClient.findById(order.getUserId());
   9
       // 3. Put into order
   10
       order.setUser(user);
   11
       // 4. Return
   12
       return order;
   13
   }

Custom Configuration#

Feign supports a lot of custom configurations, as shown in the table below:

Generally, the defaults are sufficient; if you want to customize, simply create your own @Bean to override the default beans.

1
feign:
2
  client:
3
    config:
4
      userservice: # configuration for a specific microservice
5
        loggerLevel: FULL #  log level

1
feign:
2
  client:
3
    config:
4
      default: # default is global; if you specify a service name, it's for a single microservice
5
        loggerLevel: FULL #  log level

1
public class DefaultFeignConfiguration  {
2
    @Bean
3
    public Logger.Level feignLogLevel(){
4
        return Logger.Level.BASIC; // log level is BASIC
5
    }
6
}

1
@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class)

1
@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class)

Feign Usage Optimization#

Feign’s underlying HTTP requests rely on other frameworks. Their underlying client implementations include:

• URLConnection: default implementation, does not support connection pooling
• Apache HttpClient: supports connection pooling
• OKHttp: supports connection pooling

Thus, the main way to improve Feign performance is to use a connection pool instead of the default URLConnection.

Here we demonstrate using Apache HttpClient.

1. Import dependencies

In the order-service pom, include Apache HttpClient dependency:

1
<!--httpClient dependency -->
2
<dependency>
3
    <groupId>io.github.openfeign</groupId>
4
    <artifactId>feign-httpclient</artifactId>
5
</dependency>

1. Configure the connection pool

In the order-service application.yml, add configuration:

1
feign:
2
  client:
3
    config:
4
      default: # global default
5
        loggerLevel: BASIC # log level; BASIC is the basic request/response info
6
  httpclient:
7
    enabled: true # enable Feign's support for HttpClient
8
    max-connections: 200 # maximum connections
9
    max-connections-per-route: 50 # maximum connections per route

In short, Feign optimization:

1. Prefer BASIC log level when possible
2. Use HttpClient or OKHttp instead of URLConnection
   • Include feign-httpClient dependency
   • Enable HttpClient in the configuration and set pool parameters

Best Practice#

The Feign client and the service provider’s controller code are very similar. Here is a method to reduce repetitive coding:

Why a Gateway is Needed#

The Gateway is the gatekeeper of our services, the single entry point for all microservices.

Core capabilities of the gateway:

• Access control: The gateway, as the entry to microservices, should verify whether the user has permission to request; if not, intercept.
• Routing and load balancing: All requests must pass through the gateway, but the gateway does not process business logic. It forwards requests to a microservice based on certain rules; when there are multiple target services, load balancing is required.
• Rate limiting: When request traffic is high, the gateway releases requests at a rate that downstream microservices can handle, preventing service pressure.

In SpringCloud, there are two gateway implementations:

• gateway
• zuul

Zuul is servlet-based (blocking). SpringCloudGateway is built on WebFlux provided by Spring 5, a reactive programming implementation with better performance.

Quick Start#

1. Create a SpringBoot project gateway and include gateway dependencies

   1
   <!--网关-->
   2
   <dependency>
   3
       <groupId>org.springframework.cloud</groupId>
   4
       <artifactId>spring-cloud-starter-gateway</artifactId>
   5
   </dependency>
   6
   <!--nacos服务发现依赖-->
   7
   <dependency>
   8
       <groupId>com.alibaba.cloud</groupId>
   9
       <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
   10
   </dependency>

2. Write the startup class

   1
   @SpringBootApplication
   2
   public class GatewayApplication {
   3
   
   4
     public static void main(String[] args) {
   5
       SpringApplication.run(GatewayApplication.class, args);
   6
     }
   7
   }

3. Write basic configuration and routing rules

   Routing configuration includes:

   1. Route id: the unique identifier of the route
   2. Route target (uri): the route’s target address; http represents a fixed address, lb represents load balancing by service name
   3. Route predicates: the rules to determine routing
   4. Route filters: process requests or responses

   1
   server:
   2
     port: 10010 # gateway port
   3
   spring:
   4
     application:
   5
       name: gateway # service name
   6
     cloud:
   7
       nacos:
   8
         server-addr: localhost:8848 # nacos address
   9
       gateway:
   10
         routes: # gateway route configuration
   11
           - id: user-service # route id, unique
   12
             # uri: <http://127.0.0.1:8081> # route target address; http is fixed
   13
             uri: lb://userservice # route target address; lb indicates load balancing, followed by service name
   14
             predicates: # route predicates, i.e., conditions that determine routing
   15
               - Path=/user/** # path-based matching; matches any path that starts with /user/

4. Start the gateway service for testing

Restart the gateway; visiting http://localhost:10010/user/1 matches the /user/** rule and the request is forwarded to uri: http://userservice/user/1, yielding the result:

Predicate Factory#

What we write in the configuration as assertion rules are strings; these strings are read and processed by Predicate Factory to become route decision conditions.

For example, Path=/user/** matches by path, and this rule is handled by the class org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory. There are a dozen or so such assertion factories in SpringCloudGateway:

Filter Factory#

GatewayFilter is a filter provided by the gateway that can process incoming requests and responses from microservices

• Process requests or responses for routes, such as adding headers
• Filters defined under a route only apply to the current route’s requests

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
      - id: user-service
6
        uri: lb://userservice
7
        predicates:
8
        - Path=/user/**
9
        filters: # filters
10
        - AddRequestHeader=Truth, dreaife is freaking awesome! # add header

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
      - id: user-service
6
        uri: lb://userservice
7
        predicates:
8
        - Path=/user/**
9
      default-filters: # default filters
10
      - AddRequestHeader=Truth, dreaife is freaking awesome!

Global Filters#

1
public interface GlobalFilter {
2
    /**
3
     *  Process the current request; if necessary, pass the request to the next filter
4
     *
5
     * @param exchange the request context, where you can access Request, Response, etc.
6
     * @param chain used to delegate the request to the next filter
7
     * @return {@code Mono<Void>} indicates the end of this filter’s processing
8
     */
9
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
10
}

1
package cn.itcast.gateway.filters;
2

3
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
4
import org.springframework.cloud.gateway.filter.GlobalFilter;
5
import org.springframework.core.annotation.Order;
6
import org.springframework.http.HttpStatus;
7
import org.springframework.stereotype.Component;
8
import org.springframework.web.server.ServerWebExchange;
9
import reactor.core.publisher.Mono;
10

11
@Order(-1)
12
@Component
13
public class AuthorizeFilter implements GlobalFilter {
14
    @Override
15
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
16
        // 1. Get request parameters
17
        MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
18
        // 2. Get authorization parameter
19
        String auth = params.getFirst("authorization");
20
        // 3. Validate
21
        if ("admin".equals(auth)) {
22
            // Let through
23
            return chain.filter(exchange);
24
        }
25
        // 4. Block
26
        // 4.1. Deny access, set status code
27
        exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
28
        // 4.2. End handling
29
        return exchange.getResponse().setComplete();
30
    }
31
}

Cross-Origin (CORS) Issues#

Cross-origin means different domains; examples include:

• Different domains: http://www.taobao.com/ vs http://www.taobao.org/ vs http://www.jd.com/ vs http://miaosha.jd.com/
• Same domain, different ports: localhost<8080> vs localhost<8081>

Cross-origin issues occur when the browser blocks cross-origin AJAX requests initiated by the client.

Solution: CORS

In the gateway service’s application.yml, add the following configuration:

1
spring:
2
  cloud:
3
    gateway:
4
      globalcors: # Global cross-origin handling
5
        add-to-simple-url-handler-mapping: true # Solve options requests being blocked
6
        corsConfigurations:
7
          '[/**]':
8
            allowedOrigins: # Which websites are allowed to make cross-origin requests
9
              - "<http://localhost:8090>"
10
            allowedMethods: # Allowed cross-origin AJAX request methods
11
              - "GET"
12
              - "POST"
13
              - "DELETE"
14
              - "PUT"
15
              - "OPTIONS"
16
            allowedHeaders: "*" # Headers that are allowed in requests
17
            allowCredentials: true # Whether to allow credentials (cookies)
18
            maxAge: 360000 # This cross-origin check's validity period