springcloud 哪些配置应该放配置中心

[holinhot]

springcloud 哪些配置应该放配置中心比较合理。

配置分 2 种， 一种是不涉及业务逻辑的配置，像数据库、redis 连接用户密码等信息。 第二种是与业务有关联的配置，短信验证码接口 apikey, 多个短信验证码接口的权重; AWS SES 邮件发送接口配置等。 第三种是纯业务配置项，例如是否允许新用户注册的开关; 与上游服务商通信用的 apikey;

按以往没配置中心的情况，除了基本的数据库连接信息外其他都是存在数据库里的。这样好处是方便在管理后台可视化配置并且实时生效，不需要重启服务。

目前第二种与第三种有放注册配置中心也有放数据库里的，感觉非常混乱。 有没有一个干净的划分方案。

[perfectlife]

感觉都放比较好，并且有些配置也是支持热加载的，不用重启服务，统一放配置中心，权限也好整一点

[dddd1919]

除了连配置中心需要的配置之外的所有配置

[holinhot]

@perfectlife 这种状况在业务配置时没有引导和参数验证机制，而且如果产品是交付给客户使用，怎么做以前那种几乎所有配置项都在管理后台操作并且有引导和验证机制。难道要给配置中心单独开发一个配置管理后台？

[perfectlife]

@holinhot 程序内只需要配置配置中心地址和程序使用的配置名称，启动时候会去配置中心拉配置到本地然后启动。交付时候会包含配置中心，我们的供应商交付时候都是包含 nacos/zk 的，这些都是自带管理后台。

[nothingistrue]

除了连接配置中心的配置，和归属于具体节点的配置（例如非自动分配的服务端口号、bus/stream 要用到的实例 ID 等等），全放配置中心。

至于你所说的业务配置，那根配置中心没任何关系，那是“可配置的东西是否做成具体功能”的业务选择性，是完全纯业务的东西。通常来说，这种东西都是做到配置文件里面——并且配置的维护完全由开发方而不是客户负责。如果是选择做成客户可以自由调整的界面功能，那销售绝对脑袋被驴踢了，不但少收一份配置维护的钱，还要多担一份功能没做好的风险。

[holinhot]

@perfectlife nacos 自带管理后台但没有功能项引导和值验证机制

[holinhot]

@nothingistrue 小的系统都是靠卖许可证而不是服务支持。例如 ECShop 这种产品

[nothingistrue]

@holinhot #7 Spring Cloud 配置中心，面向的是超大系统的运维和运营配置，小系统就不需要这些东西。从业务上说，小系统的配置，以单一配置文件为最优解，为了市场的话可以增加一些后台管理界面来做特定的业务配置。从业务范围上来说，小系统连 Spring Cloud 就不该用。

[holinhot]

@nothingistrue 确实如此，对于超大系统来说配置项放业务数据库里性能损耗也严重