es-triggers

请求转化和分发即服务

这是干啥用的？

简单说，这是一个HTTP服务，可以将接收到的HTTP请求进行转化，并转发给其他HTTP服务。

为什么要做这个服务？

在进行HTTP服务集成的时候，集成和维护成本往往很高，比如：

1. HTTP请求发送方（ Client 端）和 HTTP请求接收方（Server 端）之间经常存在不兼容的情况，导致集成困难和调用失败。

2. 如果 Client 端和 Server 端由不同的团队甚至厂商进行维护，那么请求调用失败后问题的定位和分析需要就会产生大量的沟通成本，问题的解决也会带来更多的成本（见下面的 原因2 ）。

我们希望能够降低这些成本和风险，这是开发这个服务的初衷。

导致高成本集成的原因

1. 多请求格式难扩展：Client 经常需要向 Server 端发送不同类型的请求格式来调用 Server 端相同的业务逻辑，如果 Server 端对 每种请求 单独暴露接口，M 种请求就会有M 个不同接口的开发、部署、维护成本。

2. 多方接收难调整：Client 端经常需要同时向不同的 Server 端发送请求，如果 Client 端对请求格式进行了调整，所有接收该 Client 端请求的 Server 端都有可能受到影响，这些Server端可能都需要进行调整，有 N 个 Server 端就会有 N 倍的开发、部署、维护成本。

3. 不兼容、难复用：Server 端已经暴露的接口与 Client 端不兼容，Server 端或 Client 端如果为此进行代码修改，就可能带来前面两条原因所产生的成本和风险。

   不兼容主要包括以下两种情况：

   1. 调用次数不兼容：比如，Client 端希望只发送一次请求调用 Server 端进行多次业务逻辑，而 Server 端希望暴露的接口的一次请 求只处理一次业务逻辑。

   2. 请求形态不兼容：即 Client 端发送的请求数据形态（Shape）和 Server 端接口希望接收的请求形态（Shape）有所不同。

降低成本的途径

这个服务试图在 Client 端与 Server 端之间插入一层可配置、可观测、可审计的协调层，对来自 Client 端的输入请求进行 拦截 和 信息提取，并根据 Server 端的要求进行输出请求的 拦截、 塑形、组装、分发。

1. 一切皆配置：所有的转化与分发逻辑都通过配置完成，无需开发部署。由此可以做到 1次部署 + 持续配置 + 0次开发 的低成本模式。

2. 一切皆代码：所有配置数据都进行了代码模块化处理，可以做到 每个模块声明Once And Only Once ，将 M x N 的高成本模式变为 M + N 的低成本模式。同时由于采用了代码版本控制，所有的配置修改原生可审计。

3. 一切皆事件：所有逻辑执行都记录为事件日志，可以做到 免沟通问题定位和排查 的低成本模式。同时，对日志数据还可以带来良好的可观测性。

这个服务是怎么工作的？

这个服务将一系列的模块化的配置串联为一套处理流程，对每个输入请求进行处理，最终形成一组输出请求。

在这个流程中，每一种配置模块都回答了流程所需的一个或多个相关的问题：

1. Listener：监听器，回答了 输入请求从哪里来 以及 输入请求要触发哪些处理流程。
2. SourceInterceptor：源拦截器，回答了 一个处理流程可以被什么样的输入请求触发。
3. Binding：绑定，回答了 要从输入请求里获取哪些数据。
4. TargetRequest：目标请求，回答了 一个输出请求要由哪条处理流程产生。
5. TargetInterceptor: 目标拦截器，回答了 一条处理流程产生的所有输出请求哪些会通过HTTP发送。
6. Template：模版，回答了 HTTP发送的输出请求长什么样。
7. TargetSystem：目标系统，回答了一条处理流程要把输出请求发送到哪里去。
8. Trigger：流程触发，回答了这条流程需要使用哪个源拦截器、使用哪个绑定、使用哪个目标拦截器、使用哪个模版、发送给哪个目标系统、会产生哪些输出请求。

这个服务负责将所有这些配置自动的贯穿起来。

我可以用这个服务做什么？

举个例子，你可以使用触发器实现CI/CD的流程。

1. 用这个服务将第三方系统（比如GitHub、GitLab等）的WebHook事件分发给CI/CD系统的启动接口。
2. CI/CD系统的每个任务完成后，通过这个服务将反馈信息发送给CI/CD系统的调度接口。
3. CI/CD系统的任务完成后，通过这个服务实现流水线的WebHook和质量门禁。
4. CI/CD系统的任务执行，可以通过这个服务与第三方执行系统（比如SonarQube）进行集成。

授权

本服务采用 MIT 授权。