Re: [Discuss]Adding Etcd as a config center for Java-Chassis
If you don't write it from scratch, we need to go through the IP-Clearance process[1] Otherwise, it could introduce some trouble to ServiceComb project. [1]http://incubator.apache.org/ip-clearance/ Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Nov 28, 2018 at 11:55 AM Yang Bo wrote: > > @bismy > > Do you mean the config-center opensource? Yes I can do that. > > On Wed, Nov 28, 2018 at 11:07 AM bismy 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"; > > 发送时间: 2018年11月28日(星期三) 上午10:45 > > 收件人: "dev"; > > > > 主题: 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 于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 > > > 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 wrote: > > > > > > > > > > it's better to make huawei config center opensource > > > > > after governance opensource, can work with huawei config center > > > directly > > > > > > > > > > Yang Bo 于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. > > > > > > > &
?????? [Discuss]Adding Etcd as a config center for Java-Chassis
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"; : 2018??11??28??(??) 11:55 ??: "dev"; : 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 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"; > ????: 2018??11??28??(??) 10:45 > ??: "dev"; > > : 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 ??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 > > 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 wrote: > > > > > > > > it's better to make huawei config center opensource > > > > after governance opensource, can work with huawei config center > > directly > > > > > > > > Yang Bo ??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 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
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 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"; > 发送时间: 2018年11月28日(星期三) 上午10:45 > 收件人: "dev"; > > 主题: 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 于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 > > 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 wrote: > > > > > > > > it's better to make huawei config center opensource > > > > after governance opensource, can work with huawei config center > > directly > > > > > > > > Yang Bo 于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 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 &
?????? [Discuss]Adding Etcd as a config center for Java-Chassis
@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"; : 2018??11??28??(??) 10:45 ??: "dev"; : 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 ??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 > 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 wrote: > > > > > > it's better to make huawei config center opensource > > > after governance opensource, can work with huawei config center > directly > > > > > > Yang Bo ??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 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"; > > > > > : 2018??11??26??(??) 7:30 > > > > > ??: "dev"; > > > > > > > > > > : [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > > > > > Hi, > >
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 于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 > 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 wrote: > > > > > > it's better to make huawei config center opensource > > > after governance opensource, can work with huawei config center > directly > > > > > > Yang Bo 于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 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"; > > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > > 收件人: "dev"; > > > > > > > > > > 主题: [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. >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
@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 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 wrote: > > > > it's better to make huawei config center opensource > > after governance opensource, can work with huawei config center directly > > > > Yang Bo 于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 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"; > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > 收件人: "dev"; > > > > > > > > 主题: [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.
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
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 wrote: > > it's better to make huawei config center opensource > after governance opensource, can work with huawei config center directly > > Yang Bo 于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 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"; > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > 收件人: "dev"; > > > > > > 主题: [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. > >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
Why not use consul? There are more advantages then etcd, for example multiple dc. -- Original -- From: wjm wjm Date: Wed,Nov 28,2018 8:34 AM To: dev Subject: Re: [Discuss]Adding Etcd as a config center for Java-Chassis it's better to make huawei config center opensource after governance opensource, can work with huawei config center directly Yang Bo ??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 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"; > > : 2018??11??26??(??) 7:30 > > ??: "dev"; > > > > : [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. >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
it's better to make huawei config center opensource after governance opensource, can work with huawei config center directly Yang Bo 于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 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"; > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > 收件人: "dev"; > > > > 主题: [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. >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
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 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"; > 发送时间: 2018年11月26日(星期一) 晚上7:30 > 收件人: "dev"; > > 主题: [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.
??????[Discuss]Adding Etcd as a config center for Java-Chassis
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"; : 2018??11??26??(??) 7:30 ??: "dev"; ????: [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.
[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.
