1.3.2　合并多个事件源

有时候你需要将不同的服务结合起来，比如将A的输出作为B的输入等。Knative不会直接帮你做这些事，但Knative事件模块可以作为“胶水”将不同的服务黏合在一起。Knative从不同的事件源接收事件，然后将事件消息传递给不同的消费者。消息源可以由GitHub、Google Pub/Sub触发，或者由上传文件完成的动作触发。

将这些事件源都组合在一起也没有问题。基于Knative的标准事件接口可以将这些事件源集合在一起。Knative为此设计了一些抽象概念，用于将其组合成复杂的事件流。只要事件或消息可以转化为CloudEvent（Serverless的标准事件格式），Knative事件模块就可以接管相关事件的所有操作。

当然，Knative不是银弹，不能对所有场景都适用。比如CI/CD、数据流分析，以及业务工作流等场景。

并不是Knative不能用于以上场景，而是对于这些场景已经有更好、更专业的工具了，尽管可以用Knative构建一个MapReduce的架构，但并不能媲美MapReduce的性能与规模。尽管可以使用Knative实现CI/CD的功能，但还需要做很多其他工作来实现输入/输出流。

当开发人员想连接各种不同的服务模块或系统，而又不想额外开发时，Knative是适合的。我们在工作中经常会遇到这种情况，随着系统不断的演进，对接的复杂度会越来越高，比如Web应用的接口变更、CI/CD系统部署脚本的变更等。Knative将不同微服务之间的调用解耦出来，通过可观测性能力可以更轻松地查看不同服务之间的调用情况。

图1.2中考虑的要素是待处理的事件多样性和处理系统的业务专业性。Knative灵活通用，可以处理多种事件，横坐标表示的是批处理和批量分析系统。这类系统通常不关注多种事件。Knative是不能通过放弃灵活性而专注于数据吞吐量的。实际上在大多数情况下，应该更倾向于选择这些专业工具，不过专业工具不是免费的。

图1.2　在事件多样性与业务专业性之间，Knative的使用推荐程度