Yes, Thank you. If you got any problems, I'd glad to help. I think it's time to make it opensource ASAP.
------------------ ???????? ------------------ ??????: "Yang Bo"<oaky...@gmail.com>; ????????: 2018??11??28??(??????) ????11:55 ??????: "dev"<dev@servicecomb.apache.org>; ????: Re: [Discuss]Adding Etcd as a config center for Java-Chassis @bismy Do you mean the config-center opensource? Yes I can do that. On Wed, Nov 28, 2018 at 11:07 AM bismy <bi...@qq.com> wrote: > @Yang Bo > > > Can you start working on service center opensource? I think it's time for > this task. And there maybe some tasks need to do, like code clean up, > licences and others staffs. I can find one to help you with these works if > needed. > > > I agree with you that servicecomb now seems to be a "lackluster system", > but we are in a quite progressive way to build more, and we are creating > great components. I am preparing a glossary what we are going to build. > > > > > ------------------ ???????? ------------------ > ??????: "Xiaoliang Tian"<xiaoliang.t...@gmail.com>; > ????????: 2018??11??28??(??????) ????10:45 > ??????: "dev"<dev@servicecomb.apache.org>; > > ????: Re: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > etcd used by service center is not allowed to expose directly to any > client, this etcd only exposed service center. unless you setup isolated > etcd cluster for config management > > Yang Bo <oaky...@gmail.com> ??2018??11??28?????? ????10:08?????? > > > @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. > > -- Best Regards, Yang.
