>

东方通中间件TongEKT配置与AI应用集成实战

一、背景与需求分析

1.1 AI应用企业落地的行业背景

过去三年间,以大语言模型(LLM)为核心的人工智能技术经历了爆发式发展。从 OpenAI GPT-4 到国内百度文心一言、阿里通义千问、智谱 ChatGLM,大模型在自然语言理解、代码生成、知识推理等任务上已经展现出接近甚至超越人类专家的能力。这一技术突破正在快速向企业级场景渗透——智能客服、合同审查、代码辅助写作、数据分析报告生成、内部知识库问答等场景纷纷开始落地。

然而,企业级 AI 应用与个人 AI 助手在架构上存在本质差异。个人 AI 助手(如 ChatGPT 网页版)本质上是端用户直接使用云服务,数据链路短、安全要求相对宽松。而企业 AI 应用需要面对复杂得多的局面:多业务系统并发调用、敏感数据不可出网、企业身份认证体系复用、合规审计要求严格、高可用保障等。这些挑战使得 AI 能力的工程化落地成为一项系统性架构工作,而非简单的模型调用。

1.2 企业AI集成面临的核心挑战

在实际项目中,我们观察到 AI 应用企业集成通常面临以下几类挑战:

1.3 东方通TongEKT中间件定位

东方通科技股份有限公司是国内中间件领域的龙头企业,总部位于北京,其 TongEKT(Enterprise Kit)产品系列在政府、金融、能源、电信等行业有大量部署案例。TongEKT 的核心能力包括:

本次集成实践以 TongEKT ESB 总线为核心,讨论如何将 LLM 应用与 RAG 应用稳妥地接入企业已有架构,实现 AI 能力的标准化输出。

二、技术方案详解

2.1 整体架构设计

本方案采用分层集成架构,从下至上依次为:企业数据层 → TongEKT ESB 总线 → AI 服务层 → 业务应用层。各层职责清晰,边界明确,便于独立演进和故障隔离。

企业数据层包括 DB2/Oracle/MySQL 数据库、文件系统、现有业务 API,统一由 TongEKT ESB 总线提供标准化接入。该层屏蔽了底层数据源的多样性,对上层 AI 服务层提供统一的 data access 接口。

TongEKT ESB 总线是企业服务总线,承担协议转换、路由分发、消息编排、安全认证等核心功能,是 AI 服务层与企业数据层之间的桥梁。ESB 总线接收来自业务应用层的标准化 AI 请求,在内部完成数据增强(从企业数据库补充上下文)、prompt 组装后,转发给 AI 服务层,并将响应转换后回传给调用方。

AI 服务层部署 LLM 应用(如本地部署的 ChatGLM、LLaMA2)或 RAG 应用(基于向量数据库的检索增强生成)。该层专注于模型推理本身,不直接对接企业业务系统,通过 ESB 总线实现解耦。

业务应用层是前端业务系统的统称,包括内部 OA 系统、业务中台、移动端应用等。这些系统通过 HTTP/REST 接口调用 ESB 总线,ESB 再转发至 AI 服务层,完成端到端的 AI 能力注入。业务应用层无需关心 AI 模型的具体调用方式,体验如同调用一个普通内部 API。

2.2 TongEKT ESB总线配置详解

以下为 TongEKT ESB 的核心配置步骤,适用于 5.x 及以上版本。配置过程在服务器节点上通过管理控制台完成。

步骤一:安装与启动

在 Linux 环境下,解压安装包并配置环境变量后即可启动。TongEKT ESB 默认使用 Java 编写,启动前需确认服务器已安装 JDK(推荐使用阿里 Dragonwell 11 或华为毕昇 JDK)。

# 解压安装包(以 Linux 环境为例)
tar -zxvf tongekt-esb-5.6.0-linux.tar.gz -C /opt/tongekt/
cd /opt/tongekt/esb/bin/

# 配置环境变量
export TONGEKT_HOME=/opt/tongekt/esb
export PATH=$PATH:$TONGEKT_HOME/bin
export JAVA_HOME=/opt/dragonwell-11

# 启动 ESB 服务
./startup.sh

服务启动后,默认管理控制台监听端口为 7800,可通过浏览器访问 http://服务器IP:7800 进入管理界面。首次登录使用默认账户 admin / admin,强烈建议首次登录后立即修改密码,并绑定双因素认证。

步骤二:创建服务通道(Service Channel)

在 TongEKT ESB 管理控制台中,依次点击【通道管理】→【新建通道】,为 AI 服务创建一个专属通道。以下为关键配置参数:

步骤三:配置消息转换与路由规则

AI 应用的请求 body 通常遵循 OpenAI 兼容格式,而企业业务系统通常使用自有的标准化数据模型。ESB 需要承担消息转换的角色,将企业格式转换为 AI 服务期望的格式,同时将 AI 响应转换回企业格式。

