web-services - 将单体服务器应用程序移植到 Web 服务陷阱

Question

有人做过从单体服务器应用程序到服务的移植吗？我需要注意哪些隐藏的“问题”才能准确估算成本？

我们有一个用 Java 编写的现有单线程单体服务器应用程序。它目前运行良好，但我们想开始扩展它。扩展它意味着会有更多的人使用它，而服务器将无法处理额外的负载。这个代码库的开发投资很大，而且代码库很大。多线程服务器的成本将是疯狂的。

我有一个轻率的想法，就是将其分解为逻辑服务组件，将它们从应用程序中移除并将它们托管在 Axis2 或 Tomcat 上，然后将它们推送到 SOA 云中。

我为 Axis2 编写了许多服务，大量使用 SOA 云，并编写了多个单体服务器，这看起来很简单。尽可能多地消除共享状态——然后将其推送到某种数据库，从单体应用程序中提取逻辑服务，重复直到完成。

但我有一种不好的预感，即细节决定成败，我敢肯定我不是第一个有这种想法的人。

Answer 1

我在这些类型的系统/架构迁移中的经验，时间消耗和 killer 往往是:

• 确定所有用例和功能要求。大约 50% 不会被记录下来。在这 50% 中，50% 是不正确的。在 50% 的文档和正确的文件中，50% 将不再有效。
• 确保向后兼容性。仅仅因为您迁移到新架构通常并不意味着所有客户端都会同时迁移。
• 将现有数据迁移到新的结构/模型/架构中。这总是比你想象的要花更长的时间。就时间/成本而言，假设您可以想象的最坏情况，将其加倍，您仍然会短缺大约一半。
• 访问控制模型。
• 以清晰实用的方式记录您的服务。如果没有人使用，您 Shiny 的新 SOA 架构将不值得蹲下。
• 性能测试。令人难以置信的是，在项目结束时跳过或完成此操作的频率有多高。首先要建立性能场景、测试基础设施和基线值，然后根据它们不断地进行测试和衡量。这对架构师来说就像单元测试对开发人员一样。

如果您不在项目早期解决这些问题，就会导致项目失败、超出预算和超时。