Nepxion Discovery [Exploration] Enterprise Solutions for Micro Services

Posted by smnovick on Thu, 10 Oct 2019 05:59:27 +0200

Nepxion Discovery [Exploration] Enterprise Solutions for Micro Services

Nepxion Discovery is based on Spring Cloud Greenwich, Finchley and Hoxton. Users need to modify the Edgware version by themselves. The main functions of the guide include:

  • The gateway is the trigger point of the whole link gray level routing based on Header transmission. The configuration center configuration routing rule mapping is implemented by inserting Header information into the gateway filter, and the routing rules are transferred to the full link service. Routing methods mainly include version and region matching routing, version and region weight routing, machine IP address and port-based routing.
  • Full-link gray publishing based on rule subscription. The gray rules of configuration center configuration are mapped to the full-link services, and all services subscribe to a shared configuration. Publishing methods mainly include matching publishing of versions and regions, and weight publishing of versions and regions.

  • Full link service isolation. Including registration isolation, consumer isolation and provider-side service isolation, the example only provides Group-based isolation. In addition, not included in this article, but also include:

    • Registration Isolation: Registration Isolation of IP Addresses on Black/White Lists and Registration Isolation with Maximum Registration Limits
    • Consumer Isolation: Consumer Isolation of Black/White List IP Addresses
  • Full-link service current-limiting fuse degrading authority, Alibaba Sentinel integration, organic integration of gray-level routing, extension of LimitApp mechanism, through the dynamic Http Header mode to achieve a combination of protection mechanisms, including based on service name, gray-level group, gray-level version, gray-level region, machine address and port, support customization of arbitrary business parameters. The combination of numbers implements this function. Supporting native flow control rules, downgrade rules, authorization rules, system rules, hot spot parameter flow control rules
  • Full Link Gray Level Call Chain. Including Header mode and log mode, Header mode framework internal integration, log mode output through MDC (users need to integrate themselves)
  • Dual-live multi-room switching support in the same city. It is included in "Header-based Gray Routing for All Links"
  • Grayscale publishing of database. Built-in simple database gray publishing strategy, it is not within the scope of this article
  • Automated Test of Gray Routing and Publishing
  • Seamless Support Deployment for Docker Containerization and Kubernetes Platform

[Nacos] Alibaba middleware department develops a new generation of middleware which integrates service registry discovery center and configuration center. It is a service infrastructure for building modern application architecture centered on "service" (e.g. micro-service paradigm and cloud native paradigm), supporting the discovery, configuration and management of almost all mainstream types of "service". It is more agile and easy to build, deliver and manage micro-service platforms.

[Sentinel] Alibaba middleware department develops a new generation of flow guards to protect the stability of distributed systems from multiple dimensions such as flow control, fuse downgrade, system load protection and so on. It undertakes the core scenarios of Alibaba's "Double Eleventh Congress" in recent 10 years, such as second killing (i.e., burst flow control within the system capacity can be tolerated), message peak shaving and valley filling, cluster flow control, real-time fusing downstream unavailable applications, etc.

[Spring Cloud Alibaba] The Spring Cloud Enhancement Suite developed by Alibaba Middleware is dedicated to providing one-stop solutions for micro-service development. This project includes the necessary components for developing distributed application microservices, which can be easily used by developers through Spring Cloud programming model to develop distributed application services. Relying on Spring Cloud Alibaba, Spring Cloud application can be connected to Ali micro-service solution by adding some annotations and a few configurations. Distributed application system can be built quickly through Ali middleware.

The example uses Nacos as the service registry and configuration center (users can switch to other service registries and configuration centers), integrates Spring Cloud Alibaba, calls services of two versions or regions through Gateway and Zuul, simulates the function of gateway gray routing and service gray weight.

If users need more powerful functions, please refer to Source Home Page This is the case. There are many rules and strategies. Users are asked to choose the best way to fit their business scenarios.

Catalog

Please contact me

Wechat, Public Number and Documentation

Related links

Source Home Page

Source Home Page

Guide Home Page

Guide Home Page

Document Home Page

Document Home Page

Relevant diagrams

Deployment architecture topology

Service Governance Architecture Diagram

Gray-scale pattern discrimination map

Environmental Construction

Start up service

  • In IDE, four application services and two gateway services are launched as follows:
Class name Microservices Service Port Edition region
DiscoveryGuideServiceA1.java A1 3001 1.0 dev
DiscoveryGuideServiceA2.java A2 3002 1.1 qa
DiscoveryGuideServiceB1.java B1 4001 1.0 qa
DiscoveryGuideServiceB2.java B2 4002 1.1 dev
DiscoveryGuideGateway.java Gateway 5001 1.0 nothing
DiscoveryGuideZuul.java Zuul 5002 1.0 nothing

Note: Start up in no sequence

Environmental validation

  • Import Postman's test script, Script address
  • Execute "Nepxion" - > "Discovery Guide Gateway Interface" - > "Gateway Gateway Call Example" under the directory structure in Postman with the address of "Nepxion" - > "Discovery Guide Gateway Call Example" http://localhost:5001/discovery-guide-service-a/invoke/gateway The relevant Header values are preset for developers to modify. The results of the call through the Spring Cloud Gateway Gateway Gateway are tested in the following format:
gateway -> discovery-guide-service-a[192.168.0.107:3001][V=1.0][R=dev][G=discovery-guide-group] 
-> discovery-guide-service-b[192.168.0.107:4001][V=1.0][R=qa][G=discovery-guide-group]
  • Execute the "Nepxion" - > "Discovery Guide Gateway Interface" - > "Zuul Gateway Call Example" under the directory structure in Postman with the address of "Nepxion" - > "Discovery Guide Gateway Interface" - > "Zuul Gateway Call Example" http://localhost:5002/discovery-guide-service-a/invoke/zuul The relevant Header values are preset for developers to modify. The results of the test call through Zuul Gateway are in the following format:
zuul -> discovery-guide-service-a[192.168.0.107:3001][V=1.0][R=dev][G=discovery-guide-group] 
-> discovery-guide-service-b[192.168.0.107:4001][V=1.0][R=qa][G=discovery-guide-group]
  • The above steps are executed each time the rule policy is changed, and the results are verified to be the same as the expected values of the rule policy.

Gray Routing Strategy of Gateway Based on Header Transfer

Gray Routing Architecture

