本节对Knative的第三大组件—Eventing进行介绍，Kubernetes用户在实现开发和部署阶段服务之间松耦合的同时，服务间常要通过不同的事件机制来进行事件传递，为了解决大部分的云原生消息通信需求，Knative提供了Eventing组件。

与Serving和Building两个组件相同，Eventing也是基于Kubernetes的控制器模式实现的。Eventing在版本迭代过程中陆续更新一些特性，版本之间有些许差距，本文基于Knative Eventing 0.6进行介绍。由于Eventing涉及的概念比较多，我们根据版本迭代过程来讲解Eventing组件，从而呈现整个Eventing的设计思路。同时，鉴于0.6版本解除了对Istio的依赖，本篇也不会提及Knative的好朋友Istio。

1、事件的订阅发布

在0.5版本之前，Eventing最重要的两个对象是 Channel 和 Subscriptions，如下图所示，Channel 是事件生产者与事件消费者的中间层，它会从事件源（Event Source）收集事件并且分发给事件消费者（Service）。创建一个Channel对象会将一个事件源绑定到该Channel，这里我们定义的Channel必须是可寻址的，目前Knative只支持HTTP协议，这个地址对应是一个URI，事件源可以通过这个URI将事件发送给Channel。那么事件消费者从哪里订阅事件呢？ Eventing提出了另一个对象Subscription，用户可以通过创建一个Subscription对象来指定一个事件消费者对事件的订阅，需要分发给哪些消费者是通过Subscription来指定的，同样消费者需要提供分发路径URI。

可以看出，Channel起到了一个订阅分发事件的作用，但实际上这里的 Channel 只是一个概念，底层存储可以有不同形式的实现，在Knative Eventing中称为Provisioner。目前Knative已经支持多种不同的Provisioner：Apache Kafka、GCP PubSub、NATS。除了对这些消息中间件的支持，为方便用户学习和测试使用，Knative 也提供便捷的Provisioner：In-Memory Channel。但是In-Memory将事件信息缓存在内存中，服务一旦退出会导致事件信息全部丢失，因为生产环境使用是不安全的。

我们通过一组示例来展示怎样利用Eventing组件实现订阅发布目的。

1、首先定义一个Channel对象，Spec字段需要指定Channel的底层实现，这里采用的是In-memory类型的Provisioner。

2、创建事件源。这里我们定义一个从Github获取消息的事件源。目前，Eventing组件已经支持多种事件源，GitHubSource是其中的一类，参数中需要配置关注的事件点，这里关注的事件点是某个Git库的项目Pull事件，Sink中指定消息会发送到我们在第一步创建的Channel中。

3、创建事件订阅方。创建一个Subscription对象绑定一个Subscriber到Channel的绑定，创建之后，集群中名称为test的Service就可以成功订阅Channel，也可以获取Github的项目Pull事件。同样，也可以创建多个Subecription来绑定更多的Subscriber。

如上所述，我们就实现了一组订阅发布，实现了集群内部服务对Github事件的订阅。

下面，我们讲一下上述操作背后的控制器实现，对于In-Memory的Channel底层存储支持以及Github事件源支持的实现，我们在第四部分“扩展Knative Eventing”中会进行介绍，这里我们主要讲一下其余两个主要的控制器，Subscribtion控制器和Channel控制器。

首先是Channel Controller。这个控制器的逻辑很简单，它关注Channel资源的变动，检测Channel底层的Provisioner是否已经安装支持，如果不支持会在Status标记。

其次是Subscribtion Controller。它会关注Subscribtion资源的变动，一方面生成生成Subscriber的URI（如果Subscriber是一个Kubernetes Service对象，那么Service的访问路径就是该URI）；另一方面会将Subscribtion注册到指定的Channel，也就是将Subscribtion加入到Channel的Spec的Subscrible字段，这样Channel就知道要将自己的消息分发到哪些Subscriber了。

从控制器逻辑上看，完全没有事件采集、保存、转发的实际流程，那么这部分流程在哪里呢？前文已经介绍了Channel只是概念的逻辑，Channel Controller 自然也不会有实际的举动。事件的处理都在事件源组件与Provisioner两个部分完成，这两个部分是可以插件化的扩展的，主要的工作流程在第四节你就会明白。

2、事件的过滤转发

在0.5版本中，Knative Eventing增加了Broker和Trigger对象的定义，方便对事件进行过滤，事件的消费方可以利用这种机制只获取自己感兴趣的事件，而不是无脑接收所有Channel中的事件信息。说到这里，你首先会想问“过滤条件”的指标怎么定义呢？Eventing的过滤指标暂时支持的有两项：Type（事件的类型）和Source（事件来源），后续版本应该会支持更多的筛选规则。那又怎样能保证所有的事件都有这两项呢？其实Eventing组件要求事件信息的格式符合CloudEvents的标准（https://github.com/cloudevents/spec/blob/master/spec.md#design-goals），这两项指标在标准参数之内。

