• Introduce the related Plugin Starter dependency to POM.xml

  • You must define a version number for the microservice, either in application.properties or yamL metadata

  • You must customize a Key for microservices to facilitate the classification of microservices, such as group or application, in application. Properties or YAML metadata for remote configuration center push and gray level interface analysis

  • Users only need to pay attention to relevant rule notifications. You can use either of the following methods:

    Push rules through the remote configuration center

    Push rules through the console interface

    Push speculation through client tools such as Postman

  • Go to http://www.iqiyi.com/w_19rzwzovrl.html, change the video resolution to 720P, and maximize playback.

  • Please visit https://pan.baidu.com/s/1eq_N56VbgSCaTXYQ5aKqiA, get more clear video Alt text Alt text.

  • If you are in charge of operations, how often do you find that the service registry in your test environment is registered with the local development environment by some irresponsible developer, causing testers to fail their tests? You want to be able to block the local development environment registration from being registered.

  • If you are the operations leader, an instance of a microservice cluster in a production environment has a temporary problem, but you don’t want it to go offline. You want to be able to block this instance from being called for the time being.

  • If you are a business owner, instances under a microservice cluster release different versions due to the rapid iteration of business services. You want to route according to versioning policies, provide differentiated calls to downstream microservices, and achieve multi-version grayscale access control.

  • If you are A test lead and want to do A/B testing of microservices, do this by dynamically changing versions.

  • With great flexibility – support for filtering control and version grayscale publishing in any link.

  • Minimally restrictive – as long as service registration discovery is enabled, the program entry is added with @enableDiscoveryClient.

  • The IP address filtering mechanism based on black and white lists prohibits the registration of corresponding micro-services.

  • Limit microservice registrations based on the maximum number of registrations. Once the number of registered instances in a microservice cluster reaches the upper limit, subsequent microservices are prohibited from being registered.

  • The IP address filtering mechanism based on black and white lists prevents the corresponding micro-services from being discovered.

  • Based on version pairing, multi-version access control is implemented at the service discovery and load balancing levels by configuring the mapping between the accessible versions of the consumer and provider.

  • Grayscale publishing is realized through rule change.

  • Through version switching, grayscale publishing is realized.

  • The implementation defines the above rules through XML.

  • By default, the remote configuration center integrates Alibaba’s Nacos, asynchronously accepts the rule information pushed by the remote configuration center, and dynamically changes the rules of micro-services.

  • In addition, Spring Boot Actuator asynchronously accepts Rest active push rule information and dynamically changes the rules of microservices.

  • With Spring Boot Actuator, dynamically change the version of microservices.

  • In the control of service registration level, once the condition prohibiting registration is triggered, asynchronous events are actively pushed so that users can subscribe.

  • Users can customize more rule filtering conditions.

  • Consumers can listen for service registration discovery core events.

  • The local microservice of the development environment (for example, its IP address 172.16.0.8) does not want to be registered with the service registry discovery center of the test environment, so you can maintain a black/white list IP address filtering (global and local filtering) rule in the configuration center.

  • We can do this by providing a black/white list.

  • When the number of registered microservices reaches the upper limit (for example, 10), subsequent microservices will not be registered.

  • Development environment of the local service (such as IP addresses for 172.16.0.8) have been registered to the test environment of service discovery center, you can maintain a black/white list in the center of the configuration of the IP address filter (filter) to support global and local rules, the local micro service will not be any other test environment of service calls.

  • We can do this by pushing a black/white list.

  • Service A calls service B, and service B has two instances (B1 and B2). Although the three have the same service name, they are functionally different. The requirement is that at some point, service A can only call B1, and B2 is prohibited. In this scenario, we maintain a version 1.0 for B1 and a version 1.1 for B2 in application.properties.

  • We can call the configuration of the corresponding relationship of service B of A certain version by pushing service A to achieve grayscale control in A sense. When switching the version, we only need to push it again.

  • In A/B testing, the access path is changed by dynamically changing the version without restarting the microservice.

Gray scale before release

  • Assuming the current production environment, the invocation path is Gateway (V1.0)-> Service A(V1.0)-> Service B(V1.0).

  • O&m will release A new production environment and deploy A new service cluster, service A(V1.1) and service B(V1.1).

  • Since the gateway (1.0) does not point to service A(V1.1) and service B(V1.1), they cannot be invoked.

