修改介绍

README.md

@@ -18,9 +18,9 @@ Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增
 - [请联系我](#请联系我)
 - [快速开始](#快速开始)
 - [痛点](#痛点)
+- [场景](#场景)
 - [简介](#简介)
 - [名词解释](#名词解释)
-- [场景](#场景)
 - [兼容](#兼容)
 - [依赖](#依赖)
 - [工程](#工程)
@@ -52,15 +52,35 @@ Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增
 ![Alt text](https://github.com/Nepxion/Docs/blob/master/discovery-plugin-doc/Consul.jpg)
 
 ## 痛点
-现有Spring Cloud的痛点
+现有的Spring Cloud微笑服务痛点
 - 如果你是运维负责人，是否会经常发现，你掌管的测试环境中的服务注册中心，被一些不负责的开发人员把他本地开发环境注册上来，造成测试人员测试失败。你希望可以把本地开发环境注册给屏蔽掉，不让注册
 - 如果你是运维负责人，生产环境的某个微服务集群下的某个实例，暂时出了问题，但又不希望它下线。你希望可以把该实例给屏蔽掉，暂时不让它被调用
 - 如果你是业务负责人，鉴于业务服务的快速迭代性，微服务集群下的实例发布不同的版本。你希望根据版本管理策略进行路由，提供给下游微服务区别调用，例如访问控制快速基于版本的不同而切换，例如在不同的版本之间进行流量调拨
 - 如果你是业务负责人，希望灰度发布功能可以基于业务场景特色定制，例如根据用户手机号进行不同服务器的路由
 - 如果你是测试负责人，希望对微服务做A/B测试，那么通过动态改变版本达到该目的
 
+## 场景
+- 黑/白名单的IP地址注册的过滤
+  - 开发环境的本地微服务（例如IP地址为172.16.0.8）不希望被注册到测试环境的服务注册发现中心，那么可以在配置中心维护一个黑/白名单的IP地址过滤（支持全局和局部的过滤）的规则
+  - 我们可以通过提供一份黑/白名单达到该效果
+- 最大注册数的限制的过滤
+  - 当某个微服务注册数目已经达到上限（例如10个），那么后面起来的微服务，将再也不能注册上去
+- 黑/白名单的IP地址发现的过滤
+  - 开发环境的本地微服务（例如IP地址为172.16.0.8）已经注册到测试环境的服务注册发现中心，那么可以在配置中心维护一个黑/白名单的IP地址过滤（支持全局和局部的过滤）的规则，该本地微服务不会被其他测试环境的微服务所调用
+  - 我们可以通过推送一份黑/白名单达到该效果
+- 多版本访问的灰度控制
+  - A服务调用B服务，而B服务有两个实例（B1、B2），虽然三者相同的服务名，但功能上有差异，需求是在某个时刻，A服务只能调用B1，禁止调用B2。在此场景下，我们在application.properties里为B1维护一个版本为1.0，为B2维护一个版本为1.1
+  - 我们可以通过推送A服务调用某个版本的B服务对应关系的配置，达到某种意义上的灰度控制，改变版本的时候，我们只需要再次推送即可
+- 多版本权重的灰度控制
+  - 上述场景中，我们也可以通过配对不同版本的权重（流量比例），根据需求，A访问B的流量在B1和B2进行调拨
+- 动态改变微服务版本
+  - 在A/B测试中，通过动态改变版本，不重启微服务，达到访问版本的路径改变
+- 用户自定义和编程灰度路由策略，可以通过非常简单编程达到如下效果
+  - 我们可以在网关上根据不同的Token查询到不同的用户，把请求路由到指定的服务器
+  - 我们可以在服务上根据不同的业务参数，例如手机号或者身份证号，把请求路由到指定的服务器
+
 ## 简介
-- 实现对基于Spring Cloud的微服务和Spring Cloud Api Gateway（F版）和Zuul网关的支持
+- Nepxion Discovery实现对基于Spring Cloud的微服务和Spring Cloud Api Gateway（F版）和Zuul网关的支持
   - 具有极大的灵活性 - 支持在任何环节做过滤控制和灰度发布
   - 具有极小的限制性 - 只要开启了服务注册发现，程序入口加了@EnableDiscoveryClient
   - 具有极强的可用性 - 当远程配置中心全部挂了，可以通过Rest方式进行灰度发布
@@ -104,26 +124,6 @@ Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增
 - 配置（Config）和规则（Rule），在本系统中属于同一个概念，例如更新配置，即更新规则，例如远程配置中心存储的配置，即规则XML
 - 服务端口和管理端口，即服务端口指在配置文件的server.port值，管理端口指management.port（E版）值或者management.server.port（F版）值
 
-## 场景
-- 黑/白名单的IP地址注册的过滤
-  - 开发环境的本地微服务（例如IP地址为172.16.0.8）不希望被注册到测试环境的服务注册发现中心，那么可以在配置中心维护一个黑/白名单的IP地址过滤（支持全局和局部的过滤）的规则
-  - 我们可以通过提供一份黑/白名单达到该效果
-- 最大注册数的限制的过滤
-  - 当某个微服务注册数目已经达到上限（例如10个），那么后面起来的微服务，将再也不能注册上去
-- 黑/白名单的IP地址发现的过滤
-  - 开发环境的本地微服务（例如IP地址为172.16.0.8）已经注册到测试环境的服务注册发现中心，那么可以在配置中心维护一个黑/白名单的IP地址过滤（支持全局和局部的过滤）的规则，该本地微服务不会被其他测试环境的微服务所调用
-  - 我们可以通过推送一份黑/白名单达到该效果
-- 多版本访问的灰度控制
-  - A服务调用B服务，而B服务有两个实例（B1、B2），虽然三者相同的服务名，但功能上有差异，需求是在某个时刻，A服务只能调用B1，禁止调用B2。在此场景下，我们在application.properties里为B1维护一个版本为1.0，为B2维护一个版本为1.1
-  - 我们可以通过推送A服务调用某个版本的B服务对应关系的配置，达到某种意义上的灰度控制，改变版本的时候，我们只需要再次推送即可
-- 多版本权重的灰度控制
-  - 上述场景中，我们也可以通过配对不同版本的权重（流量比例），根据需求，A访问B的流量在B1和B2进行调拨
-- 动态改变微服务版本
-  - 在A/B测试中，通过动态改变版本，不重启微服务，达到访问版本的路径改变
-- 用户自定义和编程灰度路由策略，可以通过非常简单编程达到如下效果
-  - 我们可以在网关上根据不同的Token查询到不同的用户，把请求路由到指定的服务器
-  - 我们可以在服务上根据不同的业务参数，例如手机号或者身份证号，把请求路由到指定的服务器
-
 ## 架构
 简单描述一下，本系统的核心模块之一的“切换灰度发布”，从网关（Zuul）开始的灰度发布操作过程，您还可以采用更多的灰度发布方式
 - 灰度发布前