定制 vrok/messenger-reply 二次开发

按需修改功能、优化性能、对接业务系统,提供一站式技术支持

邮箱:yvsm@zunyunkeji.com | QQ:316430983 | 微信:yvsm316

vrok/messenger-reply

Composer 安装命令:

composer require vrok/messenger-reply

包简介

Symfony messenger middleware & stamps to reply to messages

README 文档

README

This is a library to allow symfony/messenger to reply to messages with a result.
This is meant to be used in a setup with AMQP transport and two symfony instances talking to each other over the same broker: e.g. a web frontend and a microservice, where the frontend sends tasks to the service and requests a reply, for example a generated PDF file.

CI Status Coverage Status

Setup

Installation on both sides (You need the ReplyToStamp on the request side and the middleware + stamp on the receiving side): composer require vrok/messenger-reply

You need request and reply message classes that are equal on both sides, e.g. use a shared composer package:

namespace MyNamespace\Message;

class GeneratePdfMessage
{
    /**
     * @var string
     */
    private string $latex;

    public function __construct(string $latex)
    {
        $this->latex = $latex;
    }

    /**
     * @return string
     */
    public function getLatex(): string
    {
        return $this->latex;
    }
}

...

namespace MyNamespace\Message;

class PdfResultMessage
{
    private string $pdfContent;

    public function __construct(string $pdfContent)
    {
        $this->pdfContent = $pdfContent;
    }

    /**
     * @return string
     */
    public function getPdfContent(): string
    {
        return $this->pdfContent;
    }
}

Requesting side

Add a transport for the shared AMQP broker, routing to the input of the receiver (having the same exchange and queue name as the receivers input queue).

framework:
    messenger:
        transports:
            pdf-requests:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    exchange:
                        name: pdf-service
                        type: direct
                        default_publish_routing_key: input
                    queues:
                        input:
                            binding_keys: [input]
                retry_strategy:
                    max_retries: 3
                    # milliseconds delay
                    delay: 1000
                    # causes the delay to be higher before each retry
                    # e.g. 1 second delay, 2 seconds, 4 seconds
                    multiplier: 2
                    max_delay: 0

Add a transport for the shared AMQP broker, for receiving the replies (matching the exchange and queue name of the receivers output queue): We need separate transports as messenger:consume [transportname] consumes all messages in all queues for that transport.

framework:
    messenger:
        transports:
            pdf-results:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    exchange:
                        name: pdf-service
                        type: direct
                        default_publish_routing_key: output
                    queues:
                        input:
                            binding_keys: [output]
                retry_strategy:
                    max_retries: 3
                    # milliseconds delay
                    delay: 1000
                    # causes the delay to be higher before each retry
                    # e.g. 1 second delay, 2 seconds, 4 seconds
                    multiplier: 2
                    max_delay: 0

Route your requests to the shared transport/queue:

framework:
    messenger:
        routing:
            # e.g. 
            'MyNamespace\GeneratePdfMessage': pdf-requests

Replying side

Configure the middleware service:

services:
    Vrok\MessengerReply\ReplyMiddleware:
        tags:
            - { name: monolog.logger, channel: messenger }
        calls:
            - [setLogger, ['@logger']]

