系统更换技术

Question

我有一些问题希望有人能够为我解答。

我们的情况是，我们正在考虑彻底更换现有系统。首先，我将描述我们现有的系统。

我们目前在纯对象堆栈上进行操作。环境是OO，数据库是OO。我们目前有 3-4 百万行代码，由 2-3 人开发，我们目前有 6 人的开发团队，还在继续开发中。最初的开发始于 1997 年，我们安装了许多客户端。环境是 64 位、语言和数据库、多语言，并且是 UNICODE。我们使用的操作系统是 Windows（最新版本）。我们有许多通过瘦客户端（不是浏览器）交付的模块，带宽使用率非常低（在 64KB WAN 网络性能水平上运行，这在我们运营的一些国家仍然很普遍，即基础设施很差）。我们最大的实施是为世界上最大的公司之一，目标是从该客户端的一个系统实例（一个物理数据库）为 30 多个国家/地区提供功能，并使用瘦客户端向所有国家/地区提供功能一组应用服务器（应用服务器位于 db 服务器并执行所有处理），瘦客户端仅处理与用户的交互以及数据的显示和数据的收集。该系统由瘦客户端上的 1000 名用户使用。我们也有移动和门户组件，它们是用 C# 开发的，它们是整个系统的一小部分，并使用 API 连接。可能有 1000 个移动应用程序用户，最终数字预计为 5000 个移动用户。系统内将有 500000-1000000 个供应商，每个供应商预计每天至少有两笔交易。

数据库本身是分区的，并实时复制到多个位置。实现完成后的最终数据库大小预计在 2TB 范围内，当前系统会处理，没问题。复制的工作方式是在hot-standy上有多个复制环境，即复制所有应用程序服务器和 API 服务器。我们最大的客户端定期（每月一次）执行预定的 Windows 更新，当这种情况发生时，主环境会自动滚动到辅助环境，因此系统始终保持可用。在随后的几个月中，系统回滚到初选，这种转变非常快，即实时。

在我们最大的客户中，系统是在 2014 年安装的，从那时起，它没有出现任何中断，除了由于那段时间服务器维护而导致的计划中断，即它没有崩溃或出现故障。运营的前三年。为了向目标组织或特别是其在其运营所在国家/地区的子公司之一提供更新和增强功能，我们能够通过在线加载功能更新来更改系统。这是我的问题的一个非常重要的组成部分，因为多年来我们一直能够在一个中心位置进行更新，并且所有国家的所有用户都可以立即使用新功能，同时他们继续使用该应用程序。这无需更改任何 .EXE 或 .DLL 或最终用户正在操作的任何文件。这对我们目前来说是一个巨大的优势，因为我们提供服务的许多组织不允许对最终用户设备上的 EXE 或 DLL 文件进行任何更改，并且通常有一些审批过程需要几天时间并且需要由用户来完成这个过程。

如需更多信息，我们有一个 6 人的支持团队，为所有这些国家/地区的所有客户提供支持服务，我们实行 2 人三班倒提供这些服务。因此，这应该为您提供系统稳定性和我们提供的支持水平的一些背景知识。我们的服务水平被描述为出色。当然，我们确实有 SLA 协议，而且我们从未违反任何 SLA 条款。

那么，现在回答我的问题。人们会选择什么技术来替换这样的系统，需要多少人来替换？有人建议我用 C# 和 SQL Server 来代替它，并且从头开始重新开发需要几个好人一两年的时间（我们拥有上一期的所有功能规范工作 20 年）。但是，在没有深入了解这个技术栈的情况下，我比较关心时间段（我认为是非常乐观的），我关心 SQL server 的可扩展性，最重要的是我非常关心我们会松动我们享有的这一优势使我们能够通过在线更新更改当前系统的功能，而不会影响已登录的用户。我被告知这种事情在 C# 中是不可能的，如果我们必须提供更新来修复错误或提供新功能，那么所有用户都必须替换受影响的 EXE 和 DLL 文件，即所有这些文件，每次我们更新时，成千上万的用户都必须这样做。这将通过一个名为 OneClick 的过程自动完成，但我假设如果我们的客户端环境中存在不允许 EXE 更改的公司政策，那么 OneClick 将不可行。有人告诉我，如果我们对新开发采用浏览器方法，那么任何更新都将是服务器端的（这更好），但是仍然需要中断才能应用更新。

最后，关于现在可能的在线更新的更多信息。目前，所有系统都被复制用于灾难恢复和更新期间 100% 的正常运行时间。当我们当前更新我们的系统（在一个中心位置）时，这些逻辑更新会自动应用于所有复制的系统，也无需用户干预。我担心的另一个问题是，除了我们用相同的更新更新多个位置时面临的问题，这似乎是 C# 中的一个要求，或者有人告诉我，我们还将让所有复制的系统手动更新也是。正如你所看到的，我们的支持团队很小，所以我担心未来维护所有这些所需的维护资源会出现井喷，然后是修复错误的时间成本，这些错误可能会随着所有这些额外的任务而蔓延需要执行我们目前只执行一次的相同练习。

最后，关于我们目前如何进行更新的最后一点信息。如果更新本质上是结构性的，即更改数据库的物理结构，则需要中断，即整个系统停机中断。当我们应用更新时，会进行结构更改，并且会在所有辅助环境（备用环境）中自动复制。用户不受瘦客户端或浏览器软件的影响。他们只需在中断完成后重新登录。我们目前有一个固定时间的窗口，每月一次来执行这些更新，但是，很少需要它。每周一次，我们有一个应用功能更改的窗口，这些更改是在线应用的，而用户都在线执行他们的日常和定期任务。

所以，如果有人可以让我了解哪些技术可用于此类系统替换，或者 C# 和 SQL 服务器是否可以提供我们实际需要的必要服务和性能，即我特别想知道是否事实上，C# 应用程序可以实时更新，那真是太棒了。显然，我们正处于这个过程的早期阶段，因此我们将不胜感激您提供的任何信息，并将节省大量研究时间。

提前谢谢你。

Answer 1

根据您描述的基本要求，我的第一个想法是您可能应该为您的系统采用完整的基于 Web 的解决方案，这样所有更新都可以集中完成，而不会对您的客户端访问产生太大负面影响。

但是，如果我正确理解了您的问题，那么您需要的一个方面是在客户端准备好可执行代码（因此纯 Web 解决方案将无法工作）。

在这种情况下，需要可以在客户端快速轻松地更新的东西。

我们已经使用 node.js 和 MongoDB 堆栈几年了，将纯脚本用于您的业务逻辑有一些非常有趣的效果：除了易于开发之外，脚本本身在设计时具有一定的指南，可以即时执行“热重载”以更新您的业务逻辑。所以这就是我建议尝试/查看的内容。

如果您进行简单的谷歌搜索，node.js 的效率和 NoSQL DB（如 MongoDB）提供的灵活性在很多地方都有很好的描述。