修改介绍

README.md

@@ -623,15 +623,15 @@ Discovery【探索】微服务框架，基于Spring Cloud & Spring Cloud Alibaba
         - [全链路服务通过配置来定义](#全链路服务通过配置来定义)
         - [全链路服务通过前缀来定义](#全链路服务通过前缀来定义)
         - [全链路服务通过注入来定义](#全链路服务通过注入来定义)
-    - [全链路智能编排蓝绿灰度发布](#全链路智能编排蓝绿灰度发布)
-        - [全链路智能编排版本逻辑](#全链路智能编排版本逻辑)
-        - [全链路智能编排实现原理](#全链路智能编排实现原理)
-        - [全链路智能编排使用方式](#全链路智能编排使用方式)
     - [全链路无编排蓝绿灰度发布](#全链路无编排蓝绿灰度发布)
         - [全链路无编排的流量染色](#全链路无编排的流量染色)
         - [全链路无编排的蓝绿灰度规则策略](#全链路无编排的蓝绿灰度规则策略)
         - [全链路无编排的故障转移](#全链路无编排的故障转移)
         - [全链路无编排蓝绿灰度发布的总结](#全链路无编排蓝绿灰度发布的总结)
+    - [全链路智能编排蓝绿灰度发布](#全链路智能编排蓝绿灰度发布)
+        - [全链路智能编排版本逻辑](#全链路智能编排版本逻辑)
+        - [全链路智能编排实现原理](#全链路智能编排实现原理)
+        - [全链路智能编排使用方式](#全链路智能编排使用方式)
 - [全链路自动化测试](#全链路自动化测试)
     - [全链路自动化模拟流程测试](#全链路自动化模拟流程测试)
         - [全链路自动化模拟流程本地测试](#全链路自动化模拟流程本地测试)
@@ -3083,6 +3083,119 @@ public StrategyHeadersInjector strategyHeadersInjector() {
 }
 ```
 
+### 全链路无编排蓝绿灰度发布
+有少数公司希望蓝绿灰度发布尽量减少人工操作，降低运作成本，不愿意通过正规流程方式执行。在这里介绍一种固化式无编排高级蓝绿灰度发布
+
+> 所谓固化式，即蓝绿灰度规则策略只配置一次后，永远不再变更
+
+#### 全链路无编排的流量染色
+给服务实例分别打`蓝`和`绿`的版本标签，不需要通过时间戳方式或者数字递增方式
+```
+-Dmetadata.version=blue
+-Dmetadata.version=green
+```
+
+技巧点之一
+- 本次发布执行时，旧服务版本标签为`green`，新服务版本标签为`blue`
+- 下次发布执行时，上次发布的新服务则变成旧服务（它的标记为`blue`），新上线的服务版本标签则为`green`
+- 以后每次发布执行时，`green`和`blue`的版本标签轮番交替使用，这次发布的新版本是`blue`，下次发布的新版本是`green`，再下次发布的新版本是`blue`...
+
+#### 全链路无编排的蓝绿灰度规则策略
+① 蓝绿发布规则策略
+
+当业务参数`a`等于`1`的时候，执行蓝路由；当业务参数`a`等于`2`的时候，执行绿路由
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<rule>    
+    <strategy-release>
+        <conditions type="blue-green">
+            <condition id="condition-0" expression="#H['a'] == '1'" version-id="route-0"/>
+            <condition id="condition-1" expression="#H['a'] == '2'" version-id="route-1"/>
+        </conditions>
+
+        <routes>
+            <route id="route-0" type="version">blue</route>
+            <route id="route-1" type="version">green</route>
+        </routes>
+    </strategy-release>
+</rule>
+```
+
+![](https://nepxion.github.io/Discovery/docs/discovery-doc/Solidify1.jpg)
+
+![](https://nepxion.github.io/Discovery/docs/icon-doc/information.png) 如果不希望蓝绿发布通过业务参数驱动，规则策略还可以进一步简化，实施过程更为简单
+
+当`<version>blue</version>`为`blue`时切换到蓝路由，为`green`时切换到绿路由
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<rule>
+    <strategy>
+        <version>blue</version>
+    </strategy>
+</rule>
+```
+
+② 灰度发布规则策略
+
+当业务参数`a`等于`3`的时候，执行蓝路由占比10%，绿路由占比90%；当业务参数`a`等于`4`的时候，执行蓝路由占比90%，绿路由占比10%
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<rule>
+    <strategy-release>
+        <conditions type="gray">
+            <condition id="condition-0" expression="#H['a'] == '3'" version-id="route-0=10;route-1=90"/>
+            <condition id="condition-1" expression="#H['a'] == '4'" version-id="route-0=90;route-1=10"/>
+        </conditions>
+
+        <routes>
+            <route id="route-0" type="version">blue</route>
+            <route id="route-1" type="version">green</route>
+        </routes>
+    </strategy-release>
+</rule>
+```
+
+![](https://nepxion.github.io/Discovery/docs/discovery-doc/Solidify2.jpg)
+
+技巧点之二
+- 蓝绿发布中`a`的值需要根据每次发布的而改变。这次发布`a`等于`1`执行的是新服务链路，下次发布`a`等于`2`执行的是新服务链路，再下次发布`a`等于`1`执行的是新服务链路...
+- 灰度发布中需要具备两条百分比相互颠倒的权重，例如，route-0=10;route-1=90和route-0=90;route-1=10。这次发布`a`等于`3`执行的是新服务链路10%权重，下次发布`a`等于`4`执行的是新服务链路10%权重，再发布`a`等于`3`执行的是新服务链路10%权重...
+- 每次发布通过`a`值交替改变锚定正确的链路路由
+
+![](https://nepxion.github.io/Discovery/docs/icon-doc/information.png) 如果不希望灰度发布通过业务参数驱动，规则策略还可以进一步简化，实施过程更为简单
+
+蓝路由占比10%，绿路由占比90%
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<rule>
+    <strategy>
+        <version-weight>blue=10;green=90</version-weight>
+    </strategy>
+</rule>
+```
+
+#### 全链路无编排的故障转移
+全链路网关和所有服务必须打开故障转移
+```
+# 启动和关闭版本故障转移。缺失则默认为false
+spring.application.strategy.version.failover.enabled=true
+```
+
+技巧点之三
+- 不允许配置兜底路由。兜底路由一般是对旧版本而言，现有规则策略逻辑下，哪条链路是旧版本路由是不确定的，那么执行发布时候，业务参数不能缺失且必须命中，因为无兜底路由存在
+- 通过打开故障转移去兜底。假设，全链路为网关 -> 服务A  -> 服务B -> 服务C，服务A和服务C要执行蓝绿灰度发布，服务B不需要。当整条链路切换到新版本路由时候，由于服务B不存在新版本，服务A调用服务B，服务A无法找到服务B的新版本，则故障转移到服务B的旧版本
+
+#### 全链路无编排蓝绿灰度发布的总结
+① 优点
+- 不需要通过时间戳方式或者数字递增方式去打标签
+- 不需要每次发布都要去修改规则策略
+- 不需要指定具体要发布的服务列表
+
+② 缺点
+- 要牢记每次发布中版本标签切换的情况，即`green`和`blue`分别代表是新版本路由还是旧版本路由
+- 要牢记业务参数在每次发布驱动链路的情况，即发布中，业务参数不能缺失且必须命中，发布后，业务参数必须缺失
+- 要牢记打开故障转移
+
 ### 全链路智能编排蓝绿灰度发布
 链路智能编排的方式，即路由链路在后台会智能化编排，用户不再需要关心服务实例的版本情况而进行手工编排，只需要配置跟业务参数有关的条件表达式即可，让蓝绿灰度发布变的更简单更易用
 
@@ -3413,95 +3526,6 @@ spring.application.strategy.version.sort.type=time
 - Github Wiki ：[如何使用DevOps运维平台对接的公共接口 - 策略接口](https://github.com/Nepxion/Discovery/wiki/如何使用DevOps运维平台对接的公共接口#策略接口)
 - Gitee Wiki ：[如何使用DevOps运维平台对接的公共接口 - 策略接口](https://gitee.com/nepxion/Discovery/wikis/pages?sort_id=6428158&doc_id=1124387#策略接口)
 
-### 全链路无编排蓝绿灰度发布
-有少数公司希望蓝绿灰度发布尽量减少人工操作，降低运作成本，不愿意通过正规流程方式执行。在这里介绍一种固化式无编排高级蓝绿灰度发布
-
-> 所谓固化式，即蓝绿灰度规则策略只配置一次后，永远不再变更
-
-#### 全链路无编排的流量染色
-给服务实例分别打`蓝`和`绿`的版本标签，不需要通过时间戳方式或者数字递增方式
-```
--Dmetadata.version=blue
--Dmetadata.version=green
-```
-
-技巧点之一
-- 本次发布执行时，旧服务版本标签为`green`，新服务版本标签为`blue`
-- 下次发布执行时，上次发布的新服务则变成旧服务（它的标记为`blue`），新上线的服务版本标签则为`green`
-- 以后每次发布执行时，`green`和`blue`的版本标签轮番交替使用，这次发布的新版本是`blue`，下次发布的新版本是`green`，再下次发布的新版本是`blue`...
-
-#### 全链路无编排的蓝绿灰度规则策略
-① 蓝绿发布规则策略
-
-当业务参数`a`等于`1`的时候，执行蓝路由；当业务参数`a`等于`2`的时候，执行绿路由
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<rule>    
-    <strategy-release>
-        <conditions type="blue-green">
-            <condition id="condition-0" expression="#H['a'] == '1'" version-id="route-0"/>
-            <condition id="condition-1" expression="#H['a'] == '2'" version-id="route-1"/>
-        </conditions>
-
-        <routes>
-            <route id="route-0" type="version">blue</route>
-            <route id="route-1" type="version">green</route>
-        </routes>
-    </strategy-release>
-</rule>
-```
-
-![](https://nepxion.github.io/Discovery/docs/discovery-doc/Solidify1.jpg)
-
-② 灰度发布规则策略
-
-当业务参数`a`等于`3`的时候，执行蓝路由占比90%，绿路由占比10%；当业务参数`a`等于`4`的时候，执行蓝路由占比70%，绿路由占比30%
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<rule>
-    <strategy-release>
-        <conditions type="gray">
-            <condition id="condition-0" expression="#H['a'] == '3'" version-id="route-0=10;route-1=90"/>
-            <condition id="condition-1" expression="#H['a'] == '4'" version-id="route-0=90;route-1=10"/>
-        </conditions>
-
-        <routes>
-            <route id="route-0" type="version">blue</route>
-            <route id="route-1" type="version">green</route>
-        </routes>
-    </strategy-release>
-</rule>
-```
-
-![](https://nepxion.github.io/Discovery/docs/discovery-doc/Solidify2.jpg)
-
-技巧点之二
-- 蓝绿发布中`a`的值需要根据每次发布的而改变。这次发布`a`等于`1`执行的是新服务链路，下次发布`a`等于`2`执行的是新服务链路，再下次发布`a`等于`1`执行的是新服务链路...
-- 灰度发布中需要具备两条百分比相互颠倒的权重，例如，route-0=10;route-1=90和route-0=90;route-1=10。这次发布`a`等于`3`执行的是新服务链路10%权重，下次发布`a`等于`4`执行的是新服务链路10%权重，再发布`a`等于`3`执行的是新服务链路10%权重...
-- 每次发布通过`a`值交替改变锚定正确的链路路由
-
-#### 全链路无编排的故障转移
-全链路网关和所有服务必须打开故障转移
-```
-# 启动和关闭版本故障转移。缺失则默认为false
-spring.application.strategy.version.failover.enabled=true
-```
-
-技巧点之三
-- 不允许配置兜底路由。兜底路由一般是对旧版本而言，现有规则策略逻辑下，哪条链路是旧版本路由是不确定的，那么执行发布时候，业务参数不能缺失且必须命中，因为无兜底路由存在
-- 通过打开故障转移去兜底。假设，全链路为网关 -> 服务A  -> 服务B -> 服务C，服务A和服务C要执行蓝绿灰度发布，服务B不需要。当整条链路切换到新版本路由时候，由于服务B不存在新版本，服务A调用服务B，服务A无法找到服务B的新版本，则故障转移到服务B的旧版本
-
-#### 全链路无编排蓝绿灰度发布的总结
-① 优点
-- 不需要通过时间戳方式或者数字递增方式去打标签
-- 不需要每次发布都要去修改规则策略
-- 不需要指定具体要发布的服务列表
-
-② 缺点
-- 要牢记每次发布中版本标签切换的情况，即`green`和`blue`分别代表是新版本路由还是旧版本路由
-- 要牢记业务参数在每次发布驱动链路的情况，即发布中，业务参数不能缺失且必须命中，发布后，业务参数必须缺失
-- 要牢记打开故障转移
-
 ## 全链路自动化测试
 ![](https://nepxion.github.io/Discovery/docs/discovery-doc/Inspector.jpg)