servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wjm wjm <zzz...@gmail.com>
Subject Re: [PROPOSAL] ServiceComb MetaConfig
Date Thu, 04 Apr 2019 08:41:10 GMT
do we have a mechanism to use the configuration with high performance?

Xiaoliang Tian <xiaoliang.tian@gmail.com> 于2019年3月29日周五 下午5:27写道:

> sure, mainly forcus on management , ease of use, rollback, key value
> version control. value validation.
>
> first we support API, later UX.
>
> bismy <bismy@qq.com> 于2019年3月29日周五 下午4:08写道:
>
> > 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.tian@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.tian@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.jiang@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.tian@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
> > >>
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message