Multi-version Gray Routing Architecture

Multi-area Gray Routing Architecture

Gray Routing Architecture Diagram of Multi-IP and Port

Configuration Gateway Gray Routing Strategy

In Nacos Configuration Center, Increase Gateway Gray Routing Strategy

Version Matching Gray Routing Strategy

Increase the gray level strategy of Spring Cloud Gateway based on version matching routing. Group is discovery-guide-group, Data Id is discovery-guide-gateway. The strategy is as follows. All calls initiated from Spring Cloud Gateway are implemented with version 1.0:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy>
        <version>1.0</version>
    </strategy>
</rule>

The version of each service invocation can be specified by itself, as shown in Article 2 below. When all services are selected in the same version, it can be simplified to the first one below.

1. <version>1.0</version>
2. <version>{"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}</version>

If the above expression does not satisfy the requirement, wildcards can also be used (refer to Spring AntPath Matcher for detailed usage)

*- Represents that the invocation scope is all versions of all services
 1. * - Represents all versions of the invocation scope beginning with 1 for all services

perhaps

"discovery-guide-service-b":"1.*;1.2.?"

Represents that the version invocation scope of the discovery-guide-service-b service is all versions beginning with 1, or all versions beginning with 1.2 (the end must be a character)

Version Weight Gray Routing Strategy

Increase Spring Cloud Gateway's gray level strategy based on version weight routing. Group is discovery-guide-group, Data Id is discovery-guide-gateway. The strategy is as follows: 90% of the 1.0 version traffic calls initiated from Spring Cloud Gateway and 10% of the 1.1 traffic calls are realized.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy>
        <version-weight>1.0=90;1.1=10</version-weight>
    </strategy>
</rule>

The version weight of each service invocation can be specified by itself, as shown in Article 2 below. When all services have the same version weight, it can be simplified to the first one below.

1. <version-weight>1.0=90;1.1=10</version-weight>
2. <version-weight>{"discovery-guide-service-a":"1.0=90;1.1=10", "discovery-guide-service-b":"1.0=90;1.1=10"}</version-weight>

Region Matching Gray Routing Strategy

Increase Zuul's gray-scale strategy based on region matching routing. Group is discovery-guide-group, Data Id is discovery-guide-zuul. The strategy is as follows. All calls initiated from Zuul take the area as dev:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy>
        <region>dev</region>
    </strategy>
</rule>

Each area of service invocation can be specified by itself, as shown in Article 2 below. When all services are selected in the same area, it can be simplified to the first one below.

1. <region>dev</region>
2. <region>{"discovery-guide-service-a":"dev", "discovery-guide-service-b":"dev"}</region>

If the above expression does not satisfy the requirement, wildcards can also be used (refer to Spring AntPath Matcher for detailed usage)

*- Represents all areas of the invocation scope for all services
 d* - Represents all areas of the invocation scope beginning with d for all services

perhaps

"discovery-guide-service-b":"d*;q?"

Represents that the area invocation scope of the discovery-guide-service-b service is all the areas at the beginning of d, or all the areas at the beginning of q (the end must be a character)

Regional Weight Gray Routing Strategy

Increase Zuul's gray level strategy based on region weight routing. Group is discovery-guide-group, Data Id is discovery-guide-zuul. The strategy is as follows: 85% of the dev area traffic calls initiated from Zuul and 15% of the qa area traffic calls are realized.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy>
        <region-weight>dev=85;qa=15</region-weight>
    </strategy>
</rule>

The area weight of each service invocation can be specified by itself, as shown in Article 2 below. When all services have the same regional weight, it can be simplified to the first one below.

1. <region-weight>dev=85;qa=15</region-weight>
2. <region-weight>{"discovery-guide-service-a":"dev=85;qa=15", "discovery-guide-service-b":"dev=85;qa=15"}</region-weight>

Setting gray routing strategy of gateway through other ways

In addition to the above gray-scale routing rules issued through the configuration center, there are three ways as follows:

Input Gray Routing Strategy through Front End

The gray-level routing strategy is introduced through the front-end (Postman) mode to replace the configuration center mode and transfer the full-link routing strategy. Note: When both the configuration center and the interface are configured, interface import takes precedence.

  • For version matching strategy, the Header format is as follows:
1. n-d-version=1.0
2. n-d-version={"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}
  • For version weight strategy, the Header format is as follows:
1. n-d-version-weight=1.0=90;1.1=10
2. n-d-version-weight={"discovery-guide-service-a":"1.0=90;1.1=10", "discovery-guide-service-b":"1.0=90;1.1=10"}
  • For the region matching strategy, the Header format is as follows:
1. n-d-region=qa
2. n-d-region={"discovery-guide-service-a":"qa", "discovery-guide-service-b":"qa"}
  • For the regional weight strategy, the Header format is as follows:
1. n-d-region-weight=dev=99;qa=1
2. n-d-region-weight={"discovery-guide-service-a":"dev=99;qa=1", "discovery-guide-service-b":"dev=99;qa=1"}
  • Machine IP address and port policy:
n-d-address={"discovery-guide-service-a":"127.0.0.1:3001", "discovery-guide-service-b":"127.0.0.1:4002"}

When an external value Header is passed, the gateway also sets and passes the Header with the same name, which Header needs to be passed to the back service. It needs to be controlled by the following switches:

# When an external value Header is passed, the gateway also sets and passes the Header with the same name, which Header needs to be passed to the back service. If the following switch is true, the gateway setting is preferred, otherwise the external transfer value is preferred. Default is true
spring.application.strategy.gateway.header.priority=false
# When the gateway is set as priority, the gateway does not configure the Header, while the external configuration of the Header still ignores the external Header. Default is true
spring.application.strategy.gateway.original.header.ignored=true

# When an external value Header is passed, the gateway also sets and passes the Header with the same name, which Header needs to be passed to the back service. If the following switch is true, the gateway setting is preferred, otherwise the external transfer value is preferred. Default is true
spring.application.strategy.zuul.header.priority=false
# When the gateway is set as priority, the gateway does not configure the Header, while the external configuration of the Header still ignores the external Header. Default is true
spring.application.strategy.zuul.original.header.ignored=true

Customize Gray Routing Strategy in Gateway Filter by Business Parameters

The Http Header is transmitted through the gateway filter to transmit the whole link gray routing strategy. The following code applies only to Zuul and Spring Cloud Gateway gateways, which are not required for Service microservices.

  • Customized way of mapping built-in policy resolution to filters

Add Spring Cloud Gateway's parsing strategy, Group as discovery-guide-group, Data Id as discovery-guide-gateway, or Spring Cloud Gateway's parsing strategy, Group as discovery-guide-group, Data Id as discovery-guide-zuul. The content of the strategy is shown in the following XML content, which expresses the functional logic:

1. Value a=1 and b=2 in the Http Header with external calls
   In the < condition > node header="a=1;b=2" corresponding version-id="version-route1", find the following
   The < route > node id="version-route1" type="version" of the item, then the route is:
   {"discovery-guide-service-a":"1.1", "discovery-guide-service-b":"1.1"}

2. Value a=1 in the Http Header with external calls
   In the < condition > node header="a=1" corresponds to version-id="version-route2". Find the following
   In <route>, if the id="version-route2" type="version", then the route is:
   {"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.1"}

3. When the values in the Http Header with the external call do not hit, find the above
   Global default routing in <strategy> nodes, then the routing is:
   {"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}

4. A total of 5 kinds of policy parsing are supported, which can be used alone or in multiple overlays.
   1) version routing
   2) region Area Routing
   3) address machine address routing
   4) version-weight version weight routing
   5) region-weight region weight routing
