阿里云应用服务器:助力传统J2EE应用平滑升级AI原生

阿里云应用服务器助力传统J2EE应用无缝升级AI原生,解决协议、资源、观测等难题,实现智能化转型。

原文标题:破茧成蝶:传统J2EE应用无缝升级AI原生

原文作者:阿里云开发者

冷月清谈:

本文深入探讨了传统J2EE应用在智能化转型过程中面临的挑战,例如协议鸿沟、资源冲突和观测失明等问题。针对这些痛点,阿里云应用服务器通过独创的“渐进式容器化”技术和智能中枢架构,实现了EJB组件与微服务体系的互通,并无缝集成了大模型能力。同时,借助ARMS构建了统一可观测性平台,解决了跨越J2EE遗留系统、微服务架构及AI计算引擎的全栈式追踪难题,为企业提供了从传统事务处理到智能决策的端到端透视。此外,文章还详细介绍了基于EDAS三步开启J2EE应用智能涌现的具体实施步骤,包括代码注入智能化能力、选择AliEE部署应用以及在管理控制台中增加模型配置等。

怜星夜思:

1、文章中提到“渐进式容器化”技术,这种技术具体是如何在保证原有系统稳定性的前提下,实现EJB容器与微服务体系互通的?有哪些实际案例可以分享?
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 实现与主流大模型的标准化对接)

三大创新设计:

  1. 模型沙箱环境隔离大模型推理线程池资源,减轻 AI 业务对传统业务的影响

  2. 请求限流引入 Model Filter ,根据 Token 进行请求限流

  3. 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应用在阿里云应用服务器上绽放出智能之花,这场静悄悄的技术革命正在重新定义企业数字资产的真正价值。



问:文章提到通过ARMS构建统一可观测性平台,解决了跨技术栈的追踪难题。在实际应用中,如何有效地利用这些追踪数据进行故障定位和性能优化?

这就像医生看病,ARMS提供了各种检查报告(链路追踪、metrics、logs),但怎么诊断还得靠经验。我的建议是:

1. 建立基线:先了解系统正常状态下的各项指标是什么样的,这样才能发现异常。
2. 分层分析:从宏观到微观,先看整体调用链,再深入到具体服务,最后定位到代码行。
3. 关联分析:把链路追踪数据和日志、metrics关联起来,综合分析,才能更准确地找到问题根源。

性能优化方面,可以利用追踪数据发现慢查询、高延迟服务,然后针对性地进行优化,比如加缓存、优化SQL、升级硬件等等。

问:文章中提到J2EE应用通过阿里云应用服务器可以接入DashScope SDK,从而实现与大模型的互通。那么,在实际应用中,如何选择合适的大模型,并根据业务需求进行Prompt优化,以获得最佳的智能化效果?

模型选择方面,要考虑三个因素:

1. 模型能力:是否满足业务需求?比如,需要生成高质量的营销文案,就要选择擅长文本生成的模型。
2. 模型成本:是否在预算范围内?不同的模型收费标准不同,要根据实际情况选择。
3. 模型稳定性:是否稳定可靠?要选择经过验证、有良好口碑的模型。

Prompt优化方面,要遵循“清晰、简洁、具体”的原则,避免歧义和冗余。可以采用一些Prompt工程技巧,比如Few-shot learning、Chain-of-thought等等。更重要的是,要不断迭代优化,通过A/B测试来评估Prompt的效果。

问:文章中提到J2EE应用通过阿里云应用服务器可以接入DashScope SDK,从而实现与大模型的互通。那么,在实际应用中,如何选择合适的大模型,并根据业务需求进行Prompt优化,以获得最佳的智能化效果?

我理解的重点在于“业务需求”。首先要明确,引入大模型是为了解决什么问题,提升哪些指标。然后,再根据这些需求,去评估不同大模型的表现。可以先做一些小范围的POC(Proof of Concept),对比不同模型的实际效果。Prompt优化方面,要多做实验,不断调整Prompt的措辞和格式,看看哪个Prompt能让模型更好地理解我们的意图。这其实是一个不断学习和迭代的过程。

问:文章中提到“渐进式容器化”技术,这种技术具体是如何在保证原有系统稳定性的前提下,实现EJB容器与微服务体系互通的?有哪些实际案例可以分享?

