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.
