maybe the name confused，it is a service only for configurations，but the key contains metadata key1: log_level(service=cart, version=1.0, app=mall) key2: log_level(service=cart, version=1.0, app=mall, ip=x.x.x.x) that is 2 different keys
you can consider apollo has fixed metadata and one fixed view to math their own scenario. but in apollo, key can be very complicated, user can not easily observe keys, a lot of metadata will be attacted to key name, just like ip to "log_level" Willem Jiang <willem.ji...@gmail.com> 于2019年3月29日周五 上午11:36写道： > Hi Xiaoliang, > > Do you propose we start a new project to manage the micro services meta > datas? > Currently we just have a solution to integrate with with Apollo for > configuration management, but what's the difference between the > service metadata and configuration? > I could help us to understand the proposal, if we can drop a clear line > for it. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Mar 29, 2019 at 10:52 AM Xiaoliang Tian > <xiaoliang.t...@gmail.com> wrote: > > > > MetaConfig is a service for configuration management in an large scaled > > distrbuted system. > > > > Currently we use ctrip appllo for config managment, but it is build for a > > paticular scenario. it has fixed schema application,environment,cluster > and > > namespace. Each key belong to that schema. > > > > But it is not enough for operator to manage a complicated infrasctructure > > or application cluster. > > > > So here is the proposal to build a brand new config management service, > > > > *Features: * > > *key with rich metadata: *user can define metadata for a key , that > > distinguish from key to another key. a key will not be stringed by fixed > > schema. metadata is like "env=test, service=cart, version=1.0" or > > "cluster=xxx" or "env=test, service=cart, version=1.0, ip=x.x.x.x" > > *validator: *value can be checked by user defined python script, so in > > runtine if someone want to change this value, the script will check if > this > > value is properate. > > *encryption webhook: *. value can by ecrypt by your custom encryption > > service. > > *event producer: *producer will send key changes event to a target > > service(kafka,rabbitmq, customed). > > *config view: *by setting metadata criteria, MetaConfig will aggregate a > > view to return all key values which match those metadata, so that > operator > > can mange key in their own understading to a distributed system in > > seperated views. > > *config batch action: * with metadate, you can batch update, delete key > > values. for example: update all "service=cart version=1.0" configuration > > log level to "DEBUG" or just update "service=cart version=1.0, > ip=x.x.x.x" > > . > > *rich value type: *not ony plain text any more, but support to be aware > of > > ini, json,yaml,xml and java properties > > *heterogenous configuration system: *able to manage configuration in k8s > > and consul or even more, you can update, delete, and use config view for > > those systems, and you can integrate with your own config system to > > MetaConfig by following standardized API and model >
