@Sure Yes we can use consul. I choose etcd just because service-center already uses it. Actually, if we go with consul, we can even drop service-center, as consul provides service registry/discovery and configuration store. We can keep the schema data as configuration.
I've been suggesting to opensource the CC and it's frontend since May/June. But here we are, there are still no timeline when this will be done. And without this 2 component, the opensource version(servicecomb) feels like a lackluster system. On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang <willem.ji...@gmail.com> wrote: > If we have plan to open source the config center and governance, > it's could be better we start a discussion here to make a road map. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm <zzz...@gmail.com> wrote: > > > > it's better to make huawei config center opensource > > after governance opensource, can work with huawei config center directly > > > > Yang Bo <oaky...@gmail.com> 于2018年11月27日周二 下午2:21写道： > > > > > Etcd in itself is good enough to be used as a config center. I don't > see > > > the need for an extra layer, it reduces performance and adds > complexity. > > > > > > For example, if we use Etcd directly, the watch mechanism is naturally > > > supported by grpc which uses http2, there's no need for using websocket > > > which might have problems under some firewall rules. > > > > > > I checked the CC(CSE) client implementation in java-chassis, it uses > vert.x > > > and http to talk to the server and use websocket for watching when > > > possible. > > > > > > It have implemented tenant, environment separation and we can achieve > this > > > by using proper key prefixes in Etcd(v3). I don't see a particular > feature > > > impossible to implement using Etcd only. > > > > > > Besides, it takes a lot of time and effort to opensource the > Config-Center. > > > > > > There is one minor issue for Etcd though. The official Etcd client for > java > > > jetcd is not published to central maven repository yet. They are > preparing > > > an official 0.3.0 release but does not have a timeline for it. > > > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy <bi...@qq.com> wrote: > > > > > > > Do you have any evaluation document by using etcd as config center? > Now > > > > config-cc supports using Huawei Config Center as the backend. And > this > > > > implementation is based on ectd with an extra abstraction like > service > > > > center. I am not quite sure if using etcd itself can fitful for > users use > > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute it > like > > > > service center which is quite simple too. > > > > > > > > > > > > ------------------ 原始邮件 ------------------ > > > > 发件人: "Yang Bo"<oaky...@gmail.com>; > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > 收件人: "dev"<dev@servicecomb.apache.org>; > > > > > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > Hi, > > > > > > > > The ServiceComb project does not have a usable config-center and many > > > users > > > > have shown concerns about it. (Apollo is too complex to setup and > have > > > high > > > > learning cure in using/maintaining). > > > > > > > > I tried to build a config-center around Etcd for Java-Chassis, it's > quite > > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > > > From my point of view, using Etcd is good for small projects, show > cases > > > > and in development, because we already have an Etcd instance > > > > running(service-center needs it). > > > > > > > > The code is here(it's just a demonstration, needs improvement): > > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > > > > > Any thoughts? > > > > > > > > -- > > > > Best Regards, > > > > Yang. > > > > > > > > > > > > -- > > > Best Regards, > > > Yang. > > > > -- Best Regards, Yang.
