UberFx Service Framework

Status

Pre-ALPHA. API Changes are highly likely.

Abstract

This framework is a flexible, modularized basis for building robust and performant services at Uber with the minimum amount of developer code.

Examples

To get a feel for what an UberFx service looks like, see our examples.

Service Model

A service is a container for a set of modules and controls their lifecycle. A service can have any number of modules, each responsible for a specific type of functionality, such as a Kafka message ingestion, exposing an HTTP server, or a set of RPC service endpoints.

The core service is responsible for loading basic configuration and starting and stopping a set of these modules. Each module gets a reference to the service to access standard values such as the service name or basic configuration.

Core Packages

The top-level packages contain the nuts and bolts useful for a fully-fledged service. That said, none (except for service) requires an instance or even the idea of a service. You can use the packages independently.

If, for example, you only want use the configuration logic from UberFx, you can import go.uber.org/fx/config and use it in a standalone CLI app.

The service package contains logic specific to a running service. config is separate from service.

Modules

A modules is a pluggable component that provides an encapsulated set of functionality, and all modules are managed by the service.

Implemented modules:

HTTP server
TChannel server

Planned modules:

Kafka ingester
Delayed jobs

Module Configuration

You give your modules named keys for the purpose of looking up their configuration. This naming is arbitrary and only needs to be unique across modules. We do this because it's possible for a service to have multiple modules of the same type, such as multiple Kafka ingesters.

modules:
  yarpc:
    bind: :28941
    advertiseName: kvserver
  http:
    port: 8080
    timeout: 60s

In this example, a module named: "rpc" would look up its advertise name as modules.rpc.advertiseName.

Metrics

UberFx exposes a simple, consistent way to track metrics and is built on top of Tally.

Internally, this uses a pluggable mechanism for reporting these values, so they can be reported to M3, logging, etc., at the service owner's discretion. By default, the metrics are not reported (using a tally.NoopScope).

Configuration

UberFx introduces a simplified configuration model that provides a consistent interface to configuration from pluggable configuration sources. This interface defines methods for accessing values directly or into strongly typed structs.

Compatibility

UberFx is compatible with Go 1.7 and above.

License

MIT

yutongp/fx