rfc: server: SLAs + SLIs; star some sections
Peter Bourgon
9 years ago
| 2 | 2 | --- |
| 3 | 3 | |
| 4 | 4 | RFC: 000 |
| 5 | ||
| 6 | 5 | Author: Matt Heath <matt@mattheath.com> |
| 7 | ||
| 8 | Status: Draft | |
| 6 | Status: Accepted | |
| 9 | 7 | |
| 10 | 8 | --- |
| 11 | 9 | |
| 13 | 11 | |
| 14 | 12 | [http://peter.bourgon.org/go-kit/#package-server](http://peter.bourgon.org/go-kit/#package-server) |
| 15 | 13 | |
| 16 | Package server is probably the biggest and most important component of the toolkit. Ideally, we should be able to write our services as implementations of normal, nominal Go interfaces, and delegate integration with the environment to the server package. The package should encode and enforce conventions for server-side concerns, like health checks, system-wide request tracing, connection management, backpressure and throttling, and so on. For each of those topics, it should provide interfaces for different, pluggable strategies. It should integrate with service discovery, and work equally well over multiple transports. Considerable prior art exists in the form of Finagle, Karyon (Netflixs application service library), and likely many more. | |
| 14 | Package server is probably the biggest and most important component of the toolkit. Ideally, we should be able to write our services as implementations of normal, nominal Go interfaces, and delegate integration with the environment to the server package. The package should encode and enforce conventions for server-side concerns, like health checks, system-wide request tracing, connection management, backpressure and throttling, and so on. For each of those topics, it should provide interfaces for different, pluggable strategies. It should integrate with service discovery, and work equally well over multiple transports. Considerable prior art exists in the form of Finagle, Karyon (Netflix's application service library), and likely many more. | |
| 17 | 15 | |
| 18 | 16 | ## Scope |
| 17 | ||
| 18 | Sections with a ★ are considered particularly volatile, and may change significantly in the future. | |
| 19 | 19 | |
| 20 | 20 | ### Endpoints |
| 21 | 21 | |
| 38 | 38 | * Rate limit behaviour MAY range from minimum request intervals, to time based, or leaky bucket algorithms. |
| 39 | 39 | * A server MAY implement a pluggable throttle interface, allowing richer implementations - such as an implementation which shares information across instances of the service. |
| 40 | 40 | |
| 41 | ### SLAs | |
| 41 | ### SLAs & SLIs | |
| 42 | 42 | |
| 43 | * A server MAY report its SLA per endpoint to a discovery system, allowing clients to estimate response time. | |
| 43 | * A server MAY report its contractual SLA per endpoint to a discovery system, allowing clients to estimate response time. | |
| 44 | * A server MAY expose its actual SLI per endpoint, allowing third-parties to reason about healthiness. | |
| 44 | 45 | |
| 45 | ### Healthchecks | |
| 46 | ### Healthchecks ★ | |
| 46 | 47 | |
| 47 | 48 | * A server SHALL accept registration of healthchecks with a defined interface. |
| 48 | 49 | * A server MAY register default healthchecks to report the health of built in components of the server. |
| 65 | 66 | * A server SHALL receive and respond to requests via a Transport. |
| 66 | 67 | * The Transport mechanism SHALL be interchangeable, and satisfy a defined interface, however the mechanism of the transport is beyond the scope of this RFC. |
| 67 | 68 | |
| 68 | ### Codec | |
| 69 | ### Codec ★ | |
| 69 | 70 | |
| 70 | 71 | * A server SHALL encode and decode requests and responses via an interchangeable Codec. |
| 71 | 72 | * A server MAY support multiple encodings, and use the appropriate Codec as indicated by the transport. |
| 77 | 78 | |
| 78 | 79 | ## Further Reading |
| 79 | 80 | |
| 80 | [Your Server as a Function](http://monkey.org/~marius/funsrv.pdf) - Marius Eriksen | |
| 81 | ||
| 82 | [Finagle](https://twitter.github.io/finagle/) - Twitter | |
| 83 | ||
| 84 | [Karyon](https://github.com/Netflix/karyon) - Netflix | |
| 85 | ||
| 86 | [State of the Art in Microservices](https://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices) - Adrian Cockcroft⏎ | |
| 81 | * [Your Server as a Function](http://monkey.org/~marius/funsrv.pdf) - Marius Eriksen | |
| 82 | * [Finagle](https://twitter.github.io/finagle/) - Twitter | |
| 83 | * [Karyon](https://github.com/Netflix/karyon) - Netflix | |
| 84 | * [State of the Art in Microservices](https://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices) - Adrian Cockcroft | |