我有一个用 Struts 1 + JSP 编码的旧版银行应用程序
现在的要求是将后端（现在为MVC）迁移到 Springboot（MVC）。
以后的UI（JSP）将迁移到angular。
注意事项
1。）后端不是无状态的
2。）大量数据存储在会话对象中
方法
使 2应用程序并行运行（ Struts和Spring ），并在两者之间共享会话对象，将会话存储在数据库，内存（Redis）等中。这意味着需要进行大量代码更改，因为当前会话是针对每次更新/获取
构建完整的Spring应用程序，然后将其启用，这又不可行，我们不能让用户等待。
在同一应用中结婚Struts 1和Spring，然后离婚，并逐步删除struts组件。
问题
将Struts 1和Spring放在同一个Web应用程序中是否可行。
如果我有2个用于spring和struts的上下文路径，则可能有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
答案 0 :(得分：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（正如我提到的那样，我已经不在了），所以开发人员在定义功能迁移的方式和方式时遇到了巨大的麻烦。
那是我的两分钱，希望它们能以某种方式帮助您，祝您好运。
答案 1 :(得分：1)
由于业务可行性，选项2并不重要，让我们来谈谈其他两个。
方法1
如果您将会话状态推回适当的数据存储区（Redis / Memcache）并使用透明机制来获取 会话数据并更新应用服务器所做的任何更改，则您无需更改与会话进行交互的任何代码。 从应用程序中的任何代码获取会话对象的任何调用都委托给容器，并且该容器是 为您提供对象（通常会维护sessionid和object的映射）。对于诸如Tomcat之类的容器，我知道 会话管理器，可以通过将jar放入容器并将配置指向后端存储来替换。我用过 基于memcache的会话管理器已成功用于高流量Internet应用程序的生产中。 检查以下内容是否为Redis（https://github.com/pivotalsoftware/session-managers）和Redisson Tomcat管理器（https://github.com/redisson/redisson/tree/master/redisson-tomcat），Memcache（https://github.com/magro/memcached-session-manager） 使用此选项将透明地在各个数据存储区中获取/存储会话，而无需更改应用程序中任何与会话相关的代码。
因此在cookie中具有会话ID的请求可以在任何tomcat（托管Struts或Spring MVC应用）上获取，并获得会话 从后端存储中获取，进行更改并透明地存储回去。
方法3
从技术上讲是可能的（它们毕竟是具有不同配置的所有不同servlet响应不同的url模式） 但在以下方面开辟了很多问题领域 依赖关系会引起冲突。但是，如果您在迁移过程中冻结了两个框架的库版本，以某种方式都无法获得任何版本 与您的混音的某些版本发生冲突，那么值得尝试一下，因为最终struts库及其依赖关系将消失。
对于Angular部分-您仍然可以在会话中保留用户信息，并且需要设计其余的有状态交互 在一系列无状态（中间层为无状态，最终您将需要一些状态-只是将其推送到数据库）交互中。