我的理解,渐进式容器化有点像给老房子加装电梯,尽量不破坏原有结构。技术上,可能涉及到协议适配、服务发现、流量路由等多个方面。关键是要做好监控和回滚预案,确保万一出现问题,能够快速切换回老系统。

现实中,很多大型企业都在用类似的方法。比如,一些传统制造业企业,为了实现智能制造,需要把老旧的生产管理系统与新的物联网平台连接起来。这时候,就可以用渐进式容器化,逐步把一些数据接口和业务逻辑迁移到容器平台上,实现新老系统的协同工作。

问:文章中提到“渐进式容器化”技术,这种技术具体是如何在保证原有系统稳定性的前提下,实现EJB容器与微服务体系互通的?有哪些实际案例可以分享?

渐进式容器化,我的理解是相当于给老系统做了一个翻译器,让它能和新时代的微服务对话。底层可能是通过协议转换、服务代理等方式,把EJB请求翻译成微服务能理解的REST或者GRPC,反之亦然。就好比给古代的圣旨翻译成了现代汉语,意思不变,但表达方式更先进。

实际案例这块,可以想象一下银行的老核心系统,如果一次性全盘推翻重写,风险太大。但如果用渐进式容器化,就可以逐步把一些非核心业务迁移到微服务上,同时保证核心交易的稳定。 比如说,把用户积分查询这个模块先“翻译”成微服务,用户体验升级了,老系统也不受影响。

问:文章提到通过ARMS构建统一可观测性平台,解决了跨技术栈的追踪难题。在实际应用中,如何有效地利用这些追踪数据进行故障定位和性能优化?

我觉得要结合实际业务场景来分析。比如说,如果是电商系统,可以关注订单支付链路的追踪数据,看看哪个环节耗时最长,是不是支付接口有问题。如果是金融系统,可以关注交易链路的追踪数据,看看有没有异常交易或者安全风险。总之,要根据不同的业务场景,制定不同的监控策略和分析方法。

问:文章中提到J2EE应用通过阿里云应用服务器可以接入DashScope SDK,从而实现与大模型的互通。那么,在实际应用中,如何选择合适的大模型,并根据业务需求进行Prompt优化,以获得最佳的智能化效果?

选择大模型就像选演员,要看“演技”(模型能力)和“片酬”(调用成本)。不同的模型擅长的领域不同,有些擅长文本生成,有些擅长图像识别。要根据自己的业务需求选择合适的模型。Prompt优化更像是给演员写剧本,好的Prompt能引导模型给出更准确、更有用的答案。要不断尝试和调整Prompt,才能达到最佳效果。

说个玩笑话,Prompt工程师以后会不会成为热门职业?专门负责和大模型“沟通”的。

问:文章提到通过ARMS构建统一可观测性平台,解决了跨技术栈的追踪难题。在实际应用中,如何有效地利用这些追踪数据进行故障定位和性能优化?

我的经验是,光有数据还不够,关键是要把数据用起来。首先,要建立完善的告警机制,根据追踪数据设置合理的阈值,一旦超过阈值就立即告警。其次,要学会分析调用链,找到性能瓶颈。比如说,如果发现某个EJB服务的调用耗时很长,就可以重点关注这个服务,看看是不是数据库查询太慢或者代码逻辑有问题。最后,要持续优化,不断调整系统参数和代码,提高系统的整体性能。

问:文章中提到“渐进式容器化”技术,这种技术具体是如何在保证原有系统稳定性的前提下,实现EJB容器与微服务体系互通的?有哪些实际案例可以分享?

“渐进式容器化”的核心在于“渐进”二字,它不是一蹴而就的革命,而是一种温和的演进。具体实现上,我觉得可以类比软件开发的“接口适配器模式”,通过适配层来兼容不同的技术体系,避免对原有系统造成大的冲击。说白了就是新老系统之间加个翻译,互相理解对方的语言。

实际案例的话,可以参考大型电商平台的“商品推荐”系统。早期可能是一个基于J2EE的单体应用,但随着业务发展,需要引入更灵活的推荐算法。这时,就可以用渐进式容器化,把推荐算法服务改造成微服务,并通过适配器与原有的商品数据接口对接。这样既能提升推荐效果,又能保证商品数据的稳定性。