Grayscale publishing

  • Added A gateway for grayscale publishing (V1.1), pointing to Service A(V1.1)-> Service B(V1.1).

  • Grayscale gateway (V1.1) is published to the service registry discovery center, but is forbidden to be discovered by the service. Calls coming in from outside the gateway cannot be load-balanced to the gateway (V1.1).

  • Grayscale test is performed in the call path of Grayscale Gateway (V1.1)-> Service A(V1.1)-> Service B(V1.1).

  • After the grayscale test is successful, point the gateway (V1.0) to Service A(V1.1)-> Service B(V1.1).


After grayscale release

  • Offline service A(V1.0), service B(V1.0), gray scale successful.

  • Gray gateway (V1.1) can not be offline, reserved for the next version online again gray release.

Version Compatibility

  • Spring Cloud F version, please use 4.x.x version, refer to the Master branch for specific code.

  • For Spring Cloud C, D, and E versions, please use 3.X. x. For details, refer to the Edgware branch.

  • X.x does not support the Endpoint function because Swagger and Spring Boot 2.x.x use different actuators. Other functions are the same as 3.x.x.

Middleware compatibility

  • Spring Cloud F version, had better use the Consul 1.2.1 server version (or higher), available from https://releases.hashicorp.com/consul/1.2.1/.

  • Spring Cloud version C, D and E), must adopt the Consul 0.9.3 server version (or lower), available from https://releases.hashicorp.com/consul/0.9.3/.

  • Spring Cloud F, Zookeeper 3.5.x server version (or higher) must be available.

  • Spring Cloud C, D, and E releases, preferably Zookeeper server versions below 3.5.0 (or lower).

  • Be consistent with the Spring Cloud release.

<dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-plugin-starter-eureka</artifactId>    <version>${discovery.plugin.version}</version></dependency><dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-plugin-starter-consul</artifactId>    <version>${discovery.plugin.version}</version></dependency><dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-plugin-starter-zookeeper</artifactId>    <version>${discovery.plugin.version}</version></dependency><dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-plugin-config-center-extension-nacos</artifactId>    <version>${discovery.plugin.version}</version></dependency>Copy the code
<dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-console-starter</artifactId>    <version>${discovery.plugin.version}</version></dependency><dependency>    <groupId>com.nepxion</groupId>    <artifactId>discovery-console-extension-nacos</artifactId>    <version>${discovery.plugin.version}</version></dependency>Copy the code

Project name describe
discovery-plugin-framework The core framework
discovery-plugin-framework-eureka Eureka implementation of the core framework
discovery-plugin-framework-consul Consul implementation of the core framework
discovery-plugin-framework-zookeeper Core framework implementation of Zookeeper
discovery-plugin-config-center Configuration Center implementation
discovery-plugin-config-center-extension-nacos Configure the Nacos extension for the center
discovery-plugin-admin-center Management Center implementation
discovery-plugin-starter-eureka Eureka Starter
discovery-plugin-starter-consul Consul Starter
discovery-plugin-starter-zookeeper Zookeeper Starter
discovery-console Separate console for UI
discovery-console-extension-nacos Nacos extensions for standalone consoles
discovery-console-starter Console Starter
discovery-console-desktop Graphical grayscale release and other desktop programs
discovery-springcloud-example-console Standalone console example
discovery-springcloud-example-eureka Eureka server
discovery-springcloud-example Grayscale publishing and other examples

Rules of the sample 