在【消息转换】配置项中,新增一个 XSLT 2.0 映射规则,实现 userQuerymessages 格式的转换:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method="text" encoding="UTF-8" media-type="application/json"/>

  <xsl:template match="/">
    <xsl:text>{"model":"</xsl:text>
    <xsl:value-of select="//model"/>
    <xsl:text>","messages":[</xsl:text>

    <xsl:for-each select="//messages/message">
      <xsl:text>{"role":"</xsl:text>
      <xsl:value-of select="./@role"/>
      <xsl:text>","content":"</xsl:text>
      <xsl:value-of select="."/>
      <xsl:text>"}</xsl:text>
      <xsl:if test="position() != last()"><xsl:text>,</xsl:text></xsl:if>
    </xsl:for-each>

    <xsl:text>],"temperature":</xsl:text>
    <xsl:value-of select="//temperature"/>
    <xsl:text>,"max_tokens":</xsl:text>
    <xsl:value-of select="//max_tokens"/>
    <xsl:text>}</xsl:text>
  </xsl:template>

</xsl:stylesheet>

上述 XSLT 模板将企业封装的结构化请求映射为 OpenAI /chat/completions 接口所需的 JSON 格式,实现企业数据模型与 AI 服务接口的解耦。当 AI 服务接口发生变更时,只需修改 ESB 转换规则,业务系统无需改动。

步骤四:安全认证配置

企业 AI 应用的安全认证通常包含两个层面:一是业务系统到 ESB 的认证(通常是已有的 SSO 令牌验证),二是 ESB 到 AI 服务的认证(通常是 Bearer Token 或双向 SSL)。以下为具体配置步骤:

  1. 上传企业 CA 证书到 TongEKT 信任库(TrustStore),用于验证 AI 服务端证书真实性。
  2. 导入企业客户端证书到 TongEKT 密钥库(KeyStore),用于 AI 服务验证 ESB 客户端身份。
  3. 在通道高级配置中,勾选「启用双向认证(Mutual TLS)」,并关联对应的 KeyStore 和 TrustStore 文件路径。
  4. 若 AI 服务使用 Bearer Token 认证,在【认证头】中填入 Authorization: Bearer {token},并通过变量引用方式从 TongEKT 内置的密钥库读取实际 token 值,避免将敏感信息硬编码在配置文件中。
  5. 启用「请求签名」机制,对外发请求计算 HMAC 签名,防止请求在传输过程中被篡改。

步骤五:限流与熔断策略配置

AI 推理是高成本、高延迟的操作,若不加以保护,突发的大流量会迅速耗尽 AI 服务的资源并导致级联故障。TongEKT ESB 内置基于 Resilience4j 的熔断和限流能力,以下为推荐配置参数:

# 在通道高级配置中添加熔断规则(JSON 格式)
{
  "circuitBreaker": {
    "enabled": true,
    "failureRateThreshold": 50,
    "slowCallRateThreshold": 60,
    "slowCallDurationThreshold": 30000,
    "slidingWindowType": "COUNT_BASED",
    "slidingWindowSize": 10,
    "minimumNumberOfCalls": 5,
    "waitIntervalOpenCall": 60000,
    "permittedNumberOfCallsInHalfOpenState": 3
  },
  "rateLimiter": {
    "enabled": true,
    "limitForPeriod": 100,
    "limitRefreshPeriod": "PT1M",
    "timeoutDuration": 5000
  },
  "retry": {
    "enabled": true,
    "maxAttempts": 2,
    "waitDuration": "PT1S",
    "retryExceptions": ["java.io.IOException", "java.util.concurrent.TimeoutException"]
  }
}

上述配置各参数含义如下:熔断器在 10 次滑动窗口调用中若失败率超过 50% 或慢调用率超过 60%,自动打开熔断开关,后续请求直接返回降级响应而非继续打到 AI 服务;熔断打开 60 秒后进入半开状态,允许 3 个试探性请求,若成功则关闭熔断恢复正常。限流器限制每分钟最多 100 次 AI 调用,超出的请求进入排队队列(最多等待 5 秒),超过队列上限则直接拒绝。

2.3 LLM应用集成方案

LLM(大语言模型)应用集成的核心是解决三个问题:请求标准化转发响应提取转换异常错误处理

以本地部署的 ChatGLM3-6B 为例,AI 服务通过 FastAPI 暴露 OpenAI 兼容的 /v1/chat/completions 接口。ESB 负责将业务系统的请求标准化后转发给 ChatGLM 服务,同时将 ChatGLM 的响应转换回企业标准化格式,回传给业务系统。ESB 在这个过程中还可以做额外的增强操作,例如从企业数据库中查询合同元数据注入 prompt 上下文、将用户历史对话记录拼接为多轮会话等。

