This is the 25th day of my participation in Gwen Challenge.

Microservitization has become the mainstream trend of today, but different microservices generally have different network addresses, and external clients may need to call the interfaces of multiple services to complete a business requirement. If clients are allowed to communicate directly with each microservice, the following problems will occur:

  • The client requests different microservices multiple times, increasing the complexity of the client

  • Cross-domain requests exist and are complicated to process in certain scenarios

  • Authentication is complex and each service requires independent authentication

  • It is difficult to refactor, and as the project iterations, microservices may need to be reclassified. For example, you might combine multiple services into one or split a service into multiple services. Refactoring can be difficult to implement if the client communicates directly with the microservice

  • Some microservices may use firewall/browser-unfriendly protocols, making direct access difficult

The gateway introduced today will solve these problems. It can isolate services from the external network and play a certain protective role. At the same time, the LAN communication between services is faster. In addition, you can perform traffic limiting and permission verification on the gateway, enabling services to focus on their own services.

The advantages are as follows:

  1. Security, only the gateway system external exposure, micro services can be hidden in the Intranet, through the firewall protection
  2. Easy to monitor, monitoring data can be collected at the gateway and pushed to external systems for analysis
  3. Easy to authenticate, you can authenticate on the gateway and then forward the request to the back-end microservice instead of having to authenticate in each microservice
  4. Reduce the number of interactions between the client and each micro-service
  5. Easy unified authentication
  6. It can be used for LB

Introduced the benefits of gateway, next, we combat gateway. First, environment:

  • ubuntu16.04
  • docker18.04
  • K8s1. 13. + x
  • maven3.5.3
  • Java1.8 +
  • Springboot 2.1.6

In dependencies, let’s look at the main packages:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-kubernetes-core</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-kubernetes-discovery</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId>
</dependency>
Copy the code

After configuring the dependencies, let’s look at some of the initial bean configurations, which involve the configuration file bootstrap.yaml:

spring:
  cloud:
    kubernetes:
      discovery:
        all-namespaces: true
    gateway:
      discovery:
        locator:
          enabled: true
          lowerCaseServiceId: true
          
      routes:
      #001
      - id: cas-server
        uri: lb://cas-server-service
        order: -1
        predicates:
        - Path=/cas-server/**
        filters:
        - StripPrefix=1
Copy the code

We can see that the routers are a set, and each router needs to be configured. I did not configure a route for each service separately, but used the service discovery automatic route registration method. If the ribbon/cas-server/** is configured, the request will be forwarded to the LB :cas-server-service. StripPrefix indicates that the Path prefix is removed. If the parameter is 1, /ribbon is removed. That is, /cas-server/** is used to access our authentication service.

Next, we’ll focus on the main function:

@SpringBootApplication(scanBasePackages = { "com.gemantic" }) @EnableDiscoveryClient public class GatewayApp { public static void main(String[] args) { SpringApplication.run(GatewayApp.class, args); }}Copy the code

The annotation @enableDiscoveryClient is introduced to enable the LB of the service.

Note: in SpringBoot2. x, cross-domain problems need to be dealt with: in 1.x, we use the gateway and LB made by Zuul component of Netflix, and cross-domain problems can be solved by annotating @crossorigin on each micro-service without adding cross-domain processing. However, the default cross-domain interception in Spring Boot2. x was stated earlier and changed. Moreover, Spring Cloud Gateway, as the Gateway in the Spring Cloud ecosystem, aims to replace Netflix ZUUL, which is different from Spring Cloud Gateway. Therefore, attention should be paid to cross-domain problems. Cross-domain beans need to be added here, and each micro-service does not need annotations to solve cross-domain problems.

Core code:

@Bean public CorsWebFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.setAllowCredentials(true); Config. addAllowedOrigin("*"); // Allow cookies to cross domains config.addAllowedOrigin("*"); AddAllowedHeader ("*"); Origin config.addAllowedHeader("*"); Origin config.addAllowedHeader("*"); Config. AddAllowedMethod ("*"); //config.addExposedHeader("token"); config.setMaxAge(18000L); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsWebFilter(source); }Copy the code

In fact, Spring Cloud Gateway clearly distinguishes Router and Filter, and a big feature is a lot of built-in functions out of the box, such as: There are 10 built-in routers and so on, all of which can be used through SpringBoot configuration or hand-coded chain calls. So you can add their own use. Here to share actual source code: https://gitee.com/damon_one/spring-cloud-k8s.