Go-micro: Consul service mesh

Created on 24 Jul 2018  路  2Comments  路  Source: asim/go-micro

I'm just wondering if there any thoughts/plans to integrate with Consul's new service mesh (released in Consul v1.2)?

As an alternative, have you got any recommendations on how a permission layer could be integrated with Micro so service X could be given permission to call method Y on service Z?

Most helpful comment

There is plan to integrate consul connect, it's just unclear what the best path forward is right now.

Consul connect requires configuration in 3 ways.

  1. A service must register with consul specifying that it's a connect enabled application
  2. A service must use the connect api to enable mutual tls authentication
  3. A service must use the connect api to retrieve other connect services

I believe given service mesh is becoming a central technology we must define an abstraction for it. While service mesh is supposed to operate transparently, I think only the data plane offers this capability. In the event that we need to integrate with a control plane something must be specified.

I propose a new abstraction or potential option "proxy" whereby we proxy a number of pieces of functionality through the specified system. In the case of connect we'd enable this by the flag MICRO_PROXY=connect or flag --proxy=connect.

I don't believe this is a package level definition in go-micro because I think go-micro itself has a focus on solving these distributed systems problems as a library. I do believe this is a higher order function that we could define at the top-level alongside Service and Function.

Interested to get feedback on this.

// Proxy defines a type which configures go-micro to use service mesh
type Proxy interface {
        // Creates a new proxied micro service
        Service(opts ...Option) Service
        // name of proxy e.g micro, connect, envoy
        String() string
}

All 2 comments

There is plan to integrate consul connect, it's just unclear what the best path forward is right now.

Consul connect requires configuration in 3 ways.

  1. A service must register with consul specifying that it's a connect enabled application
  2. A service must use the connect api to enable mutual tls authentication
  3. A service must use the connect api to retrieve other connect services

I believe given service mesh is becoming a central technology we must define an abstraction for it. While service mesh is supposed to operate transparently, I think only the data plane offers this capability. In the event that we need to integrate with a control plane something must be specified.

I propose a new abstraction or potential option "proxy" whereby we proxy a number of pieces of functionality through the specified system. In the case of connect we'd enable this by the flag MICRO_PROXY=connect or flag --proxy=connect.

I don't believe this is a package level definition in go-micro because I think go-micro itself has a focus on solving these distributed systems problems as a library. I do believe this is a higher order function that we could define at the top-level alongside Service and Function.

Interested to get feedback on this.

// Proxy defines a type which configures go-micro to use service mesh
type Proxy interface {
        // Creates a new proxied micro service
        Service(opts ...Option) Service
        // name of proxy e.g micro, connect, envoy
        String() string
}

Something in the pipeline https://github.com/micro/go-micro/pull/295

Closing the issue for now

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Wintereise picture Wintereise  路  6Comments

5teven picture 5teven  路  5Comments

guanwenbogit picture guanwenbogit  路  5Comments

jnvillar picture jnvillar  路  9Comments

chmorgan picture chmorgan  路  6Comments