便宜VPS网Spring微服务灰度发布（热部署）的实现（二）
接着上篇说，我们微服务中用到的nepxion discovery主要采用了三种灰度发布方式，一种是web图形化界面发布，二是zuul过滤器灰度发布，三是业务参数策略灰度发布。下面将重点介绍三种方式的实现。
一、web图形化界面灰度发布
因为我们项目用到了eureka注册中心，所以选择web图形化界面灰度发布比较合适。
1） 首先需要建立一个discovery控制台工程console, 端口为2222，控制台工程负责web图形化界面请求的处理，运行console工程。
2） 下载discovery ui,地址：，运行discovery UI，端口为8090
3）浏览器中输入localhost:8090,即可打开控制台，如下
注意：全链路灰度发布需要在“配置中心”下才可用。灰度发布配置中心，负责存储全链路灰度发布规则，并将规则推送到各个微服务中。而配置中心可用nacos，redis等，Discovery 中提供了相应配置中心的插件包。
二、zuul网关过滤器灰度发布
通过网关过滤器传递Http Header的方式传递全链路灰度路由规则。下面代码只适用于Zuul和Spring Cloud Gateway网关，Service微服务不需要加该方式。
三、业务参数在策略类中自定义灰度路由规则
通过策略方式自定义灰度路由规则。下面代码既适用于Zuul和Spring Cloud Gateway网关，也适用于Service微服务，同时全链路中网关和服务都必须加该方式
上面说了具体灰度规则发布方式，那究竟怎么定义灰度规则呢？？
规则是基于XML或者Json为配置方式，存储于本地文件或者远程配置中心，可以通过远程配置中心修改的方式达到规则动态化。其核心代码参考discovery-plugin-framework以及它的扩展、discovery-plugin-config-center以及它的扩展和discovery-plugin-admin-center等，规则示例
XML示例（Json示例见discovery-springcloud-example-service下的rule.json）
黑/白名单的IP地址注册的过滤规则
微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册。规则如何使用，见示例说明
最大注册数的限制的过滤规则
微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册。规则如何使用，见示例说明
黑/白名单的IP地址发现的过滤规则
微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤规则”一致
版本访问的灰度发布规则
版本权重的灰度发布规则
全局版本权重的灰度发布规则
区域权重的灰度发布规则
全局区域权重的灰度发布规则
网关端全链路路由策略的灰度发布规则
注意 路由策略的入口有三个（以{\"discovery-springcloud-example-a\":\"1.0\", \"discovery-springcloud-example-b\":\"1.0\", \"discovery-springcloud-example-c\":\"1.0;1.2\"}）为例：
其作用的优先级为外界传入网关Filter指定配置中心或者本地rule.xml配置
您可以根据自己需求，自由定义灰度发布规则，灵活实现微服务的灰度发布。
源码位置：
intellij开发web，为什么每次重启tomcat才能部署成功
确保使用的是debug模式。
确保tomcat是由idea实例化的。也就是说tomcat是在idea中配置好的
（特殊的修改如：项目配置文件，某些特殊类新增，方法名称参数的添加修改引起的不能热部署就必须重启，当然你也可以用Jrebel插件。此插件收费。可以实现大部分的修改热部署，包括修改项目配置文件等热部署。以下描述均指的是普通的修改下的热部署。）
项目配置如图：
当修改文件后，ctrl+F9，编译文件。tomcat会自动加载新文件。
On frame deactivation选项同样可以选择为 update classes and Resource选项。它的作用就是在你失去焦点的时候自动编译。例如：修改某文件后你直接切换到了浏览器，或者点了下别的。只要当前的intellij idea 不是焦点就会激活自动编译并更新文件动作。也就是说不用手动按ctrl+F9了。
所有以上操作，请确保是在DEBUG模式下操作。也就是运行tomcat的时候是debug模式启动的。
热部署是什么意思
所谓热部署，就是在应用正在运行的时候升级软件，却不需要重新启动应用。
对于Java应用程序来说，热部署就是在运行时更新Java类文件。在基于Java的应用服务器实现热部署的过程中，类装入器扮演着重要的角色。
大多数基于Java的应用服务器，包括EJB服务器和Servlet容器，都支持热部署。类装入器不能重新装入一个已经装入的类，但只要使用一个新的类装入器实例，就可以将类再次装入一个正在运行的应用程序。
扩展资料
辅助用户使用和管理PKUAS的工具集合，主要包括部署工具、配置工具与实时监控工具。其中，部署工具既可热部署整个应用，也可热部署单个构件，从而实现应用的在线演化；配置工具允许用户配置整个服务器或单个应用；而实时监控工具允许用户实时观察系统的运行状态并作出相应调整。
没有热部署和有热部署的开发效率是天差地别的。这个问题还受很多第三方软件包(Struts，Spring，Hibernate)的限制。本来可以热部署，加入了第三方的包就不可以了。所以，先说明详细的 软件环境，和程序配置是非常必要的。
参考资料来源：百度百科-热部署
android 热部署是什么意思
在 Java 开发领域，热部署一直是一个难以解决的问题，目前的 Java 虚拟机只能实现方法体的修改热部署，对于整个类的结构修改，仍然需要重启虚拟机，对类重新加载才能完成更新操作。对于某些大型的应用来说，每次的重启都需要花费大量的时间成本。虽然 osgi 架构的出现，让模块重启成为可能，但是如果模块之间有调用关系的话，这样的操作依然会让应用出现短暂的功能性休克。本文将探索如何在不破坏 Java 虚拟机现有行为的前提下，实现某个单一类的热部署，让系统无需重启就完成某个类的更新。
类加载的探索
首先谈一下何为热部署（hotswap），热部署是在不重启 Java 虚拟机的前提下，能自动侦测到 class 文件的变化，更新运行时 class 的行为。Java 类是通过 Java 虚拟机加载的，某个类的 class 文件在被 classloader 加载后，会生成对应的 Class 对象，之后就可以创建该类的实例。默认的虚拟机行为只会在启动时加载类，如果后期有一个类需要更新的话，单纯替换编译的 class 文件，Java 虚拟机是不会更新正在运行的 class。如果要实现热部署，最根本的方式是修改虚拟机的源代码，改变 classloader 的加载行为，使虚拟机能监听 class 文件的更新，重新加载 class 文件，这样的行为破坏性很大，为后续的 JVM 升级埋下了一个大坑。
另一种友好的方法是创建自己的 classloader 来加载需要监听的 class，这样就能控制类加载的时机，从而实现热部署。本文将具体探索如何实现这个方案。首先需要了解一下 Java 虚拟机现有的加载机制。目前的加载机制，称为双亲委派，系统在使用一个 classloader 来加载类时，会先询问当前 classloader 的父类是否有能力加载，如果父类无法实现加载操作，才会将任务下放到该 classloader 来加载。这种自上而下的加载方式的好处是，让每个 classloader 执行自己的加载任务，不会重复加载类。但是这种方式却使加载顺序非常难改变，让自定义 classloader 抢先加载需要监听改变的类成为了一个难题。
不过我们可以换一个思路，虽然无法抢先加载该类，但是仍然可以用自定义 classloader 创建一个功能相同的类，让每次实例化的对象都指向这个新的类。当这个类的 class 文件发生改变的时候，再次创建一个更新的类，之后如果系统再次发出实例化请求，创建的对象讲指向这个全新的类。
下面来简单列举一下需要做的工作。
创建自定义的 classloader，加载需要监听改变的类，在 class 文件发生改变的时候，重新加载该类。
改变创建对象的行为，使他们在创建时使用自定义 classloader 加载的 class。
自定义加载器的实现
自定义加载器仍然需要执行类加载的功能。这里却存在一个问题，同一个类加载器无法同时加载两个相同名称的类，由于不论类的结构如何发生变化，生成的类名不会变，而 classloader 只能在虚拟机停止前销毁已经加载的类，这样 classloader 就无法加载更新后的类了。这里有一个小技巧，让每次加载的类都保存成一个带有版本信息的 class，比如加载 Test.class 时，保存在内存中的类是 Test_v1.class，当类发生改变时，重新加载的类名是 Test_v2.class。但是真正执行加载 class 文件创建 class 的 defineClass 方法是一个 native 的方法，修改起来又变得很困难。所以面前还剩一条路，那就是直接修改编译生成的 class 文件。
利用 ASM 修改 class 文件
可以修改字节码的框架有很多，比如 ASM，CGLIB。本文使用的是 ASM。先来介绍一下 class 文件的结构，class 文件包含了以下几类信息，一个是类的基本信息，包含了访问权限信息，类名信息，父类信息，接口信息。第二个是类的变量信息。第三个是方法的信息。ASM 会先加载一个 class 文件，然后严格顺序读取类的各项信息，用户可以按照自己的意愿定义增强组件修改这些信息，最后输出成一个新的 class。
首先看一下如何利用 ASM 修改类信息。
清单 1. 利用 ASM 修改字节码
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
ClassReader cr = null;
String enhancedClassName = classSource.getEnhancedName();
try {
cr = new ClassReader(new FileInputStream(
classSource.getFile()));
} catch (IOException e) {
e.printStackTrace();
return null;
}
ClassVisitor cv = new EnhancedModifier(cw,
className.replace(\".\", \"/\"),
enhancedClassName.replace(\".\", \"/\"));
cr.accept(cv, 0);
Python的web项目如何进行动态重载和热部署?
真正意义上的代码热部署应该是类似erlang那样的，将代码更新到节点后不停服务，不断连接的自动应用新代码。auto reload什么的还是会造成业务瞬间中断。我感觉是可以从wsgi容器级别上实现，比如更新代码后检测到文件变更，然后通知容器创建新的wsgi application的实例，之后所有新的请求都发送到新的wdgi application实例上。等旧wsgi application实例的最后一个请求返回后就将其回收掉。不过貌似没有看到类似的实现
