WSO2 Integrator入站端点请求路由及Axis2层相关问题咨询

入站端点是否维护端点-资源映射表 #

HTTP/HTTPS 类型入站端点（Inbound Endpoint）既不会维护端口维度的路径-资源映射表，也不是纯透传组件，核心逻辑如下：

• 首先需要明确：MI 部署的 API、Proxy Service 资源是注册在全局资源注册表中的，并非绑定在默认 8290 端口上。8290 只是默认 Axis2 HTTP 传输监听器的监听端口，不存在「资源属于某个端口」的绑定关系。
• 你描述的场景中，8505 端口创建的入站端点配置了/healthcare/querydoctor/.*的路径匹配规则，不会生成你提到的8505端口路径 -> 8290端口资源的映射关系：
  • 如果给该入站端点显式配置了注入目标（指定inject-sequence或固定关联的API），收到匹配路径的请求后会直接投递到指定目标，不会做额外的资源匹配
  • 如果没有配置固定注入目标，入站端点收到匹配请求后会直接调用全局资源分发逻辑，从全局资源注册表中匹配符合路径规则的API、Proxy Service，这个匹配过程和默认8290端口收到请求后的路由逻辑完全一致，只是入口端口不同。
• 入站端点不是纯透传：它本身会完成端口监听、连接管理、报文解析、路径匹配的动作，不是直接把TCP流量转发到其他端口。

「绕进入站侧Axis2层」的具体含义 #

要理解这个逻辑，先明确默认HTTP传输的处理流程：
MI 默认的8290(HTTP)、8253(HTTPS)端口是基于Axis2传输框架实现的监听器，请求到达后必须先走完Axis2入站侧的完整处理链：

• 传输层报文解析、HTTP协议头标准化处理
• 构建Axis2规范的消息上下文对象
• 执行所有全局注册的Axis2传输级拦截器
• 按照Axis2层配置的传输路由规则做初步分发

而HTTP入站端点采用的是独立的Netty实现的HTTP监听器，不依赖Axis2传输框架：

• 当入站端点配置的目标是Sequence或者API时，请求匹配路径规则后，会直接将解析后的报文转换为MI内部的消息上下文，跳过上述Axis2入站侧的全量处理流程，直接把消息投递到目标序列/API，这就是所谓的「绕过Axis2层」。
• 当入站端点配置的目标是Proxy Service时，不会走上述直接注入逻辑，而是会把构建好的消息上下文提交到Axis2核心处理引擎，完整走完Axis2的拦截、路由流程，和默认端口收到的Proxy请求处理逻辑完全一致。

采用绕过Axis2层设计的原因 #

• 性能提升：跳过Axis2传输层的冗余处理逻辑，减少请求处理链路长度，在高并发场景下可以明显降低延迟、提升吞吐量，适合高吞吐的API接入场景
• 配置隔离：不同入站端点可以独立配置监听端口、线程池大小、连接超时、安全校验规则，不会和默认端口的全局Axis2传输配置耦合，方便做多业务域的入口隔离
• 路由灵活：不受Axis2传输层全局路由规则的限制，可以直接将指定端口、指定路径的请求投递到自定义处理序列，满足多入口差异化处理的需求，不需要修改全局传输配置。

内容的提问来源于stack exchange，提问作者viggnah