希望每个应用,有自己的config,包括路由,数据库,中间件等等。参考thinkphp。这样对于协同工作更方便。
把“应用”做成插件模式更爽,用就安装,不用就卸载。 不过配置项目不能完全独立。
应该不会增加。每个应用独立配置需要重写大部分组件才能实现,比如在user应用中使用user对应的数据库配置,那么所有的数据库组件包括tp、laravel等都能自动识别当前应用,需要重新二次封装。同理redis、cache、mongodb、队列等很多组件也都需要二次封装下,这会导致耦合很大,开发工作量很大,而且可能无法照顾到所有组件。
config能否支持动态配置啊 现在我观察是启动读取了所有配置文件 配置跟随常驻内存
什么样的业务场景,会需要动态配置呢? 可能我遇见的情况太少了 基本上配置都是静态的
而动态变更配置这个需求本身是比较常见的 比如需要从后台设置配置 ,程序需要从数据库拉取配置、比如多机器部署 共享一个配置中心 配置来源于配置中心
当我有100台机器的时候 变更个配置不可能一台一台去下线、修改配置文件、重启、上线
动态配置需要读数据库或者redis等存储,项目自己封装一个函数(比如叫conf())就好了。 config()函数不知道你的动态配置存储在哪里,也不知道读哪个表哪个库,不好做动态配置
实现config::set()后 业务层自己写进去就好了
自己实现 conf的话 变更数据库配置之类的还是复杂 机器多了根本操作不过来
config::set() 只对当前进程有效,无法对所有服务器所有进程生效,没有意义。 自己实现conf,conf里自己决定从哪个存储读写配置,配置变更,所有服务器生效,不存在服务器多了操作不过来。
把“应用”做成插件模式更爽,用就安装,不用就卸载。
不过配置项目不能完全独立。
应该不会增加。每个应用独立配置需要重写大部分组件才能实现,比如在user应用中使用user对应的数据库配置,那么所有的数据库组件包括tp、laravel等都能自动识别当前应用,需要重新二次封装。同理redis、cache、mongodb、队列等很多组件也都需要二次封装下,这会导致耦合很大,开发工作量很大,而且可能无法照顾到所有组件。
config能否支持动态配置啊 现在我观察是启动读取了所有配置文件 配置跟随常驻内存
什么样的业务场景,会需要动态配置呢?
可能我遇见的情况太少了
基本上配置都是静态的
而动态变更配置这个需求本身是比较常见的 比如需要从后台设置配置 ,程序需要从数据库拉取配置、比如多机器部署 共享一个配置中心 配置来源于配置中心
当我有100台机器的时候 变更个配置不可能一台一台去下线、修改配置文件、重启、上线
动态配置需要读数据库或者redis等存储,项目自己封装一个函数(比如叫conf())就好了。
config()函数不知道你的动态配置存储在哪里,也不知道读哪个表哪个库,不好做动态配置
实现config::set()后 业务层自己写进去就好了
自己实现 conf的话 变更数据库配置之类的还是复杂 机器多了根本操作不过来
config::set() 只对当前进程有效,无法对所有服务器所有进程生效,没有意义。
自己实现conf,conf里自己决定从哪个存储读写配置,配置变更,所有服务器生效,不存在服务器多了操作不过来。