可编程网关 Pipy 第三弹：事件模型设计

本文主要是介绍可编程网关 Pipy 第三弹：事件模型设计，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

自从参加了 Flomesh 的 workshop，了解了可编程网关 Pipy。对这个“小东西”充满了好奇，前后写了两篇文章，看了部分源码解开了其部分面纱。但始终未见其全貌，没有触及其核心设计。

不是有句话，“好奇害死猫”。其实应该还有后半句，“满足了就没事”（见维基百科）。

所有就有了今天的这一篇，对前两篇感兴趣的可以跳转翻看。

• 初探可编程网关 Pipy
• 可编程网关 Pipy 第二弹：编程实现 Metrics 及源码解读

言归正传。

事件模型

上篇写了 Pipy 基于事件的信息流转，其实还未深入触及其核心的事件模型。既然是事件模型，先看事件。

src/event.hpp:41 中定义了 Pipy 的四种事件：

• Data
• MessageStart
• MessageEnd
• SessionEnd

翻看源码可知（必须吐槽文档太少）这几种事件其实是有顺序的：MessageStart -> Data -> MessageEnd -> SessionEnd。

这种面向事件模型，必然有生产者和消费者。又是翻看源码可知，生产者和消费者都是 pipy::Filter。我们在上篇文章中讲过：每个 Pipeline 都有一个过滤器链，类似单向链表的数据结构。

那是不是按照上面说的，事件是从一个 Filter 流向下一个 Filter？也对，也不对。

矛盾？

先看 Filter 如何向下传递事件，src/session.cpp:55 处，Filter 持有 output 变量，类似为 Event::Receiver（参数为 Event 的 std::function 的别名，作为外行的笔者并不懂 c++，但不妨碍了解程序设计）。通过 Receiver 调用下一个 Filter 的 #process 方法。

这里的 Receiver 就可以理解为事件发送的窗口，而 #process(Context *ctx, Event *inp) 就是事件的接收窗口。

这就是前面为什么说 “事件是从一个 Filter 流向下一个 Filter” 是正确的。

为什么不对？首先，一个 Filter 会产生多个事件，比如 decodeHttpRequest 可能会产生 MessageStart、Data 和 MessageEnd 事件，并且每产生一个事件都会通过Receiver 向下传递，不会等 #process 流程结束才传递事件；再就是下一个 Filter 可能并不会对某个事件感兴趣（下一个 Filter 的 #process 方法不做任何处理就返回了）。

可能看下图会更容易理解（图中 no output 表明事件不会向下传递）：

最简单的示例

在 test/001-echo/pipy.js 提供了的示例：

pipy()

.listen(6080)
  .decodeHttpRequest()
  .encodeHttpResponse()

发起请求

$ curl -X POST localhost:6080 -d '{}'
{}

HTTP 消息体

#request
POST / HTTP/1.1
Content-Type: application/javascript
User-Agent: PostmanRuntime/7.28.1
Accept: */*
Postman-Token: fc84b575-7fea-487b-a55d-f6085bc62cf7
Host: localhost:6080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 2

{}
#response
HTTP/1.1 200 OK
postman-token: fc84b575-7fea-487b-a55d-f6085bc62cf7
accept-encoding: gzip, deflate, br
host: localhost:6080
accept: */*
user-agent: PostmanRuntime/7.28.1
content-type: application/javascript
Connection: keep-alive
Content-Length: 2

{}

这里我们以过滤器 decodeHttpRequest 为例，官方的说明是 Deframes an HTTP request message。前面提到它会产生 3 个事件，都是在 deframe 的过程中发出的。

Session 调用第一个 Filter 时，传入的事件类型是 event::Data。decodeHttpRequest 关注该事件，并按照 HTTP 协议开始解析。

在上图可以看到解析的不同阶段，会发出不同的事件。调用 Receiver 传输事件，调用 encodeHttpResponse 的 #process() 方法。

这里又会好奇，假如上面的示例中去掉两个过滤器中的任何一个，或者都去掉，能不能正常工作？

答案是都不能！响应状态码都是 502 Bad Gateway（curl/httpie）。

分析

这里需要结合本文的第一张图 event-handling-flow。

去掉两个过滤器

假如两个都去掉了，HTTP Request 请求消息会被直接回传给客户端，协议错误。

去掉 decodeHttpRequest

前面提到 Session 传给第一个 Filter 的事件是 event::Data。而 encodeHttpResponse 针对该事件只会将其保存到 buffer 中。

然后整个链路在此结束，没有回传任何数据。客户端会等待响应，超时退出（curl）。

去掉 encodeHttpResponse

先说结果，与前面一样超时退出。

为什么会这样，明明 decodeHttpRequest 产生了 3 个时间，Session 里的 Receiver 也有收到，也确实写回了请求 body 里的 {}。

encodeHttpResponse 过滤器有写回响应头，缺少了这些信息，响应就不并不是合法的 HTTP 协议，只是普通的 TCP 协议。

总结

Pipy 基于事件模型的设计，提供了强大的灵活性。允许我们在“规则”中使用不同过滤器针对不同的事件，对请求和响应的信息进行处理。

“规则” 就是业务逻辑的核心，而 Pipy 就是这逻辑的执行引擎。

最后，“好奇心是成长的驱动力，永远保持好奇心。”

文章统一发布在公众号云原生指北

这篇关于可编程网关 Pipy 第三弹：事件模型设计的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！