<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <!-- Be based on Http Header Delivery Policy Routing, Global Default Routing -->
    <strategy>
        <version>{"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}</version>
    </strategy>

    <!-- Be based on Http Header Delivery of policy routing, customized control, and binding with business parameters. If it does not hit, perform the above global default routing -->
    <strategy-customization>
        <conditions>
            <condition id="condition1" header="a=1" version-id="version-route2"/>
            <condition id="condition2" header="a=1;b=2" version-id="version-route1"/>
        </conditions>

        <routes>
            <route id="version-route1" type="version">{"discovery-guide-service-a":"1.1", "discovery-guide-service-b":"1.1"}</route>
            <route id="version-route2" type="version">{"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.1"}</route>
        </routes>
    </strategy-customization>
</rule>

  • Customization of user coverage filters

Inherit Gateway StrategyRouteFilter or Zuul StrategyRouteFilter, override one or more of the following methods, and override the built-in filter classes in the framework by @Bean

protected String getRouteVersion();

protected String getRouteRegion();

protected String getRouteAddress();

Example of Gateway Strategy RouteFilter

Select different routing paths according to different headers in the code

// It is suitable for A/B Testing or deciding gray routing path according to some business parameters. A/B paths can be configured separately in conjunction with the configuration center, which can be dynamically changed and notified.
// When the user in Header is Zhang San, one routing path is executed; for Li Si, another routing path is executed.
public class MyGatewayStrategyRouteFilter extends DefaultGatewayStrategyRouteFilter {
    private static final String DEFAULT_A_ROUTE_VERSION = "{\"discovery-guide-service-a\":\"1.0\", \"discovery-guide-service-b\":\"1.1\"}";
    private static final String DEFAULT_B_ROUTE_VERSION = "{\"discovery-guide-service-a\":\"1.1\", \"discovery-guide-service-b\":\"1.0\"}";

    @Value("${a.route.version:" + DEFAULT_A_ROUTE_VERSION + "}")
    private String aRouteVersion;

    @Value("${b.route.version:" + DEFAULT_B_ROUTE_VERSION + "}")
    private String bRouteVersion;

    @Override
    public String getRouteVersion() {
        String user = strategyContextHolder.getHeader("user");

        if (StringUtils.equals(user, "zhangsan")) {
            return aRouteVersion;
        } else if (StringUtils.equals(user, "lisi")) {
            return bRouteVersion;
        }

        return super.getRouteVersion();
    }
}

In the configuration class, the @Bean method is used to create filter classes, covering the built-in filter classes in the framework.

@Bean
public GatewayStrategyRouteFilter gatewayStrategyRouteFilter() {
    return new MyGatewayStrategyRouteFilter();
}

An example of Zuul Strategy RouteFilter

Select different routing paths according to different headers in the code

// It is suitable for A/B Testing or deciding gray routing path according to some business parameters. A/B paths can be configured separately in conjunction with the configuration center, which can be dynamically changed and notified.
// When the user in Header is Zhang San, one routing path is executed; for Li Si, another routing path is executed.
public class MyZuulStrategyRouteFilter extends DefaultZuulStrategyRouteFilter {
    private static final String DEFAULT_A_ROUTE_VERSION = "{\"discovery-guide-service-a\":\"1.0\", \"discovery-guide-service-b\":\"1.1\"}";
    private static final String DEFAULT_B_ROUTE_VERSION = "{\"discovery-guide-service-a\":\"1.1\", \"discovery-guide-service-b\":\"1.0\"}";

    @Value("${a.route.version:" + DEFAULT_A_ROUTE_VERSION + "}")
    private String aRouteVersion;

    @Value("${b.route.version:" + DEFAULT_B_ROUTE_VERSION + "}")
    private String bRouteVersion;

    @Override
    public String getRouteVersion() {
        String user = strategyContextHolder.getHeader("user");

        if (StringUtils.equals(user, "zhangsan")) {
            return aRouteVersion;
        } else if (StringUtils.equals(user, "lisi")) {
            return bRouteVersion;
        }

        return super.getRouteVersion();
    }
}

In the configuration class, the @Bean method is used to create filter classes, covering the built-in filter classes in the framework.

@Bean
public ZuulStrategyRouteFilter zuulStrategyRouteFilter() {
    return new MyZuulStrategyRouteFilter();
}

Customizing Gray Routing Policy in Policy Class by Business Parameters

The gray-level routing strategy is defined by policy. The following code applies not only to Zuul and Spring Cloud Gateway gateways, but also to Service micro-services, which must be added to gateways and services throughout the link.

// The combination strategy, version routing strategy + area routing strategy + IP and port routing strategy + custom strategy are implemented.
public class MyDiscoveryEnabledStrategy extends DefaultDiscoveryEnabledStrategy {
    private static final Logger LOG = LoggerFactory.getLogger(MyDiscoveryEnabledStrategy.class);

    // Policy the Header parameters (e.g. mobile) passed from Rest calls
    @Override
    public boolean apply(Server server) {
        String mobile = strategyContextHolder.getHeader("mobile");
        String serviceId = pluginAdapter.getServerServiceId(server);
        String version = pluginAdapter.getServerVersion(server);
        String region = pluginAdapter.getServerRegion(server);

        LOG.info("Load balancing user customization triggers: mobile={}, serviceId={}, version={}, region={}", mobile, serviceId, version, region);

        if (StringUtils.isNotEmpty(mobile)) {
            // Mobile number starts with mobile 138 and routes to version 1.0 of the service.
            if (mobile.startsWith("138") && StringUtils.equals(version, "1.0")) {
                return true;
                // Mobile numbers start with Unicom 133 and are routed to version 2.0 services.
            } else if (mobile.startsWith("133") && StringUtils.equals(version, "1.1")) {
                return true;
            } else {
                // Otherwise, refuse the request directly
                return false;
            }
        }

        return true;
    }
}

Creating Policy Classes in the Configuration Class @Bean Way

@Bean
public DiscoveryEnabledStrategy discoveryEnabledStrategy() {
    return new MyDiscoveryEnabledStrategy();
}

In the gateway and service, it supports the self-defined gray-level routing strategy based on Rest Header transfer. In addition, the service also supports the self-defined gray-level routing strategy based on Rpc method parameter transfer, which includes interface name, method name, parameter name or parameter value and other forms. The following example shows that a custom composite gray-level routing strategy based on Rest Header transfer and Rpc method parameter transfer is enabled in the service at the same time.

// The combination strategy, version routing strategy + area routing strategy + IP and port routing strategy + custom strategy are implemented.
public class MyDiscoveryEnabledStrategy implements DiscoveryEnabledStrategy {
    private static final Logger LOG = LoggerFactory.getLogger(MyDiscoveryEnabledStrategy.class);

    @Autowired
    private PluginAdapter pluginAdapter;

    @Autowired
    private ServiceStrategyContextHolder serviceStrategyContextHolder;

    @Override
    public boolean apply(Server server) {
        boolean enabled = applyFromHeader(server);
        if (!enabled) {
            return false;
        }

        return applyFromMethod(server);
    }

    // Select the service instance to execute the call request based on the Header parameter (e.g. mobile) passed from the Rest call
    private boolean applyFromHeader(Server server) {
        String mobile = serviceStrategyContextHolder.getHeader("mobile");
        String serviceId = pluginAdapter.getServerServiceId(server);
        String version = pluginAdapter.getServerVersion(server);
        String region = pluginAdapter.getServerRegion(server);

        LOG.info("Load balancing user customization triggers: mobile={}, serviceId={}, version={}, region={}", mobile, serviceId, version, region);

        if (StringUtils.isNotEmpty(mobile)) {
            // Mobile number starts with mobile 138 and routes to version 1.0 of the service.
            if (mobile.startsWith("138") && StringUtils.equals(version, "1.0")) {
                return true;
                // Mobile numbers start with Unicom 133 and are routed to version 2.0 services.
            } else if (mobile.startsWith("133") && StringUtils.equals(version, "1.1")) {
                return true;
            } else {
                // Otherwise, refuse the request directly
                return false;
            }
        }

        return true;
    }

    // Select service instances to execute invocation requests based on method parameters (such as interface name, method name, parameter name or parameter value, etc.) passed from RPC calls
    // This example only works on discovery-guide-service-a services
    @SuppressWarnings("unchecked")
    private boolean applyFromMethod(Server server) {
        Map<String, Object> attributes = serviceStrategyContextHolder.getRpcAttributes();
        String serviceId = pluginAdapter.getServerServiceId(server);
        String version = pluginAdapter.getServerVersion(server);
        String region = pluginAdapter.getServerRegion(server);

        LOG.info("Load balancing user customization triggers: attributes={}, serviceId={}, version={}, region={}", attributes, serviceId, version, region);

        if (attributes.containsKey(ServiceStrategyConstant.PARAMETER_MAP)) {
            Map<String, Object> parameterMap = (Map<String, Object>) attributes.get(ServiceStrategyConstant.PARAMETER_MAP);
            String value = parameterMap.get("value").toString();
            if (StringUtils.isNotEmpty(value)) {
                // The input value contains dev, which is routed to the service in the dev area
                if (value.contains("dev") && StringUtils.equals(region, "dev")) {
                    return true;
                    // The input value contains qa and is routed to the service in the qa area
                } else if (value.contains("qa") && StringUtils.equals(region, "qa")) {
                    return true;
                } else {
                    // Otherwise, directly through the request
                    return true;
                }
            }
        }

        return true;
    }
}

This function needs to be turned on by the following switches

# When starting and closing the routing policy, the call of RPC mode is intercepted. Default is false
spring.application.strategy.rpc.intercept.enabled=true

Configuration of Front-end Gray Level-Gateway Gray Level Routing Combination Strategy

When there are multiple versions of the front-end (e.g. APP) and the back-end micro-services, the "front-end gray-level-gateway gray-level routing combination strategy" can be implemented.

For example, there are 1.0 and 2.0 versions in front-end, 1.0 and 2.0 versions in micro-service. Because of version incompatibility (front-end version 1.0 can only call 1.0 version of micro-service, front-end version 2.0 can only call 2.0 version of micro-service), when front-end calls gateway, it can pass its version number to gateway through Header, gateway can route corresponding version according to front-end version number. Ben's Micro Services

This scenario can be solved by the scheme of "Customizing Gray Routing Strategy in Gateway Filter by Business Parameters". The following is the solution:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy-customization>
        <conditions>
            <condition id="condition1" header="app-version=1.0" version-id="version-route1"/>
            <condition id="condition2" header="app-version=2.0" version-id="version-route2"/>
        </conditions>

        <routes>
            <route id="version-route1" type="version">{"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}</route>
            <route id="version-route2" type="version">{"discovery-guide-service-a":"1.1", "discovery-guide-service-b":"1.1"}</route>
        </routes>
    </strategy-customization>
</rule>

The above configuration simulates two independent and undisturbed call paths in the whole link:

1. APP v1.0 -> gateway -> A service v1.0 -> B service v1.0
2. APP v1.1 -> gateway -> A service v1.1 -> B service v1.1

Full Link Gray Level Publishing Rules Based on Subscription Mode

In Nacos Configuration Center, Added Full Link Gray Level Publishing Rules
Note: This function and the gateway gray-level routing and gray-level weight function will overlap. In order not to affect the demonstration effect, please clear the gateway gray-level routing strategy first.

Configuration of Full Link Gray Matching Rules

Gray Level Rules for Version Matching

Increase the gray level rule of version matching, Group is discovery-guide-group, Data Id is discovery-guide-group (global publication, both are group names). The rule is as follows: 1.0 version of a service can only access version 1.0 of b service, 1.1 version of a service can only access version 1.1 of b service:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <version>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-version-value="1.0" provider-version-value="1.0"/>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-version-value="1.1" provider-version-value="1.1"/>
        </version>
    </discovery>
</rule>

Region matching gray rule

Increase the gray level rule of region matching, Group is discovery-guide-group, Data Id is discovery-guide-group (global publication, both are group names). The rule is as follows: A service in dev area can only access b service in dev area, while a service in qa area can only access b service in qa area:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <region>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-region-value="dev" provider-region-value="dev"/>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-region-value="qa" provider-region-value="qa"/>
        </region>
    </discovery>
</rule>

Configuration of Gray Level Weighting Rules for Full Link

Global version weight gray rule

The grey scale rules that increase the weight of global version are: Group is discovery-guide-group, Data Id is discovery-guide-group (global publication, both of them are group names). The rules are as follows: 90% traffic is provided for services with version 1.0 and 10% traffic is provided for services with version 1.1:

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <weight>
            <version provider-weight-value="1.0=90;1.1=10"/>
        </weight>
    </discovery>
</rule>

Local version weight gray rule

The grey scale rules of increasing local version weight are found-guide-group for Group, discovery-guide-group for Data Id (global release, both of them are group names). The rules are as follows: 90% traffic is provided in version 1.0 of a service, 10% traffic is provided in version 1.1; 20% traffic is provided in version 1.0 of b service and 80% traffic is provided in version 1.1 of b service.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <weight>
            <service provider-service-name="discovery-guide-service-a" provider-weight-value="1.0=90;1.1=10" type="version"/>
            <service provider-service-name="discovery-guide-service-b" provider-weight-value="1.0=20;1.1=80" type="version"/>
        </weight>
    </discovery>
</rule>

Global Region Weight Gray Rule

The grey rules of increasing the weight of global region are: Group is discovery-guide-group, Data Id is discovery-guide-group (global publication, both are group names). The rules are as follows: the implementation area provides 90% of the traffic for dev services, and the area provides 10% of the traffic for qa services.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <weight>
            <region provider-weight-value="dev=90;qa=10"/>
        </weight>
    </discovery>
</rule>

Local Region Weight Gray Rule

The grey rules of increasing the weight of local area are: Group is discovery-guide-group, Data Id is discovery-guide-group (global publication, both are group names). The rules are as follows: a service dev area provides 90% of the traffic, qa area provides 10% of the traffic; b service dev area provides 20% of the traffic, qa area provides 80% of the traffic.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <weight>
            <service provider-service-name="discovery-guide-service-a" provider-weight-value="dev=90;qa=10" type="region"/>
            <service provider-service-name="discovery-guide-service-b" provider-weight-value="dev=20;qa=80" type="region"/>
        </weight>
    </discovery>
</rule>

Note: Local weight priority is higher than global weight, version weight priority is higher than regional weight.

Please perform the Postman operation and carefully observe the probability that the service will be invoked with random weights

Configuration of Gray Level Weight of Full Link-Gray Version Combination Rule

Increase the combination of gray rules, Group for discovery-guide-group, Data Id for discovery-guide-group (global publication, both are group names), the rules are as follows, to achieve functions:

  • a service version 1.0 provides 90% of the traffic to the gateway, and version 1.1 provides 10% of the traffic to the gateway.
  • Version 1.0 of a service can only access version 1.0 of b service, version 1.1 can only access version 1.1 of b service

The significance of this function is that the gateway calls services at random weights, while the service link calls services according to version matching.

<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <discovery>
        <version>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-version-value="1.0" provider-version-value="1.0"/>
            <service consumer-service-name="discovery-guide-service-a" provider-service-name="discovery-guide-service-b" consumer-version-value="1.1" provider-version-value="1.1"/>
        </version>

        <weight>
            <service consumer-service-name="discovery-guide-gateway" provider-service-name="discovery-guide-service-a" provider-weight-value="1.0=90;1.1=10" type="version"/>
            <service consumer-service-name="discovery-guide-zuul" provider-service-name="discovery-guide-service-a" provider-weight-value="1.0=90;1.1=10" type="version"/>
        </weight>
    </discovery>
</rule>

Graphical Interface Verification

  • download Source Home Page Project and import IDE
  • Discovery-spring cloud-example-console/Console Application under Start Source Engineering
  • discovery-console-desktop/ConsoleLauncher under Start Source Engineering
  • Log in through admin/admin and click on the "Show Service Topology" button to display the following interface

  • Before joining the above rules, select the gateway node, right-click on "execute gray-level routing", add "discovery-guide-service-a" and "discovery-guide-service-b" in turn in the bullet exit routing interface, and click the "execute routing" button, which will present the following interface

  • After adding the above rules, in the routing interface, click the "Execute Routing" button again, which will present the following interface

Full Link Service Isolation

Groups in metadata represent system ID or logical grouping in a sense. Grouping strategy means that only services in the same system can be invoked.

Registration Service Isolation

The strategy based on Group Blacklist/Whitelist, that is, the group where the current service is located, is not allowed to be registered on Group's Blacklist or Whitelist. Only need to open the following configuration in gateway or server:

# Start and close registered service isolation (based on Group Black/White List policy). Default is false
spring.application.strategy.register.isolation.enabled=true

Black/white lists are configured as follows

spring.application.strategy.register.isolation.group.blacklist=
spring.application.strategy.register.isolation.group.whitelist=

Consumer Service Isolation

Group s must be the same based on whether they share the same strategy, that is, the list of providers that consumers get. Only need to open the following configuration in gateway or server:

# Start and close service isolation on the consumer side (based on the same strategy as Group). Default is false
spring.application.strategy.consumer.isolation.enabled=true

By modifying the Group name of discovery-guide-service-b to another name and executing the Postman call, it will be found that no instance of discovery-guide-service-b can be obtained from discovery-guide-service-a. This means isolation on the discovery-guide-service-a consumer side

Provider-side service isolation

Based on the same strategy of Group, that is, the service side is invoked by the consumer side, the two groups must be the same. Otherwise, the heterogeneous system can pass n-d-service-group value through Header mode to match. Just turn on the following configuration on the server side (not the gateway):

# Start and close service isolation on the provider side (based on the same strategy as Group). Default is false
spring.application.strategy.provider.isolation.enabled=true

# When using gray-level routing strategy, we need to specify the scanning path of RestController class. This configuration acts on two tasks: call interception in RPC mode and service isolation in consumer side.
spring.application.strategy.scan.packages=com.nepxion.discovery.guide.service.feign

Call in Postman, execute http://localhost:4001/invoke/abc To invoke the discovery-guide-service-b service, the following exception will occur. It means that the discovery-guide-service-b provider is isolated.

Reject to invoke because of isolation with different service group


If the Header of n-d-service-group=discovery-guide-group is added, then both groups remain the same, and the call passes. This is a way to isolate heterogeneous system calls from microservices.

Full Link Service Current Limiting Fuse Degradation Authority and Gray Level Fusion Based on entinel

Implementing this function on the server side by integrating Sentinel

It encapsulates Nacos Data Source and Apollo Data Source, supports Nacos and Apollo remote configuration centers, and implements Sentinel function in zero code. For more remote configuration centers, refer to Sentinel's official DataSource and integrate yourself

1. Nacos Key format: Group is the [group name] configured in metadata, Data Id is the [service name] - [rule type]
2. The Key format of Apollo: [group name] - [service name] - [rule type]

Supports the read logic of remote configuration center and local rule file, that is, read remote configuration first, and read local rule file if there are no or rule errors. Dynamic implementation of hot refresh of rules in remote configuration center

The following switches are supported to turn on the kinetic energy, which is turned off by default.

# Start and close Sentinel current limiting downgrade fuse privilege and other functions. Default is false
spring.application.strategy.sentinel.enabled=true

Annotation of native Sentinel

Referring to the following code, add the @SentinelResource annotation to the interface method, value is sentinel-resource, blockHandler and fallback are the methods to be executed to protect its function.

@RestController
@ConditionalOnProperty(name = DiscoveryConstant.SPRING_APPLICATION_NAME, havingValue = "discovery-guide-service-b")
public class BFeignImpl extends AbstractFeignImpl implements BFeign {
    private static final Logger LOG = LoggerFactory.getLogger(BFeignImpl.class);

    @Override
    @SentinelResource(value = "sentinel-resource", blockHandler = "handleBlock", fallback = "handleFallback")
    public String invoke(@PathVariable(value = "value") String value) {
        value = doInvoke(value);

        LOG.info("Call path:{}", value);

        return value;
    }

    public String handleBlock(String value, BlockException e) {
        return value + "-> B server sentinel block, cause=" + e.getClass().getName() + ", rule=" + e.getRule() + ", limitApp=" + e.getRuleLimitApp();
    }

    public String handleFallback(String value) {
        return value + "-> B server sentinel fallback";
    }
}

Native Sentinel rule

For the use of native Sentinel rules, see Sentinel official documentation

Flow control rules

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-flow. The rule is as follows:

[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "grade": 1,
        "count": 1,
        "strategy": 0,
        "refResource": null,
        "controlBehavior": 0,
        "warmUpPeriodSec": 10,
        "maxQueueingTimeMs": 500,
        "clusterMode": false,
        "clusterConfig": null
    }
]

Rule of demotion

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-degrade. The rule is as follows:

[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "count": 2,
        "timeWindow": 10,
        "grade": 0,
        "passCount": 0
    }
]

