Топология брокера или топология посредника: выбор правильного подхода для вашей системы

В архитектурах распределенных систем существуют различные способы взаимодействия между компонентами. Двумя популярными подходами являются топология брокера и топология посредника. Каждый подход имеет свои преимущества и варианты использования. В этой статье мы рассмотрим обе топологии, обсудим их характеристики и предоставим примеры кода, иллюстрирующие их реализацию. К концу вы будете иметь четкое представление о том, когда использовать в вашей системе топологию брокера или топологию посредника.

Топология брокера.
Топология брокера соответствует шаблону публикации-подписки, при котором компоненты взаимодействуют через центральный брокер сообщений. Брокер выступает в роли посредника, получая сообщения от издателей и доставляя их подписчикам. Этот подход обеспечивает слабую связь между компонентами и обеспечивает асинхронную связь. Вот пример реализации топологии брокера с использованием брокера сообщений, такого как RabbitMQ, в Python:

# Publisher
import pika
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='my_queue')
message = 'Hello, subscribers!'
channel.basic_publish(exchange='', routing_key='my_queue', body=message)
print("Message sent")
connection.close()
# Subscriber
import pika
def callback(ch, method, properties, body):
    print("Received message:", body)
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='my_queue')
channel.basic_consume(queue='my_queue', on_message_callback=callback, auto_ack=True)
print("Waiting for messages...")
channel.start_consuming()

Топология посредника.
Топология посредника имеет структуру, подобную центральному концентратору, в которой компоненты взаимодействуют через посредника. Посредник действует как координатор между компонентами, облегчая их общение и обеспечивая соблюдение правил. Такой подход способствует лучшей инкапсуляции и уменьшению прямых зависимостей между компонентами. Вот пример реализации топологии посредника с использованием шаблона Mediator в C#:

// Mediator
public interface IMediator
{
    void Notify(Component sender, string message);
}
// Concrete Mediator
public class ConcreteMediator : IMediator
{
    private ComponentA componentA;
    private ComponentB componentB;
    public ConcreteMediator(ComponentA componentA, ComponentB componentB)
    {
        this.componentA = componentA;
        this.componentB = componentB;
    }
    public void Notify(Component sender, string message)
    {
        if (sender == componentA)
        {
            componentB.Receive(message);
        }
        else if (sender == componentB)
        {
            componentA.Receive(message);
        }
    }
}
// Components
public abstract class Component
{
    protected IMediator mediator;
    public Component(IMediator mediator)
    {
        this.mediator = mediator;
    }
    public abstract void Send(string message);
    public abstract void Receive(string message);
}
public class ComponentA : Component
{
    public ComponentA(IMediator mediator) : base(mediator)
    {
    }
    public override void Send(string message)
    {
        mediator.Notify(this, message);
    }
    public override void Receive(string message)
    {
        Console.WriteLine("Component A received: " + message);
    }
}
public class ComponentB : Component
{
    public ComponentB(IMediator mediator) : base(mediator)
    {
    }
    public override void Send(string message)
    {
        mediator.Notify(this, message);
    }
    public override void Receive(string message)
    {
        Console.WriteLine("Component B received: " + message);
    }
}
// Usage
var mediator = new ConcreteMediator(new ComponentA(mediator), new ComponentB(mediator));
mediator.componentA.Send("Hello, Component B!");
mediator.componentB.Send("Hi, Component A!");

Как топология брокера, так и топология посредника предлагают эффективные способы управления связью в распределенных системах. Выбор между ними зависит от конкретных требований и особенностей вашей системы. При принятии решения о том, какой подход использовать, учитывайте такие факторы, как желаемый уровень связанности, необходимость асинхронной связи и сложность взаимодействия системы. Понимая эти топологии и примеры их кода, вы сможете принять обоснованное решение о разработке надежной и масштабируемой распределенной системы.