<? The XML version = "1.0" encoding = "utf-8"? ><rule> <! -- If you do not want to enable the related functions, you only need to delete the related nodes. For example, if you do not want the blacklist function, delete the blacklist node. Black/white list registration filtering for service registrations, which only takes effect when the service is started. The whitelist indicates that only specified IP address prefixes can be registered. The blacklist indicates that specified IP address prefixes cannot be registered. Each service can only be enabled at the same time either whitelist or blacklist --> <! -- filter-type: blacklist/whitelist: indicates the blacklist or blacklist. --> <! -- service-name, indicating the service name --> <! -- filter-value: specifies the black or white IP address list. IP addresses are usually represented by prefixes. Multiple IP addresses are represented by semicolons (;). Delimiter, no Spaces allowed --> <! -- Indicates that IP addresses with the prefix of 10.10 and 11.11 are not allowed to be registered (global filtering) --> <blacklist filter-value="10.10; 11.11 "> <! -- represents the following services, IP addresses prefixed with 172.16 and 10.10 and 11.11 cannot be registered --> <service service-name="discovery-springcloud-example-a" filter-value="172.16"/> </blacklist> <! -- <whitelist filter-value=""> <service service-name="" filter-value=""/> </whitelist> --> <! - Limit the number of service registrations. Registration filtering takes effect only when the service is started. When a specified number of instances of a service are registered, more instances will not be registered --> <! -- service-name, indicating the service name --> <! -- filter-value: indicates the maximum number of registered instances --> <! -- indicates that the maximum number of registered instances of all the following services is 10000 (global configuration) --> <count filter-value="10000"> <! -- represents the following service, the maximum number of registered instances is 5000, the global configuration value 10000 will not work, <service service-name="discovery-springcloud-example-a" filter-value="5000"/> </count> </register> <discovery> <! -- Black/white list discovery filtering for service discovery, same as "Black/white list filtering for service registration" --> <! -- Indicates that IP addresses with the prefix of 10.10 and 11.11 are not allowed to be discovered (global filtering) --> <blacklist filter-value="10.10; 11.11 "> <! -- represents the following services, Do not allow IP addresses prefixed with 172.16 and 10.10 and 11.11 to be discovered --> <service service-name="discovery-springcloud-example-b" filter-value="172.16"/> </blacklist> <! Multi-version greyscale access control for service discovery --> <! -- service-name, indicating the service name --> <! -- version-value: specifies the available version. If multiple versions are available, use; --> <version> <! -- represents the 1.0 of the consumer service A, --> <service consumer-service-name="discovery-springcloud-example-a" The provider - service - name = "discovery - springcloud - example - b" consumer - version - value = "1.0" the provider - version - value = "1.0; 1.1 "/ > <! -- represents the 1.0 of the consumer service B, --> <service consumer-service-name="discovery-springcloud-example-b" The provider - service - name = "discovery - springcloud - example - c" consumer - version - value = "1.0" the provider - version - value = "1.0; 1.1 "/ > <! -- represents 1.1 of the consumer service B, --> <service consumer-service-name="discovery-springcloud-example-b" The provider - service - name = "discovery - springcloud - example - c" consumer - version - value = "1.1" the provider - version - value = "1.2" / > </version> </discovery></rule>Copy the code

Multi-version grayscale rule policy 

< service consumer - service - name = "a" provider - service - name = "b" consumer - version - value = "1.0" The provider - version - value = "1.0, 1.1" / >Copy the code
< service consumer - service - name = "a" provider - service - name = "b" the provider - version - value = "1.0, 1.1" / >Copy the code
< service consumer - service - name = "a" provider - service - name = "b" consumer - version - value = "1.0" / >Copy the code
<service consumer-service-name="a" provider-service-name="b"/>Copy the code
<service consumer-service-name="a" provider-service-name="b" consumer-version-value="" The provider - version - value = "1.0, 1.1" / >Copy the code
<service consumer-service-name="a" provider-service-name="b" consumer-version-value="1.0" provider-version-value=""/>Copy the code
<service consumer-service-name="a" provider-service-name="b" consumer-version-value="" provider-version-value=""/>Copy the code

  1. If the version number of the consumer’s application.properties is not defined, the consumer can access any version of the provider.

  2. The provider’s application.properties does not have a version number, and can only be accessed if the consumer does not do any version configuration in the XML.

Dynamically changing rule policies

  • Rules are classified into local rules and dynamic rules.

  • Local rules are defined in a local rule (for example, rule.xml) file or can be retrieved from a remote configuration center and read at microservice startup time.

  • Dynamic rules are dynamically set through POST or pushed by the remote configuration center.

  • During rule initialization, if the remote configuration center is connected, the remote rule is read first. If the remote rule does not exist, the local rule file is read again.

  • When obtaining multi-rule gray scale rules, obtain dynamic rules first, and then obtain local rules if they do not exist.

