vulcand / predicate

Library for creating predicate mini-languages in Go

Vulcand

Vulcand is a programmatic extendable proxy for microservices and API management. It is inspired by Hystrix and powers Mailgun microservices infrastructure.

Focus and priorities

Vulcand is focused on microservices and API use-cases.

Features

• Uses etcd as a configuration backend.
• API and command line tool.
• Pluggable middlewares.
• Support for canary deployments, realtime metrics and resilience.

Project info

documentation	https://vulcand.github.io/
status	Used in production@Mailgun on moderate workloads. Under active development.
discussions	https://groups.google.com/d/forum/vulcan-proxy
roadmap	roadmap.md
build status

Opentracing Support

Vulcand has support for open tracing via the Jaeger client libraries. Users who wish to use tracing support should use the --enableJaegerTracing flag and must either run the Jaeger client listening on localhost:6831/udp or set the environment variables JAEGER_AGENT_HOST and JAEGER_AGENT_POST. (See the Jaeger client libraries for all available configuration environment variables.)

When enabled vulcand will create 2 spans: one span called vulcand which covers the entire downstream request and another span called middleware which only spans the processing of the middleware before the request is routed downstream.

Aliased Expressions

When running vulcand in a kubernetes DaemonSet vulcand needs to know requests from the local node can match Host("localhost") rules. This --aliases flag allows an author of a vulcand DaemonSet to tell vulcand the name of the node it's currently running on, such that vulcand correctly routes requests for Host("localhost"). The --aliases flag allows the user to pass in multiple aliases separated by commas.

Example

$ vulcand --aliases 'Host("localhost")=Host("192.168.1.1")'

predicate's Issues

GetFieldByTag consumes large amounts of resources

Calling trace.NotFound in every recursive branch of GetFieldByTag is very expensive.

Type Safety?

Hello mailgun! How's SFO doing? Super interesting project!

So I was thinking if it's feasible to add type safety check into this. Currently it parses the tokens, stores literals and function names, and then uses reflect to call the functions. What do you think about using different concrete function types (as opposed to unifying them with a single interface{})

So Functions would become a managed type (rather than map[string]interface{}) that has methods to attach different user-defined functions to it. To avoid reflection, this means multiple "attaching" methods need to be defined, for example:

func (f *Functions) AttachInt(name string, f func(int, int) int) error
func (f *Functions) AttachFloat(name string, f func(float64, float64) float64) error

When executing, rather than calling by reflect, it could first determine the actual function implementation to use based on literal types. Type conversion happens here: if a function is called with something like (int, float64), it would be automatically converted to (float64, float64) before calling the function. This removes the need to use reflection from both function and literal passing.

Internally in the Functions type, it would need to have references to different types, and keep track on which functions are attached and which are not. For example:

type Functions struct {
    functions map[string]*function
}
type function struct {
    funcInt  func(int, int) int
    funcSetInt bool
    funcFloat func(float64, float64) float64
    funcSetFloat bool
}

This way, you get the type safety check and reduce the reflection using.

However, it might be a bit too verbose for quick prototyping or whatever situations where people don't want to deal with all those stuff. So there could be an interface which is exactly like what's present now, and underlying handles all these automatically.

What do you think?

Add go.mod to support the Go module?