Fork me on GitHub

Internals

Moving pieces

Octoparts is composed of the following components:

  • Web app built on the Playframework
    • Wraps calls to registered endpoints in Hystrix commands to guarantee resilience and responsiveness
    • Caches endpoint configuration metadata and endpoint results to either EhCached or Memcached
  • Hystrix dashboard for Hystrix stream visualisation, deployed in Tomcat
    • If multiple Octoparts nodes are used, Turbine is required for aggregating the Hystrix streams into a single stream to be consumed by the dashboard
  • Kibana for visualising log entry data
    • Log data from each Octoparts node is collected and aggregated via fluentd and stored in Elasticsearch
  • Alert Mailer that queries the aforementioned Elasticsearch datastore to monitor errors rates and, if errors surpass configured thresholds, sends alert emails

Process flow

When a POST request is sent to the endpoints invocation API (TODO: point to deployed Octoparts swagger), it goes through the following process:

  1. The request body is parsed into a JSON object.
  2. The JSON object is deserialised into an AggregateRequest object.
  3. The AggregateRequest is processed:
    1. The RequestMeta for the request is extracted to identify common shareable data and to ensure we process the request within the requested timeout duration.
    2. The PartRequests contained inside are processed asynchronously in parallel:
      1. Find the configured endpoint data (HTTP address to hit, parameters, cache) that matches the partId of the PartRequest. If none can be found, return an error for this particular PartRequest explaining that the partId provided is not supported.
      2. If there is a suitable cached PartResponse for the PartRequest (i.e. one that matches all the parameters and is not stale according to the corresponding endpoint configuration; see Caching for more details), return it.
      3. If there isn’t a suitable cached response, wrap an HTTP request to the backend endpoint in a Hystrix Command with the proper thread pool and invoke it. Using the response from the command, generate and cache a PartResponse.
  4. All the PartResponses are gathered into a single AggregateResponse object. Note: PartRequests that take longer than the default or requested timeout duration to process are mapped to a PartResponse with a timeout error (for more details, see Timeouts)
  5. The AggregateResponse is serialised into a JSON object
  6. The JSON object is sent as a string in the body of the HTTP response

Next: Read about Runtime Info