Authorization rules

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows:

[
    {
        "resource": "sentinel-resource",
        "limitApp": "discovery-guide-service-a",
        "strategy": 0
    }
]

System Rules

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-system. The rule is as follows:

[
    {
        "resource": null,
        "limitApp": null,
        "highestSystemLoad": -1.0,
        "highestCpuUsage": -1.0,
        "qps": 200.0,
        "avgRt": -1,
        "maxThread": -1
    }
]

Flow Control Rules for Hot Point Parameters

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-param-flow. The rule is as follows:

[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "grade": 1,
        "paramIdx": 0,
        "count": 1,
        "controlBehavior": 0,
        "maxQueueingTimeMs": 0,
        "burstCount": 0,
        "durationInSec": 1,
        "paramFlowItemList": [],
        "clusterMode": false
    }
]

Protection mechanism based on gray-level routing and entinel-LimitApp extension

This method is valid for the above five rules, which are described in terms of authorization rules.

In the authorization rule, limitApp, if there are more than one, can be separated by ",". "strategy": 0 means white list, and "strategy": 1 means black list.

Protection mechanism based on service name

Modifying the Header name of the service name for the configuration item Sentinel Request Origin Key and the corresponding service name for limitApp in the authorization rules can realize the protection mechanism based on the service name.

