Архитектурный дизайн агностического сервера протокола

Я хочу создать сервер, который сможет обрабатывать протоколы TCP, HTTP и Websockets (а не одновременно) и иметь возможность работать одинаково независимо от того, какой протокол он будет использовать во время выполнения.Архитектурный дизайн агностического сервера протокола

В принципе, я не отношусь к каждому типу запроса по-разному, но каким-то образом создаю объект общего запроса и общий объект ответа.

Сообщения, полученные через TCP и Websockets, будут иметь структуру HTTP-запроса.

Все запросы/сообщения будут REST-like.

Какое архитектурное проектирование я должен использовать, чтобы не дублировать маршрутизацию/обработку для каждого протокола?

источник

2016-06-02 Donovan

Это хорошо. Каков твой вопрос? В любом случае вы не должны привязывать свою бизнес-логику к определенному сетевому протоколу. Взгляните на то, как Microsoft WCF делает это: используя «привязки». Связывание переводит «сообщение» в формат, специфичный для протокола. – CodeCaster

Что касается вашего редактирования, можете ли вы подробнее рассказать о «маршрутизации/обработке»? – CodeCaster

@CodeCaster, так как все запросы/сообщения будут «выглядеть» одинаково, я хочу использовать один и тот же механизм маршрутизации, выполнить некоторую обработку, а затем дать ответ. – Donovan

Любой TCP-сервер может быть также HTTP-сервером. Если вы проверите https://docs.python.org/2/library/socketserver.html и https://docs.python.org/2/library/basehttpserver.html, вы увидите, что HTTPServer расширяет TCPServer.

После того, как запрос поступает на ваш TCP-сервер, просто выясните, является ли он «HTTP-запросом» (это сложная часть) и перенаправляет его на HTTP-маршрутизатор (на любой приемлемой основе MVC на любом языке есть один) ,

Если мы рассмотрим запрос TCP и HTTP-запрос, вы можете преобразовать запрос TCP в HTTP-запрос и перенаправить его на тот же маршрутизатор. Во всяком случае, этот подход может замедлить всю обработку.

Кроме того, если у вас уже есть только клиенты TCP &, тогда я буду хранить их отдельно из-за того, что HTTP вводит некоторые накладные расходы. Таким образом, другой подход заключается в том, чтобы поддерживать сервер и маршрутизатор отдельно по протоколу и использовать только классы бизнес-логики (Модели) в качестве общего уровня.

TCP Server --> FC -->TCP Router --> TCPController(Controller) --> TCP Response 
             | 
             \/ 
             Model 
             /\ 
             | 
HTTP Server --> FC --> HTTP Router --> HTTPController(Controller) --> HTTP Response

* FC = Front Controller

Используя этот подход, вы можете заменить HTTP-сервер в любое время с другим, и это может принести множество преимуществ: использовать хорошо известный веб-сервер (например Nginx) или пользовательский, написанный вами на разных языках.

источник

2016-06-02 12:54:36

Архитектурный дизайн агностического сервера протокола

ответ

Смежные вопросы