[
https://issues.apache.org/jira/browse/DUBBO-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783152#comment-16783152
]
Trafalgar Ricardo Lu edited comment on DUBBO-35 at 3/10/19 6:15 AM:
--------------------------------------------------------------------
[~chicken]
Hi,
My name is Trafalgar Ricardo Lu and I am studying at Hangzhou Dianzi University
now. I am intersted in this project. Though I didn't use Consul before, I am
famliar with Dubbo, Redis and Zookeeper. These days, I am learning how to use
Consul and its Java API, but some problems come:
# As said in describtion,"Registry, RegistryService, RegistryFactory may be
extended", but I notice that all of servers supported by Dubbo is extended by
FailbackRegistry which can solve the unexpected regist failure and already
extended Registry and RegistryService. May the ConsulRegistry extended it
derectly?
# Consul has two diffirent Java API, one called consul-api and the other is
consul-client. Since I have check it on github and run some demos, I think the
latter is better then former. Which does this project prefer?
# Consul can store K-V and regist services. Both of changes of them can be
subscribed. So, for store K-V, it quite likes Redis, I think ConsulRegistry can
be designed as RedisRegistry. And, for regist services, it can store service
infomation derectly, it kind of like Zookeeper. I prefer using latter, but I
not sure which plan should I suggust in proposal, after all, they both can be
a good solution.
I would appreciate a lot if you could help me with these problems. It would be
useful when writing proposal.
Best Regards,
Trafalgar Ricardo Lu
was (Author: trafalgar ricardo lu):
Hi,
My name is Trafalgar Ricardo Lu and I am studying at Hangzhou Dianzi University
now. I am intersted in this project. Though I didn't use Consul before, I am
famliar with Dubbo, Redis and Zookeeper. These days, I am learning how to use
Consul and its Java API, but some problems come:
# As said in describtion,"Registry, RegistryService, RegistryFactory may be
extended", but I notice that all of servers supported by Dubbo is extended by
FailbackRegistry which can solve the unexpected regist failure and already
extended Registry and RegistryService. May the ConsulRegistry extended it
derectly?
# Consul has two diffirent Java API, one called consul-api and the other is
consul-client. Since I have check it on github and run some demos, I think the
latter is better then former. Which does this project prefer?
# Consul can store K-V and regist services. Both of changes of them can be
subscribed. So, for store K-V, it quite likes Redis, I think ConsulRegistry can
be designed as RedisRegistry. And, for regist services, it can store service
infomation derectly, it kind of like Zookeeper. I prefer using latter, but I
not sure which plan should I suggust in proposal, after all, they both can be
a good solution.
I would appreciate a lot if you could help me with these problems. It would be
useful when writing proposal.
Best Regards,
Trafalgar Ricardo Lu
> GSoC 2019: Consul as one of Dubbo's Service Discovery solution.
> ---------------------------------------------------------------
>
> Key: DUBBO-35
> URL: https://issues.apache.org/jira/browse/DUBBO-35
> Project: Apache Dubbo
> Issue Type: Task
> Reporter: Jun Liu
> Priority: Major
> Labels: GSoC2019
>
> Dubbo has a well-defined [Service
> Directory|https://vaadin.com/blog/microservices-service-registration-and-discovery]
> SPI to integrate with Registry Servers. It's very easy to integrate with
> various registry servers by following the SPI interfaces and conventions.
> Below are the servers supported by Dubbo:
> * Zookeeper
> * Redis
> * Multicast
> * Etcd
> [Consul](https://www.consul.io/) has emerged as a popular Service Directory
> solution for microservices, so I think it should also be included as a
> solution in Dubbo's kit.
> Here is the related SPI definition you may need to extend:
> * Registry
> * RegistryService
> * RegistryFactory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