Enable the middleware on your message bus:
(We have to disable the default middleware and explicitly define the order as there is no priority option, just adding our service to the middleware-option would add it before send_middleware. See symfony/symfony#28568)

framework:
    messenger:
        buses:
            messenger.bus.default:
                default_middleware: false
                middleware:
                    - {id: 'add_bus_name_stamp_middleware', arguments: ['messenger.bus.default']}
                    - reject_redelivered_message_middleware
                    - dispatch_after_current_bus
                    - failed_message_processing_middleware
                    - send_message
                    - handle_message
                    - Vrok\MessengerReply\ReplyMiddleware

Configure an input transport where you send messages from the external applications, which are consumed by your worker(s). And an output transport where the replies are sent, optimally with one queue for each application sending requests, so the only consume the replies meant for them. We need separate transports as messenger:consume [transportname] consumes all messages in all queues for that transport.

framework:
    messenger:
        transports:
            input:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    exchange:
                        name: pdf-service
                        type: direct
                        default_publish_routing_key: input
                    queues:
                        input:
                            binding_keys: [input]
                retry_strategy:
                    max_retries: 3
                    # milliseconds delay
                    delay: 1000
                    # causes the delay to be higher before each retry
                    # e.g. 1 second delay, 2 seconds, 4 seconds
                    multiplier: 2
                    max_delay: 0

            output:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    exchange:
                        name: pdf-service
                        type: direct
                        default_publish_routing_key: output
                    queues:
                        output:
                            binding_keys: [output]
                        output_1:
                            binding_keys: [output_1]
                retry_strategy:
                    max_retries: 3
                    # milliseconds delay
                    delay: 1000
                    # causes the delay to be higher before each retry
                    # e.g. 1 second delay, 2 seconds, 4 seconds
                    multiplier: 2
                    max_delay: 0

All replies should be routed to the output transport:

framework:
    messenger:
        routing:
            # Route your messages to the transports
            '*': output

Usage

Dispatch the request message with the attached ReplyStamp so the receiver knows where to send the replies:

    use MyNamespace\GeneratePdfMessage;
    use Vrok\MessengerReply\ReplyToStamp;

    $e = new Envelope(new GeneratePdfMessage('LaTeX content'));
    $this->bus->dispatch($e
        ->with(new ReplyToStamp('output'))
    );

Implement a MessageHandler that handles the requests and returns the reply Message object:

use MyNamespace\GeneratePdfMessage
use MyNamespace\PdfResultMessage

class GeneratePdfMessageHandler implements
    MessageHandlerInterface
{
    public function __invoke(GeneratePdfMessage $message): PdfResultMessage
    {
        $LaTeX = $message->getLatex();
        $pdfContent = "<fakepdf>$LaTeX</fakePdf>";
        $reply = new PdfResultMessage($pdfContent);
        return $reply;
    }
}

Consume requests (only on the input queue!) on the receiver side:

./bin/console messenger:consume input

Consume replies (only on the output queue!) on the requesting side:

./bin/console messenger:consume pdf-results

If you need to know on the requesting side which task to resume etc. with the received reply, you can implement the Vrok\MessengerReply\TaskIdentifierMessageInterface (and use the Vrok\MessengerReply\TaskIdentifierMessageTrait) on your request and reply message classes to automatically transfer the task and/or identifier properties given on the request to the reply. We cannot use stamps for this as stamps are not accessible by MessageHandlers.

vrok/messenger-reply 适用场景与选型建议

vrok/messenger-reply 是一款 基于 PHP 开发的 Composer 扩展包,目前已累计 188 次下载、GitHub Stars 达 1, 最近一次更新时间为 2020 年 06 月 15 日, 在 PHP 生态内属于活跃度较高的组件。

它主要适用于以下技术方向: 「symfony」 「middleware」 「Messenger」 「reply」 「replyTo」 等业务场景。在实际项目中,围绕这些方向常见需要落地的问题包括:接口对接、性能调优、并发安全、与既有框架(Laravel / ThinkPHP / Yii / Webman 等)的兼容适配,以及生产环境的日志埋点与稳定性保障。

我们在过去多个企业项目中使用过 vrok/messenger-reply 或与其功能相近的方案,如果你在选型或落地过程中遇到问题,例如 版本兼容、二次改造、私有化封装、与内部系统对接、生产 BUG 排查,欢迎联系我们协助评估。

围绕 vrok/messenger-reply 我们能提供哪些服务?
定制开发 / 二次开发

基于 vrok/messenger-reply 在你已有业务上做功能扩展、字段裁剪、UI 适配、与内部账号 / 权限 / 日志系统的深度对接。

BUG 修复 & 性能优化

线上偶发问题、内存泄漏、慢查询、并发异常等排查修复;针对高流量场景做缓存、队列、索引层面的调优。

项目外包 & 长期维护

承接完整的项目从需求 → 设计 → 开发 → 上线 → 长期运维;也可按月提供技术保姆服务。

yvsm@zunyunkeji.com QQ:316430983 微信:yvsm316 西安尊云信息科技 · 专注 PHP / Go / 分布式系统研发

统计信息

  • 总下载量: 188
  • 月度下载量: 0
  • 日度下载量: 0
  • 收藏数: 1
  • 点击次数: 7
  • 依赖项目数: 1
  • 推荐数: 0

GitHub 信息

  • Stars: 1
  • Watchers: 1
  • Forks: 0
  • 开发语言: PHP

其他信息

  • 授权协议: MIT
  • 更新时间: 2020-06-15