Provide a centered configuration management service is very important for ServiceComb, because all microservice governance functions are based on dynamic properties. In ServiceComb microservice view, now we currently use following functions( implement archaius api using apollo and config-center)
* pull/push configurations of key-value pair from configuration service. in microservice view, no future functions is needed. So I guess the suggested service mainly focus on management functions. How do you decide to provide this functions? Add a management console or by REST api? ------------------ ???????? ------------------ ??????: "Xiaoliang Tian"<xiaoliang.t...@gmail.com>; ????????: 2019??3??29??(??????) ????2:14 ??????: "dev"<dev@servicecomb.apache.org>; ????: Re: [PROPOSAL] ServiceComb MetaConfig let's think how we change a timeout for a particular operation? the key is xxx.usermanagement.user.getuser.timeout, is that key easy to be manged by operator? I guess he has to learn a special key rule only make sense in his team I want this timeout just be timeout, and easy to read it bacame timeout(service= usermanagement , schema=user,opertion=getuser) Xiaoliang Tian <xiaoliang.t...@gmail.com> ??2019??3??29?????? ????12:15?????? > > 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 >> >
