dubbo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DUBBO-35) GSoC 2019: Consul as one of Dubbo's Service Discovery solution.
Date Wed, 13 Mar 2019 02:32:00 GMT

    [ https://issues.apache.org/jira/browse/DUBBO-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791234#comment-16791234

Jun Liu commented on DUBBO-35:



You can apply to GSoC 2019 and choose the Dubbo projects you interested in when GSoC is officially
open to students. As you can see, Dubbo has only two candidate proposals at present, which
are LoadBalancer extension, Registry extension. The community is thinking of providing more
proposals to attract more attendees and give you more choices. 

{quote}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?{quote}
Yes, you are right, extending FailbackRegistry directly if it can solve the problem.

{quote}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.
As far as I know, Consul has a well-refined Service Discovery model that is designed for microservices.
I think adapting Dubbo's service registry and discovery to that model should be enough. 

You can also send your questions or requirements to dev@dubbo.apache.org, there're more experts
that are willing to help. Check here for how to subscribe: https://github.com/apache/incubator-dubbo/issues/1393


> 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
> * 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

View raw message