cheese8

How about make an Json interface, and take fastjson, gson, jackson etc as provider implemented the interface, then user could choose it by json provider name configuration？

Could I take this issue? @CrazyHZM

这么大的payload为啥要通过rpc方式？会不会是序列化时间过长的原因？或者上传一个简单demo我们复现一下？

Assign me if it is convient.

初步想法： 1、对于服务注册方 对于spring cloud应用，服务上线ApplicationReadyEvent事件，服务下线ContextClosedEvent事件，可能要考虑下版本兼容问题。 对于非spring cloud应用，服务上线可能没什么好办法，服务下线可考虑hook。 2、服务治理层面 服务提供方可考虑提供Readiness等探针，若 Readiness 失败则不转发流量进来。

> 服务优雅上线： Readiness probe机制 1. 服务治理中心根据Readiness probe结果来更新服务列表并转发流量 2. 服务提供者实现Readiness服务检查端点/actuator/health/readiness ApplicationReadyEvent事件 1. 服务治理中心提供Registration接口 2. 服务提供者捕获ApplicationReadyEvent事件后，注册服务中心 3. 对于不支持ApplicationReadyEvent事件的环境，由服务提供者实现Registration接口，根据自身情况(延时或其它处理)注册服务中心 服务优雅下线： 1. 服务治理中心提供DeRegistration接口 2. 服务提供者addJvmShutdownHook/ContextCloseEvent事件，先解注册服务注册中心，后根据自身执行情况，做一定的延时后下线。 3. 服务提供者根据自身情况，实现DeRegistration接口，在该接口实现中，先解注册服务注册中心，后根据自身执行情况，做一定的延时后下线。

> @cheese8 @1004789224 @mathcad @weihubeats 感谢各位的讨论。 > > 我尝试总结一下： > > ### 服务优雅上线 > #### 1. 整体机制 > 首先整体的原则是尽量复用 Spring Cloud/Spring Boot 已有的机制，在此基础上做扩展。所以 @1004789224 提到的 /actuator/health/readiness 和 ApplicationReadyEvent 事件非常重要。SCT 在决定是否注册到注册中心时，统一判断...

抱歉，上周略忙，下周可以PR。 优雅上线方案，帮忙review一下，多谢。 @misselvexu @SkyeBeFreeman 另：优雅上线和优雅下线，应和业务无关，所以我理解应该不侵入业务，应多从这方面考虑实现方案。 1. GracefulStartUpListener implements ApplicationListener, Ordered override the onApplicationEvent method, and call GracefulStartupReadinessChecker.checkThenRegister 感觉ApplicationStartedEvent应该也可以，但它since 2.0.0, ApplicationReadyEvent since 1.3.0适用更广。 2. GracefulStartupReadinessChecker with checkThenRegister method and default implementation...

PolarisAutoServiceRegistration extends AbstractAutoServiceRegistration and register instance while WebServerInitializedEvent for now, we need to change it to ApplicationReadyEvent.

Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~ 初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？）