Service Discovery

[yancl]

Hi,

  Recently when we construct a cluster using GRPC, we want to add service discovery to it. I know we can add a HAProxy between client and service endpoints to make it,but we also want to add client side support. Now we have several choices, for example, Zookeeper,Etcd and Consul. And currently we prefer consul much more. 

  I know the GRPC will have something like this,so i wander what will be your choice? if that day comes, we can make a good prepare now:)

Thanks 

[Louis Ryan]

I don't know if we'll necessarily have a preference. We'll provide client-side name-resoultion/load-balancing SPIs and some implementations of them for some of these services. Probably Zookeeper & Consul based on naive assumptions about adoption.

[as...@aslam.me]

Interesting discussion about service discovery around gRPC. Hints at the potential future of all this. I'm currently working on a microservices toolchain called Micro which has pluggable client side discovery via consul or similar systems. Soon to have gRPC integration with a PR open here.

Would be happy to talk more about how to build out an ecosystem of tooling around gRPC.

[li...@liulishuo.com]

Thanks for your share, Louis:)

在 2015年4月11日星期六 UTC+8上午4:03:10，Louis Ryan写道：

[Josh Humphries]

I'm curious how much thought has been put into SPIs for this. We haven't yet made the switch to GRPC at Square, but we do have service discovery integration and client-side load balancing in our current protobuf-based RPC system. And they're provided via a set of interfaces that an SPI can implement (we have three implementations internally: one for statically defining service endpoints in config files, one for discovering endpoints via DNS SRV records, and then our most sophisticated one that uses Zookeeper to store service information and traffic shaping policies.)

I've dug through the GRPC APIs for Java a good bit and have been looking at how to layer in APIs that are similar to what we already have here at Square (at least "the good parts"). I figured they'd make a reasonable strawman proposal for this.

I've started scratching this out in a Gist and was curious to either to get input or see if this is useful for Googlers or other GRPC contributors that might already be looking into this: https://gist.github.com/jhump/ddb565e2db61ac219857. I personally mainly work in Java, but at Square we have an interest in this sort of support for Go and Ruby, too.

The current approach in the gist favors simple, general types (map-like APIs with typed keys for endpoint metadata, simple strings for service names) over generic types and type parameters. But that's a detail that I've been flip-flopping about. Instead of these "weak" types, the SPI interfaces could be parameterized, so implementations can plug in their own structured types to represent things like names (or, more generally, service discovery queries) and endpoint metadata.

(Feel free to ignore the stuff at the bottom of the gist. It was mostly riffing on ideas for layering in other things like reconnection and retry policies. These are concerns that are currently tightly coupled in the core of our internal RPC client implementation that would need to be feathered into a GRPC client differently, like via interceptors.)

----

Josh Humphries

Manager, Shared Systems  |  Platform Engineering

Atlanta, GA  |  678-400-4867

Square (www.squareup.com)

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b6db6019-50e4-4e7d-9421-dd522ea54541%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[mic...@improbable.io]

Josh, have you made any progress in client-side load balancing for gRPC (Go and Java) at Square?

We're currently exploring doing that with DNS SRV, but it seems that the grpc-go datastructures (ClientConn) are not easily extensible to facilitate a `LbClientConn`.

[Josh Humphries]

Hey, Michael,

To date, we only have internal docs about how it will work in Java, but not yet in Go (or Ruby, which we'll also need).

Most of those docs describe how we will adapt our existing capabilities (service discovery, client-side load balancing, and fault tolerance via fail-over / retry strategies) to GRPC. Most of that investigation has so far centered on the interfaces in the Java client implementation. But we are starting on the others now and plan to have something by the end of this quarter.

We have these capabilities already built internally, but built on top of a home-grown RPC mechanism that resembles GRPC (based on protobufs, built and maintained by Xooglers that were familiar with Stubby). Our plan (as of today) is to port everything to GRPC over the next two quarters.

----

Josh Humphries

Manager, Shared Systems  |  Platform Engineering

Atlanta, GA  |  678-400-4867

Square (www.squareup.com)

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b08ed1be-e4e0-4b35-b2fa-f28a1e9b4512%40googlegroups.com.

[Jiri Jetmar]

Hi,

we are actually considering to port our RPC API from LinkedIn Rest.li to gRPC. There are many different reasons for it, but one of the primary cause is the non-existing
community for Rest.li. Rest.li is for now more mature in terms of production readiness, that includes also a service discovery.

So from my side +1 for a service discovery.

Thank you.

Cheers,
Jiri