Dynamically changing the version policy

  • The version can be local version or dynamic version.

  • The local version is configured in application.properties and is read at microservice startup time.

  • The dynamic version is set dynamically through POST.

    When obtaining the version value with multiple versions, obtain the dynamic version first, and then obtain the local version if it does not exist.

Filtering policy for registration of black and white IP addresses

  • Global filtering refers to all microservices registered in the service registration discovery center. Only IP addresses contained in the prefix of the global filtering field are allowed to register (for whitelists) or not allowed to register (for blacklists).

  • Local filtering refers to a specific microservice. The real filtering condition is global filtering combined with local filtering.

Filtering policy for the maximum number of registrations

  • Global configuration value. Configure the maximum number of microservice clusters that can be registered.

  • A local configuration value is specific to a microservice. If the value exists, the global configuration value becomes invalid.

Filtering policy for discovering black or white IP addresses
The version property field defines the policy 

# Eureka configeureka. Instance. MetadataMap. Eureka version = 1.0. The instance. The metadataMap. - service - group# group = XXX Exotic Consul configuration (see https://springcloud.cc/spring-cloud-consul.html - metadata and the Consul tags) # Consul config (multiple values "," Space, Version = 1.0, for example, value = ABC) spring. Cloud. Consul. Discovery. The tags = version = 1.0, group = XXX - service - group# Zookeeper Configspring. Cloud. Zookeeper. Discovery. Metadata. Version = 1.0 spring. Cloud. Zookeeper. Discovery. The metadata. The group = XXX - service - g roupCopy the code

Functional switching strategy 

# Plugin # Enable and disable controls at the service registration level. Once disabled, the black/white list filtering function for service registrations is invalid, and the filtering function for the maximum number of registrations is invalid. Missing is the default for truespring. Application. Register. Control. The open and close the service discovery enabled = true# level control. Once this function is disabled, the control function of multi-version invocation of a service becomes invalid, and the function of dynamically masking the discovery of a service instance with a specified IP address becomes invalid. Missing is the default for truespring. Application. Discovery. Control. The Rest enabled = true# opened and closed by the rule configuration control and push. Once off, it can only be controlled and pushed through a remote configuration center. Missing is the default for truespring. Application. Config. Rest. Control. The enabled = true# local rules file path, supports two ways: Classpath :rule.xml - The rules file is placed in the Resources directory for easy packing into jars; File: rule-xml - The rule file is placed in the project root directory and placed outside for easy modification. Missing. The default is not spring loaded local rules application. Config. Path = classpath: rule. Xml# Key for micro service classification, generally classified by group field, Such as eureka. Instance. MetadataMap. Group = XXX - group or eureka. Instance. MetadataMap. Application = XXX - application. Missing is the default for group# spring. Application. Group. The key = group# spring. The application. The group. Key = applicationCopy the code

  • For the pull configuration, refer to the discovery-plugin-config-center-extension-nacos project.

  • Push configuration, refer to discovery-console- extension-nacOS project.

  • A series of batch functions.

  • Integration with Nacos for configuration push and cleanup.

Console interface

  • AbstractRegisterListener, an AbstractRegisterListener that can be used to extend and listen to service registrations. For details, see MyRegisterListener in discovery-Spring Cloud-example.

  • AbstractDiscoveryListener, realize the expansion of the service discovery and monitoring, use reference discovery – springcloud – MyDiscoveryListener example. Notice that in Consul, events of both service and management instances are triggered, and you need to distinguish between them, as shown in the following figure.

  • AbstractLoadBalanceListener, the expansion of the load balancing and listening, use reference discovery – springcloud – MyLoadBalanceListener example.

Scene description

  • One gateway Zuul cluster is deployed

  • Three microservice clusters are deployed, namely, service cluster A, service cluster B, and service cluster C. The corresponding instances are 2, 2, and 3

  • Version 1.0 of Gateway Zuul can only call version 1.0 of service A, and version 1.1 of gateway Zuul can only call version 1.1 of service A.

  • Version 1.0 of service A can invoke only version 1.0 of service B, and version 1.1 of service A can invoke only version 1.1 of service B.

  • Version 1.0 of service B can only call versions 1.0 and 1.1 of service C, and version 1.1 of service B can only call version 1.2 of service C.

