Phantom architecture

This page describes the motivation for creating Phantom. It details architecture principles, system design and technologies used in building Phantom. Key APIs for extensibility are also discussed here.

Motivation for Phantom

The primary motivation for building Phantom is to improve availability of applications(say a web-site) that accesses a number of upstream services in a distributed SOA. Phantom aims to shield applications from latent services and support alternative execution when failures occur. Developers continue to build applications and services as they do today with Phantom providing most of the infrastructure required. This blog post is a detailed discussion on the topic.

Design Principles

The Phantom closely resembles a Reverse Proxy in functionality. Additionally, it also provides an API and execution environment for highly localized business logic that is significant enough for it to qualify as an independent service. Design principles for Phantom RPC system:

• Prevent cascading failures – Fail fast and Recover quickly
• Provide Reasonable fallbacks around failures – the exact behavior can be service specific
• Support for multiple protocols and codecs in order to enable transparent proxying – Unix Domain Sockets, TCP/IP and Http, Thrift
• High performance runtime with low overhead – ability for a single local instance to handle hundreds of millions of API/Service calls per day

System Design

The following infographic highlights layers, key technologies and component groups in the Phantom system design:

The layer abstraction in the design helps to:

• Support incoming requests using a number of protocols and transports. New ones (say UDP) may be added as needed. Mixing different incoming(e.g Http) and outgoing (e.g. Thrift) transports are also supported.
• Create protocol specific codecs – e.g. Http, Thrift. Adding a new Thrift proxy end-point requires only configuration edits, no code change needed.
• Automatic wrapping of API calls with Hystrix commands with reasonable defaults for Thread/Semaphore isolation and Thread pools. Users of Phantom are not required to program to the Hystrix API and focus on implementing service calls and fallback behavior. Fallback behavior is influenced by configured parameters(timeouts, thread pool size) and real time statistics comprising latent requests, thread-pool rejections and failure counts (see Hystrix’s support for this : How Hystrix works)
• Define an API layer for calling services. This is optional and promotes request-response data driven interfaces.

Phantom technology stack

Phantom is inspired by Twitter Finagle and leverages capabilities from the following technologies:

• Netty - Used to implement socket listeners that handle incoming proxy requests
• Unix Domain Sockets - Highly efficient socket library suited for high volume IPC
• Netflix Hystrix - Resilience and Fault tolerance framework that supports multiple levels of call isolation, fallback and monitoring.
• Trooper - Library of extensions and utilities over Spring that provides Bootstrapping, classpath & configpath scanning, Component API Lifecycle Management.

Phantom modules

The Maven dependencies page lists the various modules of Phantom along-with a brief description of the contained implementation. You may re-visit the page to understand how the design layers and component grouping described in this page map to implementation modules.

Extensibility

Phantom and the technology stack it leverages has reasonable API and configurability which enable developers to create new proxy implementations. The extension mechanisms include:

• Socket Listeners - These are implemented either as regular Java I/O socket listeners (or) Netty Bootstrap, and supporting classes. Phantom abstracts some of this behavior in API and implementations like : NetworkServer , UDSOIOServer, UDSNettyServer , TCPNettyServer
• Netty Channel Handlers - Transport and Protocol specific Netty ChannelBuffer, ChannelHandler and Decoder implementations. See : ThriftNettyChannelBuffer , HttpChannelHandler , ThriftChannelHandler, ThriftBufferDecoder
• Proxy Handler API - Provides ability to process data received from the Socket listeners and after protocol/transport specific codecs have been applied via the Netty Channel Handlers. See : AbstractHandler , TaskHandler , HystrixTaskHandler , HttpProxy , ThriftProxy
• Declarative, Dependency-Injection driven deployments of proxies - Convention-over-configuration approach of defining Socket Listeners, Channel handler pipelines and Proxy handlers as beans in files by name : spring-proxy-listener-config.xml and spring-proxy-handler-config.xml. See : Listener configuration file , Handler configuration file