Initial attempt at adding support for gRPC

[dancannon]

This probably should not be merged just yet since I removed quite a few features from go-micro (healthchecks and the RPC endpoint) to get this working. However I think gRPC is a perfect fit for go-micro and I wanted to get some discussion started on how the implementation might work.

The packages in the examples directory is probably the best place to see how the new changes work and I am aware that the API is a little strange but it has a couple of advantages:

• Remains flexible
• Doesnt use reflection
• Keeps the ability to use add tracing, monitoring for requests

[asim]

Oh cool. Was looking at gRPC the other day to see how it could be integrated. Agree that it could be used as one of the core rpc mechanisms within go-micro. My approach was going to be slightly different to maintain the existing rpc code as well. One thing I'm not entirely sold on is the way in which handlers are used BUT this branch and PR can be a good way of testing and see how it all works and what improvements it can bring to go-micro. Also perhaps making it easier to implement the wrapper code in other languages.

Thoughts about other transports and how they can also be used? Been thinking about RabbitMQ, NATS, Pub/Sub, etc. Not sure whether to actually have Pub/Sub as part of the core.

Thanks for doing this!

[dancannon]

Yep I am fairly this PR is NOT the way the feature should be implemented :P I mostly wanted to experiment with gRPC and see how it might work. (Also I think I was wrong about tracing working with this PR, there is currently no way to implement middleware on the server handlers as far as I can see)

I am still completely unsure how transports would even work, from what I have seen different transports do not seem to have a common API although this might be because I am looking at the Go client libs and not the underlying protocols.

[asim]

I think there would have to be a certain amount of introspection before handing off to the handlers. The way go-micro is currently implemented it might be possible. RPC messages are normally in an envelope that has the method name being called.

As for the transport. Just about finding common constructs between various mechanisms. Read/Write, Encode/Decode, etc. Perhaps even just encapsulating at the higher level with Request/Response and handing off all the hard work to the transport layer. Definitely something I want to investigate so that transport can be changed on the command line with just --transport=http/nats/rabbitmq, etc.

Many things to do. Not to mention the api https://github.com/asim/micro-api, a shell, and everything else.