阿里云应用服务器助力传统J2EE应用无缝升级AI原生，解决协议、资源、观测等难题，实现智能化转型。
原文标题：破茧成蝶：传统J2EE应用无缝升级AI原生
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章提到通过ARMS构建统一可观测性平台，解决了跨技术栈的追踪难题。在实际应用中，如何有效地利用这些追踪数据进行故障定位和性能优化？
3、文章中提到J2EE应用通过阿里云应用服务器可以接入DashScope SDK，从而实现与大模型的互通。那么，在实际应用中，如何选择合适的大模型，并根据业务需求进行Prompt优化，以获得最佳的智能化效果？
原文内容
阿里妹导读
本文探讨了技术挑战和解决方案，还提供了具体的实施步骤，旨在帮助企业顺利实现从传统应用到智能应用的过渡。
序幕：一场跨越20年的技术对话
在杭州某科技园的会议室里，一场特殊的代码评审正在进行。屏幕上同时展示着2005年基于WebLogic开发的供应链系统和2025年接入DeepSeek大模型的智能调度方案——令人惊叹的是，二者的核心业务代码竟保持着惊人的一致性。"我们保住了20年积累的238个核心业务对象，就像修复传世名画时保留了每一笔历史痕迹。"企业CTO的感慨，揭开了阿里云应用服务器助力传统系统智能化转型的奥秘。
第一章 困局：J2EE应用的智能化转型之痛
当经典架构遭遇智能洪流
应用架构从信息化诞生以来，分别历经了单体、分布式、云原生现代化三代架构，到现在整个行业的应用架构正在往智能化演进，然而现在还有将近一半以上的应用仍然处在以 J2EE 为代表的单体架构时代，在智能化涌现的今天，传统架构往前演进时普遍会遇到以下的技术痛点：
-
协议鸿沟：EJB组件与微服务间的通信需要复杂的协议转换层，协议的复杂度同时带来了技术与管理的复杂度。
-
资源冲突：大模型推理请求突发时，由于 GPU 资源的限制，推理效率的偏低导致诸多的请求被阻塞，进一步影响到了在线业务的可用性。
-
观测失明：现代的 APM 系统对于微服务友好，但是很多系统上不能追踪到 EJB 的调用，往下对于 AI 模型的访问失明，导致这一类应用成为了观测的信息孤岛，链路的断路导致故障定位耗时成倍上升。
第二章 破局：阿里云应用服务器的基因重组
兼容之道：在经典中孕育新生
通过独创的"渐进式容器化"技术，阿里云基于 Nacos 实现了传统 EJB 容器与微服务体系的互通技术，架构图如下所示：
下面是程序员编写代码时的示例代码：
// 传统J2EE应用的云原生唤醒示例 @CloudEJBAdapter(name = "springcloud-provider-demo") public interface RemoteHello extends Serializable {
@GetMapping(“/hello”)
String hello(String name);
}
技术亮点：
-
双栈运行时环境：同时支持EJB3.0和微服务（支持 Spring Cloud 与 Dubbo两种服务框架）
-
智能协议转换桥：自动转换RMI/REST/GRPC协议
-
热插拔模块加载：无需重启加载微服务与智能化组件
智能中枢：大模型即插即用架构
基于阿里云的 DashScope SDK ，阿里云在应用服务器中实现了传统 J2EE 应用与大模型的互通的能力，架构图如下图所示：
（架构说明：通过 DashScope 实现与主流大模型的标准化对接）
三大创新设计：
-
模型沙箱环境：隔离大模型推理线程池资源，减轻 AI 业务对传统业务的影响
-
请求限流：引入 Model Filter ，根据 Token 进行请求限流
-
Prompt 管理：通过控制台进行 Prompt 注入与动态管理
全景可观测：照亮系统每个角落
在数字化转型进程中，众多企业面临着典型的技术架构演进困境：传统EJB单体系统因历史技术债务积重难返，长期处于有限维护状态；新兴业务采用Spring Cloud技术栈构建云原生微服务集群；而AI智能化浪潮又催生出基于大模型的张量计算服务。这三大业务世代共存的现状，导致整个业务全链路观测面临多维挑战：传统 JNDI 远程调用链路黑盒化、微服务网关的分布式追踪断层、大模型推理的计算图可视化缺失等异构技术栈的观测鸿沟。
通过引入ARMS（应用实时监控服务）构建统一可观测性平台，可实现跨越J2EE遗留系统、微服务架构及AI计算引擎的全栈式追踪能力。该方案有效穿透 EJB 服务调用、微服务调用、大模型推理计算等多业务的技术壁垒，为订单交易等核心业务提供从传统事务处理到智能决策的端到端透视，破解"技术代际断层"导致的系统可观测性盲区问题，构建面向混合技术生态的全域观测中台。
第三章 实战：基于 EDAS 三步开启 J2EE 的智能涌现
第一步：代码中注入智能化相关能力
先配置相关的参数：
<!-- 智能服务声明式配置 -->
<Resource name="modelClient"
auth="Container"
type="com.alibaba.ai.ModelClient"
factory="com.alibaba.ai.ModelClientFactory"/>
再引入相关业务代码：
// 老张（15年J2EE经验）与小李（AI工程师）的协作新范式 public class HybridDeveloper { @EJB // 传统技能 private OrderSystem legacySystem;// 新质生产力
@Resource(name=“modelClient”)
private ModelClient client;@Prompt(name=“orderProcessor”)
private PromptMessage prompt;
public Future<CompletionResponse> process(Order order) {
return CompletableFuture.supplyAsync(() -> {
// 经典逻辑
legacySystem.validate(order);
// 智能增强
return modelClient.chat().completions(prompt, order);
});
}
}
第二步：在阿里云 EDAS 中选择 AliEE 部署对应的应用
AliEE 脱胎于电商的 AliTomcat ，已在阿里云 EDAS 中正式商业化，除了在阿里云 EDAS 中一键开启之外，目前也支持独立单机部署；在 EDAS 中一键开启的方式如下图：
同时，目前流行的部署形态是将应用服务器嵌入至工程的 FatJar 中，在这种形态下，需要在工程的 POM 依赖中进行 Tomcat （或 Jetty）依赖包的替换，如下所示：
<!-- 第一步：注销原有的 Tomcat 依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> --><!-- 第二步：新增 AliEE 依赖即可 –>
<dependency>
<groupId>io.cloudapp</groupId>
<artifactId>cloudapp-starter-aliee</artifactId>
</dependency>
第三步：在管理控制台中增加模型的配置
在控制台中，输入模型名称、模型地址、Prompt 等参数，如下图所示：
在 AliEE 的管理控制台之上配置好相应的模型参数之后，这些配置将下发至 AliEE 的进程，动态加载刷新后无需重启实时生效。
后记
当每一代技术浪潮到来的时候，政企的痛点之一是担心上一代的信息资产会不会因此成为债务。阿里云通过基础技术的创新，让每个时代的智慧都能在数字世界得以永生。当经典J2EE应用在阿里云应用服务器上绽放出智能之花，这场静悄悄的技术革命正在重新定义企业数字资产的真正价值。