一个典型的业务场景是法务合同 AI 辅助审查:业务系统传入一段合同文本和业务问题(如"请检查本合同中的付款条款是否有风险"),ESB 自动拼接 prompt 模板、设置 temperature 和 max_tokens 参数、发送到 ChatGLM 推理服务,最后将生成的答案提取并封装为 JSON 返回给业务系统展示。

# 场景:合同审查 - 业务系统 → ESB 请求体
{
  "bizId": "CONTRACT-2024-001",
  "model": "chatglm3-6b",
  "userQuery": "请总结本合同的付款条款要点,以项目代号CC-2024开头,并标注潜在风险点",
  "temperature": 0.7,
  "max_tokens": 512,
  "context": {
    "contractType": "采购合同",
    "counterparty": "某科技有限公司"
  }
}

# ESB 转换后发送至 AI 服务的请求体(OpenAI 兼容格式)
{
  "model": "chatglm3-6b",
  "messages": [
    {"role": "system", "content": "你是一个专业的合同审查助手,擅长分析商业合同条款并识别潜在风险。请基于合同内容回答用户问题,回答时使用项目代号CC-2024作为开头标注。"},
    {"role": "user", "content": "合同类型:采购合同,交易对方:某科技有限公司。请总结本合同的付款条款要点,并标注潜在风险点。"}
  ],
  "temperature": 0.7,
  "max_tokens": 512
}

# ESB 转换后 AI 服务响应回传业务系统的格式
{
  "bizId": "CONTRACT-2024-001",
  "answer": "CC-2024:本合同付款条款主要约定……(AI生成内容)",
  "model": "chatglm3-6b",
  "tokensUsed": 387,
  "latencyMs": 4200
}

2.4 RAG应用集成方案

RAG(检索增强生成,Retrieval-Augmented Generation)是当前企业 AI 落地的主流架构,核心优势在于能够将企业私有知识(不在大模型训练集中)作为上下文注入推理过程,从而大幅提升回答的准确性和可信度。RAG 的核心流程为:用户自然语言提问 → 向量检索 → Top-K 相似文档片段注入 prompt → LLM 生成带引用的答案。

在基于 TongEKT ESB 的集成方案中,ESB 承担 RAG 应用中文档预处理和检索路由的工作,实现三个核心环节的串联协同。以下为各环节详细说明:

文档注入阶段(Document Ingestion)

业务系统上传合同、文档 PDF 等非结构化文件后,ESB 通过内置的消息编排引擎自动执行以下处理流程:首先调用独立的文档解析微服务将 PDF 解析为纯文本,然后调用文本切分服务(Text Chunking Service)将长文本按语义段落切分为适合检索的 Chunk 单元(通常每 Chunk 控制在 500 字左右),接着调用 Embedding 服务(如 text2vec-large-chinese 或 BGE-large-zh)将每个 Chunk 转换为向量表示,最后将向量写入向量数据库(Milvus)的指定 Collection。ESB 通过可视化编排界面将上述多个微服务调用串联为一个自动化 Pipeline,对业务系统暴露为一个简单的「文档上传」接口。

查询阶段(Query and Retrieval)

当业务系统发送自然语言查询时,ESB 内部依次执行以下操作:第一步,将用户查询文本发送给 Embedding 服务获取查询向量;第二步,以查询向量为输入请求 Milvus 向量数据库,执行 ANN(Approximate Nearest Neighbor)检索,返回最相似的 Top-K(如 Top-5)文档片段;第三步,将 Top-K 片段组装为带引用标记的上下文(Reference Context);第四步,将 query + Reference Context 组装为完整的 RAG prompt,发送给 LLM 服务进行推理生成。

# RAG 查询场景 - 业务系统 → ESB 请求体
{
  "query": "本合同中的保密条款有哪些?有哪些需要注意的限制?",
  "topK": 5,
  "threshold": 0.75,
  "model": "chatglm3-6b",
  "collection": "contract_docs"
}

# ESB 内部 Step 1:查询向量嵌入
# ESB → Embedding 服务:GET /v1/embeddings
# Request: {"input": "本合同中的保密条款有哪些?有哪些需要注意的限制?", "model": "text2vec-large-chinese"}
# Response: {"embedding": [0.123, -0.456, ...], "tokens_used": 28}

