开发说明

Gateway采用SEDA事件驱动的架构进行设计。

Messaging即消息处理机制，是一种基于消息的、异步的、消息驱动的设计方式；事件驱动贯穿Gateway开发的始终，是框架整体架构与基本功能模块之间交互的基本方式。

消息（Message）——应用功能处理的流转对象（对应事件驱动中的事件）
端点（Endpoint）——消息处理模块
通道（Channel）——消息处理模块的串连、组装
异步
- 增加拦截过滤、扩展功能的插卸
- 耗时调用上采用非阻塞方式，提高资源利用率
事件驱动（ Event-Driven Architecture）
- 降低模块、组件之间的耦合（通过事件）
- 组件只需关心如何处理事件，不必关心如何与别的组件交互
- 组件交互、事件流转由通道（Channel）或者管道（Pipes）负责
管道+处理器（Pipes and Handler）的架构风格

对于gateway来说, 任何功能几乎都是可以扩展的, 目前应用时常用的扩展类型主要有以下几种: handler扩展, filter扩展, module扩展等

handler扩展：如权限校验, 并发, 流控等直接可以独立的加到请求响应链中的这类插件称做Handler.
- 特征：必须作用在请求响应链中, 并且需要自由控制其在请求响应链的具体执行时间点, 如在某一插件前或插件后
- 应用场景：主要为需要依赖网关的配置文件中的配置信息执行该插件, 如response,参数映射,流控,并发等.
filter扩展：
- 特征：不需要依赖网关配置文件的配置信息就可以独立执行, 但执行的时间点是固定的, 比如在某个handler插件执行前后, 或者在网关的某个connector执行前后.
- 应用场景：如需要采集Http请求的请求头或者报文体的某些固定信息, 放到上下文供后面使用, 或者按照某些需求以固定模式修改请求或响应信息
Module扩展:
- 特征：执行时独立于请求响应链以外, 需要获取全局的请求响应信息, 即时性要求不是非常高的
- 应用场景：网关的每次请求响应结束时, 可以将该请求的整个上下文以事件非阻塞的方式推送给网关的事件队列, Module类型的扩展插件可以订阅感兴趣的事件, 采集需要的信息推送给其他系统或做自定义处理.

开发指南