封装设计学习了，想问多应用多集群的问题

[shima-park]

封装设计学习了，想问多应用多集群的问题

[shima-park]

多应用，多集群属于特殊的需求吧，设计的时候考虑到能方便扩展，支持就好。

回答之前那个issue就属于不改源码的情况下，就是使用1对1的基础上支持集群配置读取，监听。

目前这个库在我公司的应用场景，只是针对单个微服务的配置。
一个微服务应用只需要去读取它当前所属集群和环境的对应的配置。

写这个库的主要原因，看github上其它的apollo客户端库，创建对象后就起goroutine去监听配置了。
这对于一些不需要监听配置的应用场景来说，很蛋疼。比如只要启动的时候读取下配置就ok的场景。
能把一些执行行为交给使用者去定义，会比较好。

[zplzpl]

@shima-park 感谢你的工作，想问一下其它的问题：

如果配置修改后，拿到最新的配置，关于资源类型的配置，比如数据库connection info的改变，你们怎么做到reload？

[shima-park]

这种reload方式一般分为两种：轮询，监听。
可以将资源类型获取连接的方法进行封装，封装库的内部进行（轮询）或者（监听事件的变更）。发生变动时替换返回的连接对象。每次业务方法执行时，通过封装库获取连接对象。

我们apollo还在推广阶段。为逐渐微服务化做准备。

• 现有的业务这部分的信息是存在数据库中，轮询的去查询是否有变动，变动的话，尝试替换连接对象。

• 微服务化的试点项目中，把这块查询是否变动的逻辑，改成了依赖于一个基础的微服务。

• 之后把这部分资源类型配置存储到apollo后，可以改成我上面最开始说的，通过监听事件的形式。

[zplzpl]

@shima-park 估计很难避免，重新初始化应用重新创建那些依赖配置的对象

[yanmengjun]

@zplzpl 确实比较难，而且很难改造老系统的那种架构。我们现在更多的是应该场景是正对动态开关类型的，采用watch的方式。