Configuration item, which defaults to n-d-service-id, can not be configured

spring.application.strategy.service.sentinel.request.origin.key=n-d-service-id

Add the rule of discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows, indicating that all discovery-guide-service-a services allow access to discovery-guide-service-b services.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "discovery-guide-service-a",
        "strategy": 0
    }
]

Protection mechanism based on gray group

Modifying the configuration item Sentinel Request Origin Key as the Header name of gray-scale group and the corresponding group name of limitApp in authorization rules can realize the protection mechanism based on group name.

Configuration Items

spring.application.strategy.service.sentinel.request.origin.key=n-d-service-group

Increase the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows, indicating that all services belonging to my-group are allowed to access service discovery-guide-service-b.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "my-group",
        "strategy": 0
    }
]

Protection mechanism based on gray version

Modifying the name of Sentinel Request Origin Key as gray level version of Header and the corresponding version of limitApp in authorization rules can realize version-based protection mechanism.

Configuration Items

spring.application.strategy.service.sentinel.request.origin.key=n-d-service-version

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows. All services with version 1.0 are allowed to access service discovery-guide-service-b.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "1.0",
        "strategy": 0
    }
]

Protection mechanism based on gray area

Modifying the configuration item Sentinel Request Origin Key as the Header name of gray area and the corresponding area of limitApp in authorization rules can realize the region-based protection mechanism.