如果你的Eventing版本是0.5之后的，那么你就可以使用Trigger来订阅自己感兴趣的事件了。订阅的方式也很简单，原先我们订阅一个事件是创建一个Subscribtion对象，现在创建一个Trigger对象即可。下图定义了一个Trigger，Spec字段中的filter字段定义了筛选逻辑，只订阅Broker名称为default中的Type为dev.knative.foo同时Source为dev.knative.bar的消息，订阅方是名称为message-dumper的Service。

那Broker是用来做什么的呢？从逻辑图里很容易认为Broker是Channel的替代品，其实不是，它不是为了事件信息缓存转发存在的，而是为了事件过滤存在概念，这里展示一个Broker的定义就一目了然。可以看见定义一个Broker的时候仍旧需要指定一个Channel，这个Channel是Broker的事件来源。Broker根据Trigger中定义的规则，对事件进行过滤，过滤之后发送给事件的订阅方。

与上述过滤机制相关的控制器有两个：Trigger Controller 和 Broker Controller。其中Trigger Controller处理Trigger资源的逻辑，Broker Controller处理Broker资源的逻辑。

Broker Controller的处理逻辑主要如下：

1、创建Broker资源定义的Channel资源。
2、创建用于Fliter的Deployment。该服务负责实现消息过滤。
3、创建步骤2中的Deployment资源的上层Service资源。

Trigger Controller主要为每个Trigger资源创建一个Subscribtion，由于Channel中的事件只会分发给由Subscribtion指定的Subscriber，这里创建Subscribtion对象本质上是用于将Channel中的事件导流，Subscriber的URI参数为Broker控制器在第三步中创建的Service的访问路径。这样，Channel中的事件被导流到用于Flitter的Service，Flitter根据Trigger中定义的规则过滤之后再将事件给真实的Subscriber，从而实现事件过滤。

3、事件注册

在0.6版本中，Knative Eventing增加了EventType对象的定义，方便用户得知从不同Broker获取的所有事件集合。在提出EventType概念之前，用户在定义了一系列的Broker之后很难管理集群中可以订阅的事件，需要逐个查看Channel资源的事件源，EventType就是为了解决这个问题提出的。

在创建事件源对象资源的同时，控制器会创建一个对应的EventType对象来注册消息源对象。有了EventType的事件注册支持，用户通过kubeclt get eventtypes就可以获取集群中所有通过Broker定义的事件源，从而查看是否有自己需要订阅的事件，示例如下：

原图链接https://knative.dev/docs/eventing/event-registry/

EventType只能用于搭配Broker和Trigger使用，用户在获取集群中的事件源集合之后，同时可以查看事件是否可以被订阅。如果允许订阅，就可以通过Trigger来订阅感兴趣的事件。

4、扩展Knative Eventing

最后，我们来介绍对于Knative Eventing组件可以做的个性化扩展，读者可以通过这些扩展来支持自己的业务或者是组件。

4.1 扩展Channel底层存储实现的支持

前文我们说过，Channel资源是一个概念上的含义，Channel Controller并没有完成事件的存储转发等行为，而是由不同的Provisioner实现的。这里我们以GCP PubSub为例介绍怎样扩展Channel底层存储支持，同时也可以了解Provisioner的工作机制，清楚Channel消息是怎么接收、存储和分发的。

GCP PubSub是一个分布式消息总线，使用时需要创建一个Topic，然后才可以向Topic发布消息或者是订阅主题。对应到Eventing，一个Channel也就对应了一个Topic，对Channel的一个订阅对应了一个GCP PubSub 的 Subscription 的创建，在实现时，会对Channel的Status字段中添加Subscription字段来记录该Channel实际创建的GCP Pubsub Subscription资源。

扩展对GCP PubSub的支持首先需要创建一个特定名称（gcp-pubsub）的ClusterChannelProvisioner对象，“ClusterChannelProvisioner”是由 Eventing 组件提供的资源类型。创建了这个对象就是向Eventing组件宣称：你已经可以支持名称为“gcp-pubsub”的Provisioner了，这种类型的Channel也可以正常工作了。

下一步就是实现控制器逻辑了，控制器需时刻关注Channel的动静，一旦有Provisioner类型为“gcp-pubsub”的Channel增删，控制器就要负起责任，实现底层的资源的增删。

控制器有两部分构成：Channel控制器和Dispatcher分发器；首先介绍Channel控制器的处理逻辑：

