java - Struts 1到 Spring 迁移-策略

Question

我有一个用Struts 1 + JSP编码的旧版银行应用程序
现在的要求是将后端（现在为MVC）迁移到Springboot（MVC）。
以后的UI（JSP）将迁移到angular。

注意事项

1.）后端不是无状态的

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

方法


有2个并行运行的应用程序（Struts和Spring），并在两者之间共享会话对象，即，将会话存储在数据库中，在内存中（Redis）等。这意味着大量代码更改，因为当前会话是跨JSP层进行操作的，动作，每次更新/获取的服务
构建完整的Spring应用程序，然后将其启用，这再次不可行，我们不能让用户等待。
在同一应用中将Struts 1和Spring结婚，然后离婚，并逐步删除struts组件。


题

将Struts 1和Spring放在同一个Web应用程序中是否可行。
如果我有2个不同的spring和strut上下文路径，可以使用2个不同的servlet（ActionServlet和DispatcherServlet同时存在）吗？

当前的重点是迁移MVC层，服务层将不是问题。

另外，如果我将来需要保留API的后端设计以支持REST，那么如果我可以采用这种方式进行设计，那是可能的。

当前

JSP-> Struts 1 MVC->服务层-> DB

我们可以建立的

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

未来

只需删除JSP-> Struts MVC

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

Answer 1

我的朋友，很高兴阅读您的问题！我生活在相同的地狱，您将使用相同的堆栈进入...

方法3

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

迁移时，您希望将对遗留代码的工作保持在最低限度，如果可能的话，尽量不要进行。

方法2

完美的选择，但是正如您所说，它不会付账。如果您有足够的现金去做，那就太好了，否则，您就...

方法1

勒死，这对我有用。首先使用有效的共享登录名，然后再转到小功能。想想一棵树，首先要删除一些小树枝，然后将它们移到节点，直到可以切割所有东西为止。当您删除这些小功能时，应该在新产品上使用它们（显然，您不能中断服务，否则您将采用方法2）。

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

后端

1）使登录工作。就我而言，遗留问题全与会话有关，但我们不希望在新产品中使用。因此，我们在登录时在旧代码上实现了一个方法，该方法将从新产品中调用Oauth并将登录信息存储在数据库中，就像您提到的那样。原因是在我回复的前端。

2）定义您的旧版和后端将如何一起生活，以及使它们两者都能正常工作的资源（更准确地说是RAM和CPU）。

2.1）如果您的旧版软件在带有自定义库的tomcat上运行，那么您可能会在不同的上下文中运行新产品时遇到问题。如果发生这种情况，我的建议是选择Docker（请仔细查看内存使用情况，并确保将其限制在您的容器上）。

3）从很小的地方开始，替换与创建新东西相关的功能，这些东西几乎没有逻辑（小巧的东西，例如用户等），然后转移到具有中等逻辑或在旧产品上确实丑陋且最终用户每天使用。

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

5）请勿仅将此项目视为迁移。在页面上让所有人都知道这是一种新产品。不应复制和粘贴旧代码，应使用最佳实践加以理解和改进。

5.1）单元和集成测试（如果您的遗留系统有GREAT，请尽快）比较结果，以确保您的重构不会破坏任何内容或更改预期的输出。这是必不可少的。

前端

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

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

2）从头开始定义样式。不要像后来的团队那样将UI / UX的工作推迟到以后。您越早发现颜色，设计，图标等问题，您在会议上浪费的时间就越少，这些会议应该讨论发布及其影响，而浪费在讨论“这不是我想要的颜色”或类似的东西上。老实说，在UI之前定义UX，并使其清晰可见。

3）像在设计微服务前端一样进行设计。您可能需要花费很多时间才能做到这一点，但是如果这样做的话，从新架构到微服务的迁移所受的痛苦将大大减少。

文化

我不知道您的工作场所的文化，但是我的远非完美，那些怀着旧思想进入舒适区的老人。

改变工作场所的文化以适应我们目前在市场上的情况，老年人有时倾向于抵制变革，尤其是在技术娴熟且不了解最新信息的情况下。当人们离开公司时，这将使更换人员变得容易得多（因为人们确实会继续前进）。

我听说他们仍在尝试运行Scrum（正如我提到的那样，我已经不在了），所以开发人员在定义功能迁移的方式和方式时遇到了巨大的麻烦。

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