Configuration Items

spring.application.strategy.service.sentinel.request.origin.key=n-d-service-region

Add the rule of service discovery-guide-service-b. Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows. All services with dev area are allowed to access service discovery-guide-service-b.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "dev",
        "strategy": 0
    }
]

Protection mechanism based on machine address and port

Modifying the configuration item Sentinel Request Origin Key as the Header name of the gray area and the limit App as the corresponding area value in the authorization rules can realize the protection mechanism based on machine address and port.

Configuration Items

spring.application.strategy.service.sentinel.request.origin.key=n-d-service-address

Add the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows, indicating that services with addresses and ports 192.168.0.88:8081 and 192.168.0.88:8082 can access service discovery-guide-service-b.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "192.168.0.88:8081,192.168.0.88:8082",
        "strategy": 0
    }
]

Composite Protection Mechanism for Customizing Business Parameters

A Composite Protection Mechanism for Customizing Business Parameters by Adapting Classes

// Custom Version Number + User Name to Realize Composite Fuse
public class MyServiceSentinelRequestOriginAdapter extends DefaultServiceSentinelRequestOriginAdapter {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        String version = request.getHeader(DiscoveryConstant.N_D_SERVICE_VERSION);
        String user = request.getHeader("user");

        return version + "&" + user;
    }
}

