配置中心
打包方案
使用 commit 进行打包
方案 | 优点 | 缺点 |
---|---|---|
Docker | - 没有修改依赖的版本的上传(21s)和部署(3s)速度很快 - 强资源限制 - 符合 12factor 原则 |
- 引入了 Docker,需要学习成本; - 对现有的部署方式改动较大 |
将 pip 依赖和配置打包到 git repo 中 | - 符合 12factor 原则 | - 需要保证打包机器和部署机器的系统版本一直,不然下载的 pip 包可能不同 - git 需要处理很多文件,上传和部署很慢 |
只打包配置,不打包依赖 | - 和现有的发布方式最相似,学习成本低 | - 部署速度和现在一样慢 |
zip |
依赖声明
储存在项目根目录的 dependencies.json
中
版本
dependencies.json:
{
"version": "v1",
"configs": ....
"services": ....
}
配置本身的版本,方便以后升级配置的变更。
配置依赖
dependencies.json:
{
"version": "v1",
"configs": [
{
"path": "conf/db/mysql/sorting",
"format": "json"
},
{
"path": "conf/db/mysql/delivery",
"format": "yaml",
"schema": {
"type": "object",
"required": [
"host", "port", "user", "password", "db_name"
]
}
},
{"path": "conf/station/order_host"},
{"path": "conf/station/merchandise_host"},
],
"services": ....
}
configs.path
: 必填
configs.format
:可选,可选值:yaml
, json
, str
,默认值:str
configs.schema
:可选,使用 json schema 进行验证,默认值:true
在 dependencies.json 中,所有配置是平级的;但是在项目具体的文件中,配置是可以嵌套的。Consul 中的 K/V Store 的数据结构和工程实际用到的配置结构是解耦的。之间的对应关系通过下面的这个文件定义
conf.py:
import ConfigFinder
find_config = ConfigFinder("dependencies.json")
CONFIG = {
"order_host": find_config("conf/station/order_host"),
"merchandise_host": find_config("conf/station/merchandise_host"),
"db": {
"mysql": {
"sorting": find_config("conf/db/mysql/sorting"),
"delivery": find_config("conf/db/mysql/delivery"),
},
},
}
TODO:如何检查更新配置,部署更新
TODO:runtime config 要和非 runtime 要分开
服务依赖
dependencies.json:
{
"version": "v1",
"configs": ....,
"services": [
{
"name": "order",
"tags": [],
"meta": {
"version": {">=": "1.2.3", "<": "2.0.0"}
}
},
{ "name": "redis" },
{ "name": "mysql-sorting" },
]
}
services.name
必选
services.tags
可选,consul 的 tags
services.meta
可选,consul 的 meta
下一步
- 熟悉 CI / CD 工具(5月底)
- 制定方案
- 部署 CI/CD(6月底)