【问题标题】:Migrating a large-scale application from JavaEE to Akka将大型应用程序从 JavaEE 迁移到 Akka
【发布时间】:2014-11-22 15:09:33
【问题描述】:

假设我有一个用 JavaEE(以及与之经典结合的相关技术)编写的非常大规模的服务器端 Web 应用程序,我决定将它完全迁移到 Akka(以及通常与之结合的相关技术,包括将Scala 的代码)。迁移决定的原因并不重要:假设我必须这样做,仅此而已。

我的问题是:这里应该遵循什么策略,以优化迁移时间和生成的应用程序的可扩展性?

如果问题缺乏细节,我可以提供一些,虽然我想听听策略而不是非常具体。

【问题讨论】:

    标签: java scala jakarta-ee web-applications akka


    【解决方案1】:

    这是一个开放式问题。但让我试着给你一些想法。在使用过 J2EE 以及基于 Play2/Akka/Spray.io (Scala) 的系统之后,我可以为您提供以下高级/一般迁移指导。

    对系统进行分区:根据功能对当前系统进行分区,并根据其对业务、利益相关者和客户的重要性对其进行排名。分区可以基于不同的维度(运行时的架构组件、业务特性、开发团队/模块)等。您还需要找到这些分区之间的依赖关系。

    识别候选分区:一旦你对分区进行了排名,选择在尽可能多的维度上重叠且耦合量最少的尽可能小的分区很有用。如果您的初始架构是模块化的,通常就是这种情况。

    实现原型:获取候选分区并创建提供相同功能能力的原型。现在根据各种质量属性(性能、可修改性、可扩展性等)评估和比较新功能与旧功能。该原型还将为您提供技术风险、挑战和工作量的估计。

    创建新架构:我认为此时您应该有足够的输入来创建新架构的第一个版本。还要确定其他分区的功能将如何在这个新架构中实现。选择最复杂的分区并尝试将其映射到这个新架构是非常好的练习,并且可以大大降低您未来的技术风险。

    展示原型:尝试将原型展示给一小部分用户/利益相关者并获得反馈。使用 REST/pub-sub 接口解耦原型是一个好主意。

    迁移计划:为系统的其余部分制定计划和时间表。

    如果您提供更有针对性的问题,我可以更具体。

    【讨论】:

    • 非常感谢您的回复))我明白,但如果您提供一些关于您上面提到的步骤的更多“真实”的东西会非常好。例如,以任何一个众所周知的应用程序为例,并粗略描述应用于该应用程序的上述步骤。有了这个,我会接受你的回答。
    猜你喜欢
    • 1970-01-01
    • 2017-02-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-03
    • 2021-01-30
    相关资源
    最近更新 更多