In the configuration class, @Bean mode is used to create the adapter class

@Bean
public ServiceSentinelRequestOriginAdapter ServiceSentinelRequestOriginAdapter() {
    return new MyServiceSentinelRequestOriginAdapter();
}

Increase the rule of service discovery-guide-service-b, Group is discovery-guide-group, Data Id is discovery-guide-service-b-sentinel-authority. The rule is as follows: user=zhangsan of Http Header with version 1.0, and all services satisfying these two conditions are allowed to access service discovery-guide-service-b-authority.

[
    {
        "resource": "sentinel-resource",
        "limitApp": "1.0&zhangsan",
        "strategy": 0
    }
]

Operation effect

  • When user=zhangsan is passed in Http Header, when full link call is made, API gateway load balancing discovery-guide-service-a service is called after 1.0 version, and then discovery-guide-service-b service is invoked successfully.

  • When user=lisi in the passed Http Header does not satisfy the condition, the final call is rejected on the discovery-guide-service-b server side.

  • When user=zhangsan is passed in Http Header, one of the conditions is satisfied. When the API gateway load balancing discovery-guide-service-a service reaches version 1.1, it calls discovery-guide-service-b service, which does not satisfy version=1.0. Finally, the call is rejected at the discovery-guide-service-b server.

Full Link Service Current Limiting Fuse and Gray Level Fusion Based on Hystrix

By introducing Hystrix component to realize the function of service current limiting fuse, when executing gray level publishing and routing, calling in thread pool isolation mode will lose context, so the following steps are needed to avoid this situation. The following steps apply to both the gateway and the server

  • Pom introduction
<! - When a service uses Hystrix to isolate threads, it needs to import the following packages - >.
<dependency>
    <groupId>com.nepxion</groupId>
    <artifactId>discovery-plugin-strategy-starter-hystrix</artifactId>
    <version>${discovery.version}</version>
</dependency>
  • Configuration Open
# When opening the server to implement Hystrix thread isolation mode for service isolation, spring. application. strategy. hystrix. threadlocal. support must be set to true, and discovery-plugin-strategy-starter-hystrix package should be introduced. Otherwise, ThreadLocal context object will be lost during thread switching. Default is false
spring.application.strategy.hystrix.threadlocal.supported=true

Full link gray call chain

The gray scale call chain mainly includes the following six parameters. Users can define their own call chain parameters to be passed, such as traceId, spanId, etc. They can also define their own call chain parameters to be passed, such as mobile, user, etc.

1. n-d-service-group-service subgroup or application
 2. n-d-service-type-service type, divided into "gateway" and "service"
3. n-d-service-id-service ID
 4. n-d-service-address-service address, including Host and Port
 5. n-d-service-version-service version
 6. n-d-service-region-service area

Gray level call chain output is divided into Header mode and log mode.

Header output mode

Header Mode Framework Internal Integration

  • The Spring Cloud Gateway gateway transmits the Header value itself (refer to AbstractGateway Strategy RouteFilter. Java in the Discovery source code)
  • The Zuul gateway transmits the Header value itself (refer to AbstractZuul Strategy RouteFilter. Java in the Discovery source code)
  • The server transmits Header values through Feign and RestTemplate interceptors (refer to FeignStrategyInterceptor.java and RestTemplate StrategyInterceptor. Java in Discovery source code)

Log Output Mode

  • Spring Cloud Gateway Gateway

Inheriting Gateway StrategyTracer. java, the trace method outputs six parameters (referring to the debugTraceHeader method in the parent class) or more to the log through MDC.

// Custom call chain and gray call chain are output to the log through MDC. When integrating users, just focus on the MDC.clear code in the MDC.put and release methods of the trace method.
public class MyGatewayStrategyTracer extends DefaultGatewayStrategyTracer {
    @Override
    public void trace(ServerWebExchange exchange) {
        super.trace(exchange);
        
        // Output to log
        MDC.put("traceid", "traceid=" + strategyContextHolder.getHeader("traceid"));
        ...

        MDC.put(DiscoveryConstant.N_D_SERVICE_GROUP, "Service group name=" + strategyContextHolder.getHeader(DiscoveryConstant.N_D_SERVICE_GROUP));
        ...
    }

    @Override
    public void release(ServerWebExchange exchange) {
        MDC.clear();
    }
}

In the configuration class, the @Bean method is used to create call chain classes, covering the built-in call chain classes in the framework.

@Bean
@ConditionalOnProperty(value = StrategyConstant.SPRING_APPLICATION_STRATEGY_TRACE_ENABLED, matchIfMissing = false)
public GatewayStrategyTracer gatewayStrategyTracer() {
    return new MyGatewayStrategyTracer();
}
  • Zuul Gateway

Inheriting ZuulStrategyTracer.java, the trace method outputs six parameters (referring to the debugTraceHeader method in the parent class) or more via MDC to the log.

