时间戳

首页 > 解决方案 > Struts 1 到 Spring 迁移 - 策略

java - Struts 1 到 Spring 迁移 - 策略

问题描述

我有一个用Struts 1 + JSP编码的遗留银行应用程序 现在的要求是将后端（现在是 MVC）迁移到(MVC)。稍后 UI (JSP) 将迁移到.Springbootangular

注意事项

1.) 后端不是无状态的

2.) 大量数据存储在会话对象中

方法

  1. 有2 个应用程序并行运行（Struts 和 Spring），并在两者之间共享会话对象，将会话存储在数据库中，内存中（Redis）等。这意味着大量代码更改，因为当前会话是跨 JSP、动作、服务层操作的，每次更新/获取

  2. 构建完整的 Spring 应用程序，然后使其生效，这又是不可行的，我们不能让用户等待。

  3. 将Struts 1 和 Spring 在同一个应用程序中结合，然后将它们离婚，并逐步删除 struts 组件。

问题

将 Struts 1 和 Spring 放在同一个 Web 应用程序中是否可行。可以 2 个不同的 servlet（ActionServlet&DispatcherServlet一起存在），如果我有 2 个用于 spring 和 struts 的不同上下文路径，则可能

目前重点是迁移MVC层，服务层不会有问题。

此外，如果我需要保留API 的后端设计以支持 REST，如果我可以以这种方式进行设计，则可能。

当前的

JSP -> Struts 1 MVC -> 服务层 -> 数据库

我们可以建造什么

JSP -> Struts 1 MVC <-> JSON 对象解析器 <-> Spring REST MVC -> 服务层 -> DB

未来

只需删除 JSP -> Struts MVC

Angular（或任何其他框架）-> Spring REST MVC -> 服务层 -> DB

标签： javaspring-bootspring-mvcmigrationstruts-1

解决方案

我的朋友，很高兴看到你的问题！我生活在你即将进入的同一个地狱里，使用的是同一个堆栈......

方法 3

老实说，我永远不会尝试。原因很简单，我们不希望有旧项目和新项目相互混合的风险。遗留库很可能与新项目中的库（相同库，不同版本）发生冲突，然后您需要重构旧代码以允许使用新版本，或者完全更改库。

迁移时，您会希望尽量减少对遗留代码的工作，如果可能的话，尽量不要。

方法二

完美的，但正如你所说，它不会支付账单。如果你有足够的钱来做这件事，那就太好了，去吧，否则，你就是……

方法一

扼杀，这对我有用。从有效的共享登录开始，然后转向小功能。想象一棵树，你首先移除一些小树枝，然后将它们移动到节点，直到你能够切割所有东西。当您删除小功能时，它们应该在新产品上可用（显然您不能中断服务，否则您将采用方法 2）。

更具体地说，我的建议是：

后端

1）让登录工作。在我的例子中，遗留的一切都是关于会话的，但我们不希望在新产品上出现这种情况。因此，我们在登录期间对遗留代码实现了一个方法，该方法将从新产品中调用 Oauth 并将登录信息存储在数据库中，正如您提到的那样。原因在我回复的前端部分。

2) 定义您的遗留系统和后端将如何共存，以及让它们同时工作的资源（更准确地说是 RAM 和 CPU）。

2.1) 如果有任何机会，您的遗留系统在带有自定义库的 tomcat 上运行，您可能会在不同的上下文中运行新产品时遇到问题。如果发生这种情况，我的建议是使用 Docker（只需仔细查看内存使用情况，并确保将它们限制在容器中）。

3）从很小的地方开始，替换与创建几乎没有逻辑的新东西相关的功能（小杂物，例如用户等），然后转移到具有中等逻辑或在遗留产品上非常难看的东西，并且是由您的最终用户日常使用。

4）其余的（我离开公司时，我们还没有进入这个阶段，所以我不能提供太多信息）。

5）不要将此项目仅视为迁移。让每个人都在这个新产品的页面上。旧代码不应该被复制和粘贴，应该使用最佳实践来理解和改进。

5.1) 尽快进行单元和集成测试，如果你的遗留系统有它们，那太好了，比较结果以确保你的重构没有破坏任何东西或改变预期的输出。这是必不可少的。

前端

1）一旦“统一”登录工作，您将能够从新产品加载页面，就好像它们是旧产品的一部分一样（您甚至可以在旧产品的 jsp 上添加一个框架来加载您的角度页面，我们做到了，它就像一个魅力）。

1.1) 从 UI/UX 的角度来看，拥有新旧页面并不可爱，但它会为最终用户增加价值，并在您将这些作品发布到生产环境后为您提供反馈。由于您的遗产现在可以访问令牌（或您使用的任何身份验证方法，这将是可行的）。

2) 从一开始就定义样式。不要把 UI/UX 的工作拖到以后（就像我的团队所做的那样）。你越早弄清楚颜色、设计、图标等，你在应该讨论版本及其影响的会议上浪费的时间就越少，但浪费在讨论“这不是我想要的颜色”或类似问题上。老实说，在 UI 之前定义 UX 并使其一目了然。

3) 像设计微服务前端一样进行设计。您可能需要花费大量时间才能达到这一点，但如果您这样做了，那么从新架构迁移到微服务的痛苦就会小得多。

文化

我不了解你们工作场所的文化，但我的工作场所文化远非完美，老人们在他们的舒适区里有陈旧的想法。

改变工作场所文化以适应我们目前在市场上拥有的东西，老年人有时倾向于抵制改变，特别是当他们是技术人员并且不更新那里的新事物时。当他们离开公司时更换人会更容易（因为人们确实会继续前进）。

我听说他们仍在尝试运行 Scrum（正如我所提到的，我不再在那里），所以对于定义功能迁移将发生什么以及如何进行的开发人员来说是一个巨大的头痛。

那是我的两分钱，希望它们能以某种方式帮助你，并祝你好运。

推荐阅读