lepdou

Thank you for your suggest. We will impliment in next iteration.

netty 和 guava 是冲突最多的两个基础类。是不是可以考虑把这两个基础jar shade 掉？

@DoubleLuXu 感谢支持~ > Polaris-java 支持配置缓存到本地文件，这样初始化配置文件就非常方便，把缓存的配置文件作为基准版本，然后缓存的基础上修改配置即可。 SCT 支持读取本地缓存的配置文件。 2.1 SCT 可以指定本地配置文件目录作为配置来源 2.2 SCT 监听根目录的配置变更，可以动态加载配置，并触发回调。 也就说，在SCT配置 API 层面，完全和远程模式一样 上面是我初步的想法，可能有些地方没考虑周全，有更好的实现。 -------- 目前北极星的一些治理规则会缓存到 polaris/backup/ 目录下，是不是也缓存到这个目录下，比如： ``` polaris/backup/config/${namespace}/${file_group}/${file_name} ```  然后在 polaris-java 里，如果连不上北极星服务的时候，可以 fallback 到本地缓存。这里可以新增一个配置开关，含义是当连不上北极星服务端时，是否fallback...

#640

@DerekYRC 感谢支持~ 时间上没有要求，不是紧急需求

@DerekYRC @misselvexu > 1、"把已有的ConfigChangeEvent类作为Source"的做法可能不太合理。发布ConfigChangeEvent事件的前提是PolarisConfigKVFileChangeListener注解指定了感兴趣的keys，如果没有指定感兴趣的keys就不发布Spring的配置更新事件，显然不合理。 我觉得 spring 的 event 机制和 PolarisConfigKVFileChangeListener 应该是两个独立的处理逻辑，不应该有”潜在“的关系。所以 spring 的 event 应该是所有变更事件都要发布这个事情，然后在事件处理的地方用户自己去处理感兴趣的key。 ---- > 把更新的配置项（下图中的changes变量）作为事件的source，如何？ 我觉得可以 ---- > 2、事件命名为ConfigChangeSpringEvent，如何？ 可以的

我们修复一下

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

> 希望后面可以集成一些基本的如mq隔离等,或者提供一些拓展点出来 这是个好思路，我们想想怎么搞。 @tmaerd 感谢支持~

> Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~ > > 初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？） 消息有一种简单的方案： A 和 A-test1 是不同的 consumer-group， broker 两边都都投递，consumer 消费的时候，判断消息里的tag，是不是属于自己的分组，如果是的话就消费，不是的话就丢弃。 相当于在客户端侧处理，而不是broker端，处理起来简单很多。