修改介绍

README.md

@@ -424,20 +424,20 @@ XML示例（也可以通过Json来描述，这里不做描述，见discovery-spr
 
 ### 过滤规则
 #### 黑/白名单的IP地址注册的过滤规则
-微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册
+微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册。规则如何使用，见示例说明
 - 全局过滤，指注册到服务注册发现中心的所有微服务，只有IP地址包含在全局过滤字段的前缀中，都允许注册（对于白名单而言），或者不允许注册（对于黑名单而言）
 - 局部过滤，指专门针对某个微服务而言，那么真正的过滤条件是全局过滤+局部过滤结合在一起
 
 #### 最大注册数的限制的过滤规则
-微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册
+微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册。规则如何使用，见示例说明
 - 全局配置值，只下面配置所有的微服务集群，最多能注册多少个
 - 局部配置值，指专门针对某个微服务而言，那么该值如存在，全局配置值失效
 
 #### 黑/白名单的IP地址发现的过滤规则
-微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤策略”一致
+微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤规则”一致
 
-### 灰度规则策略
-- 版本访问策略
+### 灰度规则
+#### 版本访问规则
 ```xml
 1. 标准配置，举例如下
    <service consumer-service-name="a" provider-service-name="b" consumer-version-value="1.0" provider-version-value="1.0,1.1"/> 表示消费端1.0版本，允许访问提供端1.0和1.1版本
@@ -456,14 +456,15 @@ XML示例（也可以通过Json来描述，这里不做描述，见discovery-spr
 2. 提供端的application.properties未定义版本号，当消费端在xml里不做任何版本配置，才可以访问该提供端
 ```
 
-- 版本权重策略
+#### 版本权重规则
 ```xml
 1. 标准配置，举例如下
    <service consumer-service-name="a" provider-service-name="b" provider-weight-value="1.0=90;1.1=10"/> 表示消费端访问提供端的时候，提供端的1.0版本提供90%的权重流量，1.1版本提供10%的权重流量
 2. 尽量为线上所有版本都赋予权重值
 ```
 
-- 多数据源的数据库灰度策略
+#### 用户自定义规则
+通过订阅业务参数的变化，实现特色化的灰度发布，例如，多数据源的数据库切换的灰度发布
 ```xml
 1. 标准配置，举例如下
    <service service-name="discovery-springcloud-example-b" key="database" value="prod"/>
@@ -472,7 +473,7 @@ XML示例（也可以通过Json来描述，这里不做描述，见discovery-spr
    上线后，一开始数据库指向临时数据库，对应value为temp，然后灰度发布的时候，改对应value为prod，即实现数据库的灰度发布
 ```
 
-### 动态改变规则策略
+### 动态改变规则
 微服务启动的时候，由于规则（例如：rule.xml）已经配置在本地，使用者希望改变一下规则，而不重启微服务，达到规则的改变 
 - 规则分为本地规则和动态规则
 - 本地规则是通过在本地规则（例如：rule.xml）文件定义的，也可以从远程配置中心获取，在微服务启动的时候读取
@@ -485,7 +486,7 @@ XML示例（也可以通过Json来描述，这里不做描述，见discovery-spr
   - 全局推送是基于Group来推送的，就是同一个Group下所有服务集群共同拥有一个规则配置，如果采用这种方式，只需要做一次灰度发布，所有服务集群都生效。优点是非常简便，缺点具有一定风险，因为这个规则配置掌握着所有服务集群的命运。全局推送用于全链路灰度发布
   - 如果既执行了全局推送，又执行了局部推送，那么，当服务运行中，优先接受最后一次推送的规则；当服务重新启动的时候，优先读取局部推送的规则
 
-### 动态改变版本策略
+### 动态改变版本
 微服务启动的时候，由于版本已经写死在application.properties里，使用者希望改变一下版本，而不重启微服务，达到访问版本的路径改变 
 - 版本分为本地版本和动态版本
 - 本地版本是通过在application.properties里配置的，在微服务启动的时候读取