1、创建Kubernetes Service对象。每个Channel资源会对应创建一个Service，Channel的URI也就是Service的访问路径，Service的类型为externalName，这种类型的service背后并没有真实存在的Pod支撑，是一个空的Service，而进入 Service 的流量全部导入externalName指定的路径，这个路径是我们接下来要介绍的另一个组件的Service路径。

2、创建Topic。每个Channel对应一个GCP PubSub的Topic，如果这个Channel对象是新建的，那么需要创建一个Topic。

3、创建Subscription。将Channel的Spec字段中的Subscrible（该字段有对该Channel进行订阅的所有的Subscriber对象集合，是subscription控制器在subscription对象创建的时候写入Channel的）与Status字段中的subscription（GCP PubSub中实际存在的订阅资源）进行对比，创建/删除 GCP PubSub资源，保证一个Channel订阅对应一个真实的Gcp PubSub订阅资源。

Dispatcher分发器以Deployment部署，上层有一个Kubernetes Service资源，我们在上文中说过，进入Channel的事件都会被转发到分发器，可以看出Dispatcher实际上是Gcp PubSub与Eventing之间的Adapter，负责将集群内事件生产者进入 Channel 的事件发送到指定 Topic，同时将Topic中的事件分发给各个事件的消费者。

Dispatcher组件也是以控制器形式完成的，对于每个Channel会创建一个Receiver对象来负责接收集群中的事件，并将事件发送给Gcp Pubsub，每一个Subscriber会创建一个Dispatcher 协程负责接收GCP PubSub的事件并发送给指定的Subscriber。

根据上述逻辑，你也可以愉快地开发支持自己的消息中间件作为Channel底层存储啦。介绍怎样实现Channel对外部消息中间件的支持，掌握了其中原理，你也就可以扩展自己的消息中间件作为Channel的Provisioner。

4.2 扩展对新外部消息源的支持

除了Channel底层消息存储支持扩展之外，还有一部分可以实现个性化支持的就是消息源。对于Channel而言，事件源并非是真正产生事件的地方，而是集群中将事件源产生的事件收集到集群内的Adapter。目前Eventing已经支持了很多的事件源，也开发完成了相应的Adapter，例如GitLab、GitHub、GCP PubSub、Apache Kafka等等。还有一些事件源并不会直接被使用，而会让其他的事件源实现更加方便，例如Container Source。

这里还是以GCP PubSub为例，讲解怎样实现对一个外部事件源的支持，实现模式仍旧是老朋友控制器模式。

首先需要定义一个CRD，名称为“GcpPubSubSource”。这里介绍Spec中的几个比较重要的字段：GoogleCloudProject、Topic和Sink，其中GoogleCloudProject 和 Topic 两个字段用于确定事件来源的Gcp PubSub Topic；Sink用于定义事件的去向，及事件的去向，例如可以是Kubernetes集群中的某个Service或者是一个Channel。当指定Channel时，该Topic生成的事件就可以分发到Channel中，而订阅Channel的消费者可以获取Topic的事件了。当然Sink也可以是一个事件的直接消费者Service，Service拿到事件直接处理。

接下来介绍背后的控制器处理逻辑：

1、创建一个Gcp PubSub的订阅对象Subscribtion。订阅指定的Project以及Topic。

2、创建一个ReceiverAdapter对象。该Adapter组件以Deployment的形式运行在集群中，负责从Subscribtion中获取消息并且将消息发送给Sink字段的对象。

3、创建一个EventType资源。EventType对象中有个字段为Broker，Broker的名称为sink.Name。

4.3 利用Container Source创建自定义事件源

很多情况下，我们也会希望将一些自己开发的服务作为事件的生产者，Eventing提供了一种Container Source的事件源来方便用户创建自定义事件源，用户的服务只要满足几个条件就可以成为Eventing的事件生产者：

1、事件生产者服务需要打包成一个镜像。

2、镜像运行成容器时可以从环境变量中获取参数信息，该参数信息指定了服务的事件发送目标。

有了这样的镜像之后，用户可以创建一个Container Source资源来创建该服务的事件源，如下所示：

Container Source控制器的处理逻辑如下：

1、解析ContainerSource资源的args（或者是sink变量）中定义的路径或者是Kubernetes Service对象解析成可以访问的URI。

2、创建Deployment。Deployment中的镜像参数是用户的事件源服务对象，同时会将sink的URI作为容器的Env参数以及Args参数。这样镜像运行成容器之后就可以从参数中获取事件的发送路径，当这个路径对应一个Channel时，就可以实现事件的订阅分发了。

相关文章：

Knative 系列（一）：基本概念和原理解读
 Knative 系列（二）：兵马未动粮草先行之 Build 篇
 Knative 系列（三）：Serving 篇

创作场景

Knative 系列（四）：Eventing 篇