我有一些问题，希望有人可以回答我。
我们的情况是，我们正在考虑对现有系统进行彻底更换。首先，我将描述我们现有的系统。
我们目前正在使用纯对象堆栈。环境是OO，数据库是OO。我们目前拥有3-4百万行代码，由2-3人开发，目前我们有一个6人的开发团队，并且还在不断发展。最初的开发始于1997年，我们安装了许多客户端。环境是64位，语言和数据库，多语言，并且是UNICODE。我们使用的操作系统是Windows（最新版本）。我们有许多模块通过瘦客户端（不是浏览器）提供，带宽使用率非常低（在64KB WAN网络性能水平上运行，这在我们运营的一些国家仍然很普遍，即基础设施很差）。我们最大的实施是针对世界上最大的公司之一，目标是从该客户的一个系统实例（一个物理数据库）为30多个国家/地区提供功能，并使用瘦客户端向所有国家/地区提供功能。一组应用程序服务器（应用程序服务器与数据库服务器一起定位并执行所有处理），瘦客户机处理与用户的交互以及数据的显示和数据的收集。该系统由瘦客户机上的1000个用户使用。我们还有移动和门户组件，它们是用C＃开发的，它们是整个系统的一小部分，并使用APis连接。可能有1000个移动应用程序用户，预计最终数量为5000个移动用户。在该系统内，将有500,000-1000000个供应商，每个供应商预计每天至少有两笔交易。
数据库本身已分区，并实时复制到多个位置。实现完成后，DB的最终大小预计在2TB范围内，当前系统将处理这个问题，没问题。复制的工作方式是在热备份上有多个复制的环境，即e。复制所有应用程序服务器和API服务器。我们最大的客户端（每月一次）执行预定的Windows更新，当发生这种情况时，主要环境会自动转移到辅助环境，因此系统始终可用。在随后的几个月中，系统回滚到初选，这种转变非常快，即实时。
在我们最大的客户端，该系统于2014年安装，从那时起它没有经历任何中断，除了计划中断，因为在那个时间段内服务器维护了whateveer，即它没有崩溃或出现故障。前三年的运作。为了向目标组织提供更新和增强功能，或者特别是在其运营所在国家/地区提供补贴，我们可以通过在线加载功能更新来对系统进行更改。这是我的问题中非常重要的组成部分，因为多年来我们能够在一个中心位置进行更新，并且在他们不断使用该应用程序的同时，所有国家/地区的所有用户都可以立即使用新功能。这不会更改任何.EXE或.DLL或最终用户正在操作的任何文件。这对我们来说是一个巨大的优势，因为我们提供服务的许多组织都不允许对最终用户设备上的EXE或DLL文件进行任何更改，并且通常有一些批准过程需要几天时间并需要人工干预用户使这一过程发生。
如需进一步信息，我们有一个由6人组成的支持团队，为所有这些国家的所有客户提供支持服务，我们提供三班制的2人轮班提供这些服务。因此，这应该为您提供系统稳定性和我们提供的支持级别的一些背景知识。我们的服务水平被描述为杰出的。我们当然有SLA协议，我们没有违反任何SLA条款。
所以，现在我的问题。人们会选择哪种技术来取代这样一个系统，以及需要多少人才能更换？我建议使用C＃和SQL服务器来取代它，并且需要一两年好的人才能从头开始重新开发（我们拥有最后的所有功能规范）从事工作20年。但是，如果没有对这个技术堆栈的深入了解，我非常关注时间段（我认为它非常乐观），我担心SQL服务器的可扩展性，最重要的是我担心我们会松动我们享受的这一优势使我们能够通过在线更新来更改当前系统的功能，而不会影响登录用户。我被告知这种事情在C＃中是不可能的，如果我们必须提供更新来修复错误或提供新功能，那么所有用户都必须替换受影响的EXE和DLL文件，即所有这些文件，每次我们更新时，1000个用户都必须这样做。这将通过一个名为OneClick的过程自动完成，但我假设如果我们的客户端环境中有一个公司策略不允许EXE更改，那么OneClick将不可行。我被告知如果我们采用浏览器方法进行新开发，那么任何更新都将是服务器端（这是更好的），但是，仍然需要中断来应用更新。
最后，有关现在可能的在线更新的更多信息。目前，所有系统都被复制用于灾难恢复，并在更新期间100％正常运行。当我们当前更新我们的系统（在一个中心位置）时，这些逻辑更新将自动应用于所有复制系统，而无需用户干预。我所担心的另一个问题是，我们在使用相同的更新来更新多个位置时遇到的问题，这似乎是C＃的要求，或者我被告知，我们还将手动更新所有复制的系统同样。正如您所看到的，我们的支持团队规模很小，所以我担心维护所有这些所需的维护资源将来会爆发，然后是修复可能会出现的所有这些额外任务可能出现的错误的成本。需要执行我们目前只执行一次的相同练习。
最后，关于我们目前如何进行更新的最后信息。如果更新本质上是结构性的，即更改数据库的物理结构，则需要中断，完全系统停机。当我们应用更新时，会进行结构更改，并且会自动在所有辅助环境（备用环境）中复制。用户不受瘦客户端或浏览器软件的影响。他们只需在停电完成后重新登录。我们目前在设定的时间有一个窗口，每月一次执行这些更新，但是，它很少需要。每周一次，我们有一个应用功能更改的窗口，这些窗口在线应用，同时用户都在线执行日常和定期任务。
所以，如果那里的任何人能够让我深入了解这种系统替换可用的技术，或者C＃和SQL服务器是否能提供我们实际需要的必要服务和性能，即我会特别感兴趣知道是否实际上C＃应用程序可以实时更新，那将是非常棒的。在这个过程的早期阶段，我们显然应该如何做到这一点，因此您可以提供的任何信息都将受到高度赞赏，并将节省数小时的研究。
提前谢谢。
答案 0 :(得分：1)
根据您描述的基本要求，我首先想到的是您应该为您的系统采用完整的基于Web的解决方案，这样所有更新都可以集中完成，而不会对您的客户端访问产生太大的负面影响。
但如果我理解你的问题，你需要的一个方面就是在客户端准备好可执行代码（因此纯粹的Web解决方案不起作用）。
在这种情况下，可以迅速和需要在客户端轻松更新。
我们已经使用了node.js和MongoDB堆栈几年了，对于你的业务逻辑使用纯脚本有一些非常有趣的效果：除了易于开发，脚本本身，当设计有一定的时候准则，可以动态执行“热重载”以更新您的业务逻辑。所以这就是我建议尝试/看的东西。
如果您进行简单的Google搜索，很多地方都会详细描述node.js的效率和NoSQL DB提供的灵活性，例如MongoDB。