Architecture 正在寻找重组复杂web应用程序以简化升级的建议

我正在处理一个复杂的系统，它有几十年的历史。它过去是一个客户端/服务器调度应用程序，但现在变得更复杂了。最初，每个客户都有自己的实例，在自己的服务器上运行。现在，我们有一些客户仍在这种模式下运行，但也有一些客户在软件即服务模式下运行，即所有应用程序都在我们的服务器上运行。我们还增加了web界面，我们有数百名客户仅通过web访问他们的系统

由于目前存在，系统的每个安装包括：

• 数据库：其中几乎每个记录都有一个以“customerid”开头的主键，因此多个客户可以在同一个数据库上运行
• 安装目录：SAN上的一个目录，其子目录中包含可执行文件、日志文件、配置文件、基于磁盘的队列，以及系统中几乎所有与网站无关的内容
• 后台应用程序：一组应用程序，位于安装目录的子目录中，但可能运行在一个或多个应用程序服务器上，负责与各种非现场系统、移动用户等通信。它们可以配置为作为Windows服务运行，或从命令行运行
• 客户端应用程序：另一组应用程序，位于同一子目录中，但运行在任意数量的用户机器上，管理员和调度员可以与系统交互，向各种移动用户分派工作，运行已完成工作的报告等
• web应用程序：两个网站/应用程序/服务，允许调度用户执行某些调度功能，并允许移动用户从任何web浏览器完成分配的工作。通常，网站和系统安装之间存在多对一关系。我们将在多个服务器平台上配置多个站点，以针对系统的任何特定安装运行，并使用负载平衡器在它们之间分发传入用户

我们有十几个不同的安装，每个都有一到几百个客户。（每个客户的用户数从少数到数百。）

旧的后台应用程序是用非托管C++编写的，C语言中更新了。客户端应用程序是用VB6编写的，它是针对非托管C++编写的COM对象运行的。网站和服务是用C#编写的ASP.NET和ASP.NET/MVC

显然，这些年来，它变得相当复杂，有很多部分和很多相互关系。它仍然有效，而且效果很好，这让我感到惊讶。20年前，当我们第一次设计开始时，让我觉得我们做得还不错。但是

目前，我们最大的问题是安装更新和升级所需的工作量。系统的大部分是解耦的，因此我们可以毫无困难地更改一个通信程序，或修复一个网页等。但是对数据库模式的任何更改几乎都要求进行系统范围的更改。这需要花费大量时间，影响到许多客户，并涉及重大风险。因此，修复的实施会被延迟，这使得我们进行升级时的风险更高，这会导致更多的延迟，并且通常会损害我们的响应能力

所以，我正在寻找关于我们可能进行的架构更改的建议，这将使升级的风险和成本降低

在我的理想世界中，我们永远不会升级正在运行的安装，我们会并行安装升级，并对其进行测试，一旦我们确信它能正常工作，我们就会将客户从旧系统转移到新系统，一次一个，然后随着我们信心的增强，再将其批量转移。如果情况不好，我们可以让客户回到旧系统。但我看到了一些问题：

在用户登录之前，我们不知道他属于哪个客户

将用户从一个系统移动到另一个系统需要复制数十万条数据库记录，并在此过程中应用模式更改

将自定义从一个系统移动到另一个系统需要复制谁知道我们基于磁盘的队列中有多少文件，以及其他各种支持文件

我认为后退是必要的。但这将更加困难

我们所拥有的正在发挥作用，但效果不好。我希望得到一些建议

---

确切地说，我并不是在寻找答案，而是在寻找更多关于去哪里寻找的想法。有人知道我在哪里可以找到关于如何处理这种规模的结构化系统的信息吗？

您提到过子系统是隔离的，所以我想更换/升级组件不是很成问题。主要的痛点似乎是db的变化。这是因为您在SAAS环境中使用的是共享数据库模型。对于SAAS应用程序，建议的数据库模型按高度灵活到最低灵活的顺序为：

每个客户都有单独的数据库，共享数据库但不同 模式，共享数据库共享模式

而问题是由于第三种模式。它是最便宜的，但刚性很高

为了解决这个问题，每个客户都可以使用不同的数据库或模式实例。 这可以一次为少数客户完成。例如，对于客户A，根据选择创建不同的db/schema。导出该客户id的所有记录并填充到新架构中。开始将新客户路由到新DB，您仍然可以返回到旧DB

一般来说，对于web服务，最好

使用路由器来调用真正的Web服务

我想，它可能已经到位了。因此，客户实际上调用路由器服务，该服务将路由到适当的web站点