Knative Eventing中怎么实现一个Registry 事件注册机制，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
背景
作为事件消费者，之前是无法事先知道哪些事件可以被消费，如果能通过某种方式获得哪些 Broker 提供哪些事件,那么事件消费者就能很方便通过这些 Broker 消费事件。Registry 就是在这样的背景下被提出的，通过 Registry 机制，消费者能针对特定的 Broker 的事件通过 Trigger 进行事件订阅消费。
每个Registry 对应一个 Namespace 作为资源隔离的边界
Registry 中包括事件类型列表，以提供事件发现机制，通过事件列表，我们可以决定对哪些 Ready 的事件进行消费
由于事件最终需要通过 Trigger 进行订阅，因此事件类型信息中需要包括创建 Trigger 所需要的信息。
定义 EventType 类型的CRD资源，示例yaml：
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: name: com.github.pullrequest namespace: default spec: type: com.github.pull_request source: github.com schema: //github.com/schemas/pull_request description: "GitHub pull request" broker: default
name: 设置时需要符合k8s命名规范
type：遵循CloudEvent 类型设置。
source: 遵循 CloudEvent source设置。
schema: 可以是JSON schema, protobuf schema等。可选项。
description: 事件描述，可选项。
broker: 所提供 EventType 的 Broker。
1.创建 EventType
一般我们通过以下两种方式创建 EventType 实现事件的注册。
1.1通过Event 事件源实例自动注册
基于事件源实例，通过事件源控制器创建 EventType 进行注册：
apiVersion: sources.eventing.knative.dev/v1alpha1 kind: GitHubSource metadata: name: github-source-sample namespace: default spec: eventTypes: - push - pull_request ownerAndRepository: my-other-user/my-other-repo accessToken: secretKeyRef: name: github-secret key: accessToken secretToken: secretKeyRef: name: github-secret key: secretToken sink: apiVersion: eventing.knative.dev/v1alpha1 kind: Broker name: default
通过运行上面的yaml信息，通过GitHubSource 事件源控制器可以创建事件类型dev.knative.source.github.push以及事件类型dev.knative.source.github.pull_request这两个EventType进行注册，其中source为github.com以及名称为default的Broker。具体如下：
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: generateName: dev.knative.source.github.push- namespace: default owner: # Owned by github-source-sample spec: type: dev.knative.source.github.push source: github.com broker: default --- apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: generateName: dev.knative.source.github.pullrequest- namespace: default owner: # Owned by github-source-sample spec: type: dev.knative.source.github.pull_request source: github.com broker: default
这里有两点需要注意：
通过自动生成默认名称，避免名称冲突。对于是否应该在代码（在本例中是GithubSource控制器）创建事件类型时生成，需要进一步讨论。
我们给spec.type加上了dev.knative.source.github.前缀，这个也需要进一步讨论确定是否合理。
1.2手动注册
直接通过创建EventType CR资源实现注册，如：
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: name: org.bitbucket.repofork namespace: default spec: type: org.bitbucket.repo:fork source: bitbucket.org broker: dev description: "BitBucket fork"
通过这种方式可以注册名称为org.bitbucket.repofork, type 为 org.bitbucket.repo:fork, source 为 bitbucket.org 以及属于dev Broker 的 EventType。
2.获取 Registry 的事件注册
事件消费者可以通过如下方式获取 Registry 的事件注册列表：
$ kubectl get eventtypes -n default
NAME TYPE SOURCE SCHEMA BROKER DESCRIPTION READY REASON org.bitbucket.repofork org.bitbucket.repo:fork bitbucket.org dev BitBucket fork False BrokerIsNotReady com.github.pullrequest com.github.pull_request github.com //github.com/schemas/pull_request default GitHub pull request True dev.knative.source.github.push-34cnb dev.knative.source.github.push github.com default True dev.knative.source.github.pullrequest-86jhv dev.knative.source.github.pull_request github.com default True
3.Trigger订阅事件
最后基于事件注册列表信息，事件消费者创建对应的Trigger对Registry中的EventType进行监听消费
Trigger示例：
apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger metadata: name: my-service-trigger namespace: default spec: filter: sourceAndType: type: dev.knative.source.github.push source: github.com subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: my-service
针对 Registry，一般可能涉及到有如下问题：
Registry 是对 Trigger 订阅事件，是否包括 Event Source 事件源的处理？
答：Registry 设计的初衷主要是针对事件消费者能够发现事件并进行消费，因此它的出现主要是让用户创建Trigger进行事件订阅
如果仅仅创建 Event Source 通过Sink设置 KnService 进行事件消费(没有Trigger), 是否也可以使用Registry?
答：Registry 的设计主要是针对 Broker/Trigger 事件处理模型， 并且我们可以发现 EventType 中的Broker字段是必需设置的。如果没有发送事件到Broker， 就不会创建EventType注册到Registry。在实现方面，我们可以检查Event Source的Sink类型是否是Broker，如果是，则对其注册EventType。
是否可以通过CloudEvents subject 字段过滤资源
答：EventType CRD资源不会包含subject字段， 因为我们认为subject是更高级别的过滤设置。不过社区后续会通过高级过滤规则 进行实现。例如：
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: only-knative
spec:
filter:
cel:
expression: ce.subject.match("/knative/*")
subscriber:
ref:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
name: knative-events-processor看完上述内容，你们掌握Knative Eventing中怎么实现一个Registry 事件注册机制的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
