如何避免流量打到没有启动完成的节点？
优雅停机==》是为了让服务提供方在停机应用的时候，保证所有调用方都能“安全”地切走流量，不再调用自己，从而做到对业务无损。关键点就在于，让正在停机的服务提供方应用有状态，让调用方感知到服务提供方正在停机
优雅启动==》启动预热+延迟暴露
运行了一段时间后的应用，执行速度会比刚启动的应用更快。在Java里面，在运行过程中，JVM虚拟机会把高频的代码编译成机器码，被加载过的类也会被缓存到JVM缓存中，再次使用的时候不会触发临时加载，这样就使得“热点”代码的执行不用每次都通过解释，从而提升执行速度。但是这些“临时数据”，都在应用重启后就消失了。重启后如果让刚启动的应用就承担像停机前一样的流量，会使应用在启动之初就处于高负载状态，从而导致调用方过来的请求可能出现大面积超时，进而对线上业务产生损害行为。
启动预热：就是让刚启动的服务提供方应用不承担全部的流量，而是让它被调用的次数随着时间的移动慢慢增加，最终让流量缓和地增加到跟已经运行一段时间后的水平一样
调用方发起RPC调用流程：通过服务发现能够获取到服务提供方的IP地址，然后每次发送请求前，都需要通过负载均衡算法从连接池中选择一个可用连接。可以让负载均衡在选择连接的时候，区分一下是否是刚启动不久的应用，对于刚启动的应用，可以让它被选择到的概率特别低，但这个概率会随着时间的推移慢慢变大，从而实现一个动态增加流量的过程。
实现：
1、调用方获取服务提供方启动的时间 ==》获取方法：一种是服务提供方在启动的时候，把自己启动的时间告诉注册中心；另外一种就是注册中心收到的服务提供方的请求注册时间
2、基于权重的负载均衡，将权重设为动态的，随着时间的推移慢慢增加到服务提供方设定的固定值
预热过程
当大批量重启服务提供方的时候 ，会不会导致没有重启的机器因为扛的流量太大而出现问题？
自适应负载均衡算法平缓切换？
延迟暴露
应用启动的时候都是通过main入口，然后顺序加载各种相关依赖的类。如果服务并没有启动完成（加载器他的bean），但调用方获取到了服务提供方的IP，就有可能发起RPC调用，但如果这时候服务提供方没有启动完成的话，就会导致调用失败，从而使业务受损
服务提供方应用在没有启动完成的时候，调用方的请求就过来了，而调用方请求过来的原因是，服务提供方应用在启动过程中把解析到的 RPC 服务注册到了注册中心，这就导致在后续加载没有完成的情况下服务提供方的地址就被服务调用方感知到了。
可以把接口注册到注册中心的时间挪到应用启动完成之后。在应用启动加载、解析Bean的时候，如果遇到了RPC服务的Bean，只先把这个Bean注册到Spring-BeanFactory里面去，并不把这个Bean对应的接口注册到注册中心，只有等应用启动完成后，才把接口注册到注册中心用于服务发现，从而实现让服务调用方延迟获取到服务提供方地址。这样可以保证应用在启动完成后才开始接入流量，但这样还是没有实现最开始的目标。因为这时应用虽然启动完成了，但并没有执行相关的业务代码，所以JVM内存里面还是冷的。如果这时候大量请求过来，还是会导致整个应用在高负载模式下运行，从而导致不能及时地返回请求结果。而且在实际业务中，一个服务的内部业务逻辑一般会依赖其他资源，比如缓存数据。如果能在服务正式提供服务前，先完成缓存的初始化操作，而不是等请求来了之后才去加载，这样就可以降低重启后第一次请求出错的概率。
实现：可以在服务提供方应用启动后，接口注册到注册中心前，预留一个Hook过程，让用户可以实现可扩展的Hook逻辑。用户可以在Hook里面模拟调用逻辑，从而使JVM指令能够预热起来，并且用户也可以在Hook里面事先预加载一些资源，只有等所有的资源都加载完成后，最后才把接口注册到注册中心。