Draft:Nameko(Python framework)

Nameko' is a microservices framework for the Python programming language. Tools and patterns are given to help developers build services that communicate with each other, perform concurrent operations, and scale when necessary. The framework takes care of all the boilerplate for a microservice architecture so developers can focus on the actual business logic.

Overview

Nameko services are usually Python classes. Dependency injection, a design pattern in which a component's dependencies are not created by the component itself but are instead passed in, is used by the framework. Methods within these services are exposed through special "entrypoints," which are Python decorators that bind service methods to underlying transport protocols. For example, an `@rpc` decorator allows a method to be called via RPC, whereas an `@http` decorator allows a method to be called through an HTTP request.

Nameko relies on the eventlet for its concurrency model so that its services can process more satisfying concurrent requests. Under default instalment, Nameko uses AMQP as the primitive messaging paradigm for RPC and event notification with RabbitMQ as the message broker.

Key Features

Nameko does facilitate several functions relevant to microservice development:

• Service Communication: It offers both Remote Procedure Calls (RPC) for direct synchronous communication between services, and an event-based asynchronous (publish-subscribe) mechanism for broadcasting messages.
• Scalability: Nameko is designed to allow multiple instances of a service to run concurrently. The incoming requests can be distributed by the message broker to instances, allowing for horizontal scaling.
• Extensibility: The framework supports custom extensions. By creating their own dependencies or entrypoints, developers can use their own transport protocols, talk to a variety of databases, or communicate with other external systems.
• Testing Utilities: Nameko construes services with supporting tools and fixtures to assist with unit and integration tests. This enables testing the logic behind the service in isolation and testing the interaction between services.

Architecture Considerations

In a Nameko-based application, services would mostly be run as independent processes. Communication such as an RPC from one service to another might be routed through a central message broker. This decouples services, in the sense that they do not require to have direct knowledge of each other's network location, and can contribute toward a resilient system if a service instance goes down.

Example Service Structure

The following illustrates a basic Nameko service:

from nameko.rpc import rpc

class ExampleService:
    name = "example_service"
    @rpc
    def process_data(self, data_payload):
        result = f"Processed: {data_payload}"
        return result

To run this service, one would typically use the Nameko command-line interface. Other services could then make RPC calls to the `process_data` method of `example_service`.

See also

• Microservices
• Python (programming language)
• RabbitMQ
• Advanced Message Queuing Protocol