1599d717af
One disadvantage of using TTL based health check is the high network traffic between Consul agent (either between servers, or between server and client). In order for the services considered alive by Consul, microservices must send an update TTL to Consul every n seconds (currently 30 seconds). Here is the explanation about TTL check from Consul documentation [1] Time to Live (TTL) - These checks retain their last known state for a given TTL. The state of the check must be updated periodically over the HTTP interface. If an external system fails to update the status within a given TTL, the check is set to the failed state. This mechanism, conceptually similar to a dead man's switch, relies on the application to directly report its health. For example, a healthy app can periodically PUT a status update to the HTTP endpoint; if the app fails, the TTL will expire and the health check enters a critical state. The endpoints used to update health information for a given check are the pass endpoint and the fail endpoint. TTL checks also persist their last known status to disk. This allows the Consul agent to restore the last known status of the check across restarts. Persisted check status is valid through the end of the TTL from the time of the last check. Hint: TTL checks also persist their last known status to disk. This allows the Consul agent to restore the last known status of the check across restarts. When microservices update the TTL, Consul will write to disk. Writing to disk means all other slaves need to replicate it, which means master need to inform other standby Consul to pull the new catalog. Hence, the increased traffic. More information about this issue can be viewed at Consul mailing list [2]. [1] https://www.consul.io/docs/agent/checks.html [2] https://groups.google.com/forum/#!topic/consul-tool/84h7qmCCpjg |
||
---|---|---|
broker | ||
client | ||
cmd | ||
codec | ||
errors | ||
metadata | ||
registry | ||
selector | ||
server | ||
transport | ||
.travis.yml | ||
function_test.go | ||
function.go | ||
go-micro.go | ||
go-micro.png | ||
LICENSE | ||
options.go | ||
publisher.go | ||
README.md | ||
service_test.go | ||
service.go | ||
wrapper_test.go | ||
wrapper.go |
Go Micro
Go Micro is a pluggable RPC framework for distributed systems development.
The Micro philosophy is sane defaults with a pluggable architecture. We provide defaults to get you started quickly but everything can be easily swapped out. It comes with built in support for {json,proto}-rpc encoding, consul or multicast dns for service discovery, http for communication and random hashed client side load balancing.
Everything in go-micro is pluggable. You can find and contribute to plugins at github.com/micro/go-plugins.
Follow us on Twitter or join the Slack community.
Features
Go Micro abstracts away the details of distributed systems. Here are the main features.
- Service Discovery - Automatic service registration and name resolution
- Load Balancing - Client side load balancing built on discovery
- Sync Comms - RPC based communication with support for bidirectional streaming
- Async Comms - Native PubSub messaging built in for event driven architectures
- Message Encoding - Dynamic encoding based on content-type with protobuf and json out of the box
- Service Interface - All features are wrapped up in a simple high level interface
Go Micro supports both the Service and Function programming models. Read on to learn more.
Docs
For more detailed information on the architecture, installation and use of go-micro checkout the docs.
Learn By Example
An example service can be found in examples/service and function in examples/function.
The examples directory contains examples for using things such as middleware/wrappers, selector filters, pub/sub, grpc, plugins and much more. For the complete greeter example look at examples/greeter. Other examples can be found throughout the GitHub repository.
Watch the Golang UK Conf 2016 video for a high level overview.
Getting started
Install Protobuf
Protobuf is required for code generation
You'll need to install:
Service Discovery
Service discovery is used to resolve service names to addresses.
Consul
Consul is used as the default service discovery system.
Discovery is pluggable. Find plugins for etcd, kubernetes, zookeeper and more in the micro/go-plugins repo.
Multicast DNS
Multicast DNS is a built in service discovery plugin for a zero dependency configuration.
Pass --registry=mdns
to any command or the enviroment variable MICRO_REGISTRY=mdns
MICRO_REGISTRY=mdns go run main.go
Writing a service
This is a simple greeter RPC service example
Find this example at examples/service.
Create service proto
One of the key requirements of microservices is strongly defined interfaces. Micro uses protobuf to achieve this.
Here we define the Greeter handler with the method Hello. It takes a HelloRequest and HelloResponse both with one string arguments.
syntax = "proto3";
service Greeter {
rpc Hello(HelloRequest) returns (HelloResponse) {}
}
message HelloRequest {
string name = 1;
}
message HelloResponse {
string greeting = 2;
}
Generate the proto
After writing the proto definition we must compile it using protoc with the micro plugin.
protoc --proto_path=$GOPATH/src:. --micro_out=. --go_out=. path/to/greeter.proto
Write the service
Below is the code for the greeter service.
It does the following:
- Implements the interface defined for the Greeter handler
- Initialises a micro.Service
- Registers the Greeter handler
- Runs the service
package main
import (
"context"
"fmt"
micro "github.com/micro/go-micro"
proto "github.com/micro/examples/service/proto"
)
type Greeter struct{}
func (g *Greeter) Hello(ctx context.Context, req *proto.HelloRequest, rsp *proto.HelloResponse) error {
rsp.Greeting = "Hello " + req.Name
return nil
}
func main() {
// Create a new service. Optionally include some options here.
service := micro.NewService(
micro.Name("greeter"),
)
// Init will parse the command line flags.
service.Init()
// Register handler
proto.RegisterGreeterHandler(service.Server(), new(Greeter))
// Run the server
if err := service.Run(); err != nil {
fmt.Println(err)
}
}
Run service
go run examples/service/main.go
Output
2016/03/14 10:59:14 Listening on [::]:50137
2016/03/14 10:59:14 Broker Listening on [::]:50138
2016/03/14 10:59:14 Registering node: greeter-ca62b017-e9d3-11e5-9bbb-68a86d0d36b6
Define a client
Below is the client code to query the greeter service.
The generated proto includes a greeter client to reduce boilerplate code.
package main
import (
"context"
"fmt"
micro "github.com/micro/go-micro"
proto "github.com/micro/examples/service/proto"
)
func main() {
// Create a new service. Optionally include some options here.
service := micro.NewService(micro.Name("greeter.client"))
service.Init()
// Create new greeter client
greeter := proto.NewGreeterClient("greeter", service.Client())
// Call the greeter
rsp, err := greeter.Hello(context.TODO(), &proto.HelloRequest{Name: "John"})
if err != nil {
fmt.Println(err)
}
// Print response
fmt.Println(rsp.Greeting)
}
Run the client
go run client.go
Output
Hello John
Writing a Function
Go Micro includes the Function programming model.
A Function is a one time executing Service which exits after completing a request.
Defining a Function
package main
import (
"context"
proto "github.com/micro/examples/function/proto"
"github.com/micro/go-micro"
)
type Greeter struct{}
func (g *Greeter) Hello(ctx context.Context, req *proto.HelloRequest, rsp *proto.HelloResponse) error {
rsp.Greeting = "Hello " + req.Name
return nil
}
func main() {
// create a new function
fnc := micro.NewFunction(
micro.Name("greeter"),
)
// init the command line
fnc.Init()
// register a handler
fnc.Handle(new(Greeter))
// run the function
fnc.Run()
}
It's that simple.
Plugins
By default go-micro only provides a few implementation of each interface at the core but it's completely pluggable. There's already dozens of plugins which are available at github.com/micro/go-plugins. Contributions are welcome!
Build with plugins
If you want to integrate plugins simply link them in a separate file and rebuild
Create a plugins.go file
import (
// etcd v3 registry
_ "github.com/micro/go-plugins/registry/etcdv3"
// nats transport
_ "github.com/micro/go-plugins/transport/nats"
// kafka broker
_ "github.com/micro/go-plugins/broker/kafka"
)
Build binary
// For local use
go build -i -o service ./main.go ./plugins.go
Flag usage of plugins
service --registry=etcdv3 --transport=nats --broker=kafka
Plugin as option
Alternatively you can set the plugin as an option to a service
import (
"github.com/micro/go-micro"
// etcd v3 registry
"github.com/micro/go-plugins/registry/etcdv3"
// nats transport
"github.com/micro/go-plugins/transport/nats"
// kafka broker
"github.com/micro/go-plugins/broker/kafka"
)
func main() {
registry := etcdv3.NewRegistry()
broker := kafka.NewBroker()
transport := nats.NewTransport()
service := micro.NewService(
micro.Name("greeter"),
micro.Registry(registry),
micro.Broker(broker),
micro.Transport(transport),
)
service.Init()
service.Run()
}
Write plugins
Plugins are a concept built on Go's interface. Each package maintains a high level interface abstraction. Simply implement the interface and pass it in as an option to the service.
The service discovery interface is called Registry. Anything which implements this interface can be used as a registry. The same applies to the other packages.
type Registry interface {
Register(*Service, ...RegisterOption) error
Deregister(*Service) error
GetService(string) ([]*Service, error)
ListServices() ([]*Service, error)
Watch() (Watcher, error)
String() string
}
Browse go-plugins to get a better idea of implementation details.
Wrappers
Go-micro includes the notion of middleware as wrappers. The client or handlers can be wrapped using the decorator pattern.
Handler
Here's an example service handler wrapper which logs the incoming request
// implements the server.HandlerWrapper
func logWrapper(fn server.HandlerFunc) server.HandlerFunc {
return func(ctx context.Context, req server.Request, rsp interface{}) error {
fmt.Printf("[%v] server request: %s", time.Now(), req.Method())
return fn(ctx, req, rsp)
}
}
It can be initialised when creating the service
service := micro.NewService(
micro.Name("greeter"),
// wrap the handler
micro.WrapHandler(logWrapper),
)
Client
Here's an example of a client wrapper which logs requests made
type logWrapper struct {
client.Client
}
func (l *logWrapper) Call(ctx context.Context, req client.Request, rsp interface{}, opts ...client.CallOption) error {
fmt.Printf("[wrapper] client request to service: %s method: %s\n", req.Service(), req.Method())
return l.Client.Call(ctx, req, rsp)
}
// implements client.Wrapper as logWrapper
func logWrap(c client.Client) client.Client {
return &logWrapper{c}
}
It can be initialised when creating the service
service := micro.NewService(
micro.Name("greeter"),
// wrap the client
micro.WrapClient(logWrap),
)
Other Languages
Check out ja-micro to write services in Java
Sponsors
Open source development of Micro is sponsored by Sixt