<? The XML version = "1.0" encoding = "utf-8"? ><rule> <discovery> <version> <! -- represents 1.0 of gateway Z, --> <service consumer-service-name="discovery-springcloud-example-zuul" The provider - service - name = "discovery - springcloud - example - a" consumer - version - value = "1.0" the provider - version - value = "1.0" / > <! -- represents 1.1 of gateway Z, --> <service consumer-service-name="discovery-springcloud-example-zuul" The provider - service - name = "discovery - springcloud - example - a" consumer - version - value = "1.1" the provider - version - value = "1.1" / > <! -- represents the 1.0 of the consumer service A, --> <service consumer-service-name="discovery-springcloud-example-a" The provider - service - name = "discovery - springcloud - example - b" consumer - version - value = "1.0" the provider - version - value = "1.0" / > <! -- represents 1.1 of the consumer service A, --> <service consumer-service-name="discovery-springcloud-example-a" The provider - service - name = "discovery - springcloud - example - b" consumer - version - value = "1.1" the provider - version - value = "1.1" / > <! -- represents the 1.0 of the consumer service B, --> <service consumer-service-name="discovery-springcloud-example-b" The provider - service - name = "discovery - springcloud - example - c" consumer - version - value = "1.0" the provider - version - value = "1.0; 1.1 "/ > <! -- represents 1.1 of the consumer service B, --> <service consumer-service-name="discovery-springcloud-example-b" The provider - service - name = "discovery - springcloud - example - c" consumer - version - value = "1.1" the provider - version - value = "1.2" / > </version> </discovery></rule>Copy the code
Micro service Service port Management of port version
A1 1100 5100 1.0
A2 1101 5101 1.1
B1 1200 5200 1.0
B2 1201 5201 1.1
C1 1300 5300 1.0
C2 1301 5301 1.1
C3 1302 5302 1.2
Zuul 1400 5400 1.0
Service port Management of port
2222 3333

To demonstrate 

<dependency> <groupId>com.nepxion</groupId> <artifactId>discovery-plugin-starter-eureka</artifactId> <! -- <artifactId>discovery-plugin-starter-consul</artifactId> --> <! -- <artifactId>discovery-plugin-starter-zookeeper</artifactId> --> <version>${discovery.plugin.version}</version></dependency>Copy the code

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

An operational demonstration of service registration filtering

  • In rule-xml, write the local IP address in place.

  • Start the DiscoveryApplicationA1. Java.

  • The exception prohibiting registration is thrown, that is, the local service is limited by the IP address list in the blacklist and cannot be registered with the service registration and discovery center. The same is true for whitelisting operations, but the logic is reversed.

  • Change the maximum number of registrations in rule-xml to 0.

  • Start the DiscoveryApplicationA1. Java.

  • Throws an exception prohibiting registration, that is, the local service is limited by the maximum number of registrations and will not be registered with the service registry discovery center.

  • In rule-xml, write the local IP address in place.

  • Start the DiscoveryApplicationA1. Java and DiscoveryApplicationB1. Java, DiscoveryApplicationB2. Java.

  • You can find that service A cannot obtain any instance of service B, that is, service B is restricted to the IP address list in the blacklist and cannot be discovered by service A. The same is true for whitelisting operations, but the logic is reversed.

Operational demonstration of service discovery and load balancing control

  • Go to http://www.iqiyi.com/w_19s07thtsh.html, change the video resolution to 720P, and maximize playback.

  • Please visit https://pan.baidu.com/s/1eq_N56VbgSCaTXYQ5aKqiA for more clear video.

Multi-version gray access control based on Rest 

<? The XML version = "1.0" encoding = "utf-8"? ><rule> <discovery> <version> <service consumer-service-name="discovery-springcloud-example-b" The provider - service - name = "discovery - springcloud - example - c" consumer - version - value = "" the provider - version - value =" 3.0 "/ > </version> </discovery></rule>Copy the code





  • Start DiscoveryApplicationZuul under Discovery-Spring Cloud-Example.

  • Because Zuul is a special microservice, all operations are exactly the same as above.


The Kubernetes project practical training will start on August 17, 2018 in Shenzhen. It will take you 3 days to master Kubernetes systematically
.