gokit

gokit is a working name for a distributed programming toolkit to serve the needs of the modern service-oriented enterprise.

• Mailing list: go-kit
• IRC: Freenode #gokit

Motivation

See the motivating blog post and the video of the talk.

Goals

• Operate in a heterogeneous SOA — expect to interact with mostly non-gokit services
• RPC as the messaging pattern
• Pluggable serialization and transport — not just JSON over HTTP
• Zipkin-compatible request tracing

Non-goals

• Supporting messaging patterns other than RPC — pub/sub, CQRS, etc.
• Having opinions on deployment, orchestration, process supervision, etc.
• Having opinions on configuration passing, i.e. flags, env vars, files, etc.

Component status

• API stability — RFC complete, adopted
• package metrics — RFC complete, first draft complete
• package server — RFC complete, prototyping
• package transport — RFC pending, prototyping
• package log — RFC complete, prototyping
• package client — RFC pending
• Service discovery — RFC pending
• Request tracing — RFC pending

Contributing

At this stage, we're still developing the initial drafts of all of the packages, using an RFC workflow. Before submitting major changes, please write to the mailing list to register your interest, and check the open issues and pull requests for existing discussions.

Dependency management

Users who import gokit into their package main are responsible to organize and maintain all of their dependencies to ensure code compatibility and build reproducibility. Gokit makes no direct use of dependency management tools like Godep.

We will use a variety of continuous integration providers to find and fix compatibility problems as soon as they occur.

API stability policy

The gokit project depends on code maintained by others. This includes the Go standard library and sub-repositories and other external libraries. The Go language and standard library provide stability guarantees, but the other external libraries typically do not. The API Stability RFC proposes a standard policy for package authors to advertise API stability. The gokit project prefers to depend on code that abides the API stability policy.

Related projects

Projects with a ★ have had particular influence on gokit's design.

Service frameworks

• go-micro, a microservices client/server library ★
• gocircuit, dynamic cloud orchestration
• gotalk, async peer communication protocol & library
• Kite, a micro-service framework

Individual components

• afex/hystrix-go, client-side latency and fault tolerance library
• armon/go-metrics, library for exporting performance and runtime metrics to external metrics systems
• codahale/lunk, structured logging in the style of Google's Dapper or Twitter's Zipkin
• eapache/go-resiliency, resiliency patterns
• FogCreek/logging, a tagged style of logging
• grpc/grpc-go, HTTP/2 based RPC
• inconshreveable/log15, simple, powerful logging for Go
• mailgun/vulcand, prorammatic load balancer backed by etcd
• mattheath/phosphor, distributed system tracing
• pivotal-golang/lager, an opinionated logging library
• rubyist/circuitbreaker, circuit breaker library
• Sirupsen/logrus, structured, pluggable logging for Go ★
• sourcegraph/appdash, application tracing system based on Google's Dapper
• spacemonkeygo/monitor, data collection, monitoring, instrumentation, and Zipkin client library
• streadway/handy, net/http handler filters
• vitess/rpcplus, package rpc + context.Context
• gdamore/mangos, nanomsg implementation in pure Go

Web frameworks

• Beego
• Gin
• Goji
• Gorilla
• Martini
• Negroni
• Revel

Additional reading

• Architecting for the Cloud — Netflix
• Dapper, a Large-Scale Distributed Systems Tracing Infrastructure — Google
• Your Server as a Function (PDF) — Twitter