// Custom call chain and gray call chain are output to the log through MDC. When integrating users, just focus on the MDC.clear code in the MDC.put and release methods of the trace method.
public class MyZuulStrategyTracer extends DefaultZuulStrategyTracer {
    @Override
    public void trace(RequestContext context) {
        super.trace(context);
        
        // Output to log
        MDC.put("traceid", "traceid=" + strategyContextHolder.getHeader("traceid"));
        ...

        MDC.put(DiscoveryConstant.N_D_SERVICE_GROUP, "Service group name=" + strategyContextHolder.getHeader(DiscoveryConstant.N_D_SERVICE_GROUP));
        ...
    }

    @Override
    public void release(RequestContext context) {
        MDC.clear();
    }
}

In the configuration class, the @Bean method is used to create call chain classes, covering the built-in call chain classes in the framework.

@Bean
@ConditionalOnProperty(value = StrategyConstant.SPRING_APPLICATION_STRATEGY_TRACE_ENABLED, matchIfMissing = false)
public ZuulStrategyTracer zuulStrategyTracer() {
    return new MyZuulStrategyTracer();
}
  • Service Services

Inheriting ServiceStrategyTracer.java, the trace method outputs six parameters (referring to the debugTraceLocal method in the parent class) or more to the log through MDC

// Custom call chain and gray call chain are output to the log through MDC. When integrating users, just focus on the MDC.clear code in the MDC.put and release methods of the trace method.
public class MyServiceStrategyTracer extends DefaultServiceStrategyTracer {
    @Override
    public void trace(ServiceStrategyTracerInterceptor interceptor, MethodInvocation invocation) {
        super.trace(interceptor, invocation);
        
        // Output to log
        MDC.put("traceid", "traceid=" + strategyContextHolder.getHeader("traceid"));
        ...

        MDC.put(DiscoveryConstant.N_D_SERVICE_GROUP, "Service group name=" + pluginAdapter.getGroup());
        ...
    }

    @Override
    public void release(ServiceStrategyTracerInterceptor interceptor, MethodInvocation invocation) {
        MDC.clear();
    }
}

In the configuration class, the @Bean method is used to create call chain classes, covering the built-in call chain classes in the framework.

@Bean
@ConditionalOnProperty(value = StrategyConstant.SPRING_APPLICATION_STRATEGY_TRACE_ENABLED, matchIfMissing = false)
public ServiceStrategyTracer serviceStrategyTracer() {
    return new MyServiceStrategyTracer();
}

Refer to the results printed on the IDE console

For the opening and closing of the call chain function, the following switches are needed to control it:

# Start and close the call chain. Default is false
spring.application.strategy.trace.enabled=true
# Start and close the Debug log printing of the call chain. Note that every call will be printed once, which will have an impact on performance. It is recommended that the pressure measurement environment and production environment be closed. Default is false
spring.application.strategy.trace.debug.enabled=true

Full-link Header Transfer

The framework will default to the relevant Header for full link transmission, which can be done through the following configuration. In addition, any Header that starts with "n-d-" will default to full-link delivery.

# When starting and closing routing policy, call interception of REST mode. Default is true
spring.application.strategy.rest.intercept.enabled=true
# Start and close the Debug log printing passed by Header. Note that every call will be printed once, which will have an impact on performance. It is recommended that the pressure measurement environment and production environment be closed. Default is false
spring.application.strategy.rest.intercept.debug.enabled=true
# When using grayscale routing strategy, when calling interception for REST (supporting Feign or RestTemplate calls), you want to transfer the Header parameters from external customization (for framework context headers, such as traceid, spanid, etc.) to the service. Then configure the following values. If multiple spaces are separated by ";", no spaces are allowed.
spring.application.strategy.context.request.headers=traceid;spanid
# When using grayscale routing strategy, when calling interception for REST mode (supporting Feign or RestTemplate calls), you want to transfer the Header parameters from external customization (for business system sub-definition Header, e.g. mobile) to the service, then configure the following values. If multiple spaces are separated by ";", no spaces are allowed.
spring.application.strategy.business.request.headers=user;mobile

Native Feign Header delivery can be implemented using Request Interceptor interceptor, and native RestTemplate Header delivery can be implemented using Client HttpRequest Interceptor interceptor.

This framework also uses these native interceptors as Header's gray-level function transfer. In order to avoid users creating another layer of interceptors, the framework abstracts two interceptor adapters, which are consistent with the original two interceptors. It can help users to realize custom Header transmission.

Custom Feign-Header Passing

Implement FeignStrategyInterceptorAdapter.java, add custom Header delivery in application method

// Header Passing in Custom Feign Interceptor
public class MyFeignStrategyInterceptorAdapter extends DefaultFeignStrategyInterceptorAdapter {
    @Override
    public void apply(RequestTemplate requestTemplate) {
        requestTemplate.header("n-d-my-id", "123");
    }
}

Create interception adapter in @ Bean mode in configuration class

@Bean
public FeignStrategyInterceptorAdapter feignStrategyInterceptorAdapter() {
    return new MyFeignStrategyInterceptorAdapter();
}

Custom RestTemplate-Header Passing

Implement RestTemplateStrategyInterceptorAdapter.java, add custom Header delivery in intercept method

// Custom Header Passing in RestTemplate Interceptor
public class MyRestTemplateStrategyInterceptorAdapter extends DefaultRestTemplateStrategyInterceptorAdapter {
    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {
        HttpHeaders headers = request.getHeaders();
        headers.add("n-d-my-id", "456");

        return execution.execute(request, body);
    }
}

Interception adapter creation in configuration class by @Bean mode

@Bean
public RestTemplateStrategyInterceptorAdapter restTemplateStrategyInterceptorAdapter() {
    return new MyRestTemplateStrategyInterceptorAdapter();
}

Docker Containerization and Kubernetes Platform

Docker Containerization

  • Building Docker Environment under Windows 10 Operating System or Linux Operating System

  • Fully Automated Deployment and operation of Docker ized services. Under the root directory

    • One-click run install-docker-gateway.bat or.sh to fully deploy and run the Spring Cloud Gateway gateway
    • Run install-docker-zuul.bat or.sh with one click to fully deploy and run the Zuul gateway
    • One-click run install-docker-service-xx.bat or.sh to fully deploy and run micro services. Note that it must be run sequentially, that is, the next one can not be executed until the last one has been deployed.

Kubernetes Platform

Please do your own research.

This article is a multi-blog platform OpenWrite Release!

Topics: Java Spring Mobile xml

Hot Topics

©2024 Programmer Think