# ESB 内部 Step 2:向量检索(Milvus)
# ESB → Milvus: POST /collections/contract_docs/query
# Request: {
#   "query_vector": [0.123, -0.456, ...],
#   "limit": 5,
#   "output_fields": ["chunk_text", "source_file", "page_num"],
#   "filter": "doc_type == 'contract'"
# }
# Response: {
#   "results": [
#     {"chunk_text": "甲方承诺在合同签署之日起三年内对乙方提供的数据保密……", "source_file": "采购合同2024.pdf", "score": 0.912},
#     {"chunk_text": "保密信息的范围包括但不限于:技术资料、财务数据……", "source_file": "采购合同2024.pdf", "score": 0.887},
#     ...
#   ]
# }

# ESB 内部 Step 3:组装 RAG Prompt 发送给 LLM
# ESB → LLM 服务:POST /v1/chat/completions
{
  "model": "chatglm3-6b",
  "messages": [
    {"role": "system", "content": "你是一个专业的合同分析助手,基于以下参考内容回答用户问题。如果参考内容中没有相关信息,请如实说明。回答时须在末尾注明引用来源。\n\n参考内容:\n【来源1 - 采购合同2024.pdf】甲方承诺在合同签署之日起三年内对乙方提供的数据保密……\n【来源2 - 采购合同2024.pdf】保密信息的范围包括但不限于:技术资料、财务数据……"},
    {"role": "user", "content": "本合同中的保密条款有哪些?有哪些需要注意的限制?"}
  ]
}

# ESB 最终回传给业务系统的 RAG 答案
{
  "answer": "根据合同约定,保密条款主要包含以下内容:\n1. 保密期限:甲方承诺在合同签署之日起三年内对乙方提供的数据保密……\n2. 保密范围:包括但不限于技术资料、财务数据……\n\n【引用来源:采购合同2024.pdf】",
  "sources": [
    {"file": "采购合同2024.pdf", "relevance": 0.912},
    {"file": "采购合同2024.pdf", "relevance": 0.887}
  ],
  "latencyMs": 6800
}

2.5 国产化适配关键要点

在国产化适配层面,TongEKT 相比国外中间件的主要优势在于对国产操作系统、国产数据库和国产 JDK 的良好兼容。政企客户在选型时,国产化适配能力是重要的评分项。以下列出几个关键适配点:

三、集成效果与收益

3.1 业务价值

通过 TongEKT ESB 总线接入 AI 能力后,企业在不用大规模改造现有业务系统的情况下,快速实现了三大 AI 能力注入,产生了可量化的业务价值:

3.2 技术性能指标

在压力测试环境中,基于 TongEKT ESB + ChatGLM3-6B(INT4 量化版)的集成方案达到了以下性能指标:

指标项测试结果说明
并发吞吐量100 并发稳定支撑ESB 在 100 并发下 CPU 使用率约 65%,AI 服务侧通过限流保护未出现 OOM
熔断响应时间熔断打开后请求在 3ms 内返回不再穿透到 AI 服务,避免资源浪费
熔断触发时间故障后约 50 秒触发10 次滑动窗口内失败率超 50% 触发
端到端 P99 延迟约 8.5 秒AI 推理耗时占主导,ESB 转发本身延迟 < 50ms
ESB HA 切换时间约 5 秒主备节点心跳检测间隔和切换策略共同决定
限流拒绝率超出 100 次/分钟后请求进入排队超过队列上限后返回 429 状态码,业务侧触发重试

3.3 运维收益

TongEKT 提供的统一管理控制台让 AI 服务的运维变得透明可控,相比此前「黑盒调用」模式有了质的提升:

四、总结与展望

4.1 核心结论

本文从实战角度详细描述了东方通 TongEKT 中间件与 AI 应用集成的全流程,涵盖 ESB 通道配置、消息转换、安全认证、限流熔断等关键环节,并给出了 LLM 应用接入和 RAG 应用接入的具体技术方案。核心结论如下:

4.2 实践建议

基于本次集成经验,给出以下实践建议供读者参考:

4.3 技术趋势展望

AI 应用的企业落地是一个持续演进的过程。随着国产大模型的持续成熟(预计 2025-2026 年将有多款达到 GPT-4 同等能力的国产模型通过备案),东方通等中间件厂商与 AI 生态的集成深度还将进一步加深。我们预判以下几个方向将成为下一阶段的重点:

AI 能力的落地不是孤立的模型部署问题,而是需要与企业已有架构、数据、安全、运维体系深度融合的系统性工程。TongEKT 作为国产企业级中间件的标杆产品,在这场工程化落地中扮演着不可替代的桥梁角色。对于正在规划 AI 能力企业落地的技术团队,建议尽早将中间件层的建设纳入架构规划,避免在规模扩大后被动重构。

本文基于 TongEKT 5.6.x 版本编写。不同版本配置界面和参数名称可能略有差异,建议实际配置时参考东方通官方产品文档(可通过东方通技术支持热线获取最新文档)。如有问题可在项目实践中通过东方通技术服务渠道反馈。