内容提要
Datalex与AWS合作,通过三天体验式加速工作坊,将核心航空零售系统从EJB/Java 8迁移至Spring Boot/Java 21。四个并行工作流验证了微服务改造、CI/CD安全流水线、可观测性及生成式AI集成。成果包括内存占用降低35%、部署时间从数小时缩短至10分钟内、启动速度提升60%,并建立了可复用的迁移模式,为后续400万行代码的现代化奠定基础。
延伸解读
三天验证可行性:EBA工作坊的加速逻辑
Datalex与AWS的EBA工作坊仅用三天,就完成了从EJB/Java 8到Spring Boot/Java 21的迁移验证。其核心在于并行推进四个工作流:微服务原型、DevSecOps流水线、可观测性及AI概念验证。这种集中式、跨职能的协作模式,将原本需要数周甚至数月的可行性验证压缩到极短时间,并产出了可运行代码和量化结果,为后续大规模迁移提供了决策依据。
渐进式迁移:Strangler Fig模式与业务服务代理
为避免“大爆炸”式切换,Datalex采用Strangler Fig模式,通过业务服务代理在现有n-tier架构和新建Spring Boot微服务之间路由请求。代理根据迁移状态将流量导向旧系统或新服务,使团队能逐个替换组件,同时保持系统稳定。这种架构支持非回归测试和实时验证,确保在迁移过程中不影响航空公司客户的日常运营。
可量化收益:性能提升与成本优化
迁移后,系统内存占用降低35%,部署时间从数小时缩短至10分钟内,启动速度提升60%。这些改进源于Java 21的虚拟线程和优化垃圾回收,以及容器化部署带来的资源效率。此外,自动化扩展减少了手动干预,降低了运维开销。这些量化结果不仅验证了技术可行性,也为后续400万行代码的现代化提供了可复用的模式和投资回报证据。
代理式AI集成:从概念验证到产品机会
通过Amazon Bedrock AgentCore,Datalex构建了多代理编排系统,包含认证、数据检索和报告等专用代理,并集成了自然语言查询预订的对话界面。该概念验证展示了生成式AI如何在不重写核心系统的前提下增强功能。产品团队将评估是否将AI功能作为附加产品提供给航空公司,这可能提升客户自助服务能力并创造新的差异化优势。
Q&A
Datalex 为什么要进行系统现代化?
Datalex 的核心航空零售系统已运行二十多年,基于成熟的 Java 和 EJB2 架构。航空业正转向现代航空零售(报价与订单模式),需要更丰富的集成和 AI 原生体验。Datalex 希望在不中断现有航空公司运营的前提下,更快地交付下一代零售能力,因此启动了 Project Phoenix 现代化路线图。
Datalex 与 AWS 的 EBA 工作坊持续了多久?有多少人参与?
工作坊为期三天,在 AWS 都柏林办公室举行,共有 16 名 Datalex 工程师和 6 名 AWS 专家参与。
EBA 工作坊设置了哪四个并行工作流?
四个并行工作流分别是:1)微服务原型——从 Reservation 组件提取切片并重构为 Spring Boot 微服务;2)DevSecOps 流水线——构建端到端 CI/CD 并嵌入安全扫描;3)QA 与可观测性——实现实时监控和自定义仪表板;4)代理式 AI 概念验证——使用 Amazon Bedrock AgentCore 构建自然语言预订检索界面。
现代化后取得了哪些可量化的性能提升?
内存占用降低 35%,部署时间从数小时缩短至 10 分钟以内,启动速度提升 60%,并实现了基于 CPU 和内存指标的自动扩缩容,无需人工干预。
Datalex 如何在不中断现有系统的情况下逐步迁移?
采用 Strangler Fig 模式,通过业务服务代理(business service proxy)根据迁移状态将请求路由到现有 n 层架构或新的 Spring Boot 微服务。现有组件保持完全运行,直到其替代品经过测试并准备好处理生产流量,从而实现增量迁移而非一次性切换。
代理式 AI 概念验证实现了什么功能?
使用 Amazon Bedrock AgentCore 构建了一个 AI 驱动的自然语言界面,用于预订检索。多代理编排系统包含身份验证、数据检索和报告三个专用代理,通过 Amazon Cognito 保障安全,并与 Kong API Gateway 集成。用户可以用自然语言查询预订数据,代理将查询转换为 API 调用并返回结果。
EBA 工作坊对 Datalex 的业务决策产生了什么影响?
工作坊产出了可工作的代码和可衡量的结果,为董事会投资决策提供了证据。Datalex 董事会批准了重大技术现代化投资,原型老虎团队扩展为全职敏捷团队,EBA 还带来了可观的预算用于系统重建工作,并设定了每季度面向高管的 KPI。
从这次现代化项目中可以总结出哪些经验教训?
三条经验:1)在规划全面迁移之前,先在一个服务上证明可行性;2)迁移发生时团队必须在场,因为文档无法捕捉关键决策;3)在迁移过程中就加入安全和监控,而不是事后补充。