寻找有关重组复杂Web应用程序的建议，以便更容易升级

Question

我正在使用一个复杂的系统，它背后有几十年的历史。它曾经是一个客户端/服务器调度应用程序，但它变得更复杂。最初，每个客户都有自己的实例，在自己的服务器上运行。现在，我们有一些仍在这种模式下运行的客户，但我们有一些人正在以软件即服务模式运行 - 所有应用程序都在我们的服务器上运行。我们已经添加了Web界面，我们有数百个客户只通过网络访问他们的系统。

目前，系统的每个安装都包括：

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

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

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

很明显，多年来它变得非常复杂，有很多部分和很多相互关系。它仍然有效，并且效果很好，让我感到惊讶。当我们20年前开始构建初期时，让我觉得我们并没有做得太糟糕。但...

此时，我们最大的问题是安装更新和升级所需的工作量。大部分系统都是分离的，因此我们可以毫不费力地更改一个通信程序，或修改网页等。但是，对数据库模式的任何更改都要求对系统进行全局更改。这需要很长时间，并影响到许多客户，并且涉及重大风险。因此，修复程序的实现会延迟，当我们进行更高级别的升级时会产生风险，从而导致更多延迟，并且通常会损害我们的响应能力。

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

在我理想的世界中，我们永远不会升级正在运行的安装，我们会并行安装升级，测试它，一旦我们确信它正在运行，我们就会将客户从旧系统转移到新的，一次一个，然后随着我们越来越自信而散装。如果事情不起作用，我们可以将客户推回旧系统。但我看到了一些问题：

1. 我们不知道用户在登录之前属于哪个客户。
2. 将用户从一个系统移动到另一个系统涉及复制数十万个数据库记录，并在此过程中应用架构更改。
3. 将自定义系统从一个系统移动到另一个系统涉及复制谁知道基于磁盘的队列中有多少文件以及其他各种支持文件。
4. 我认为，回滚是必要的。但它会变得更加困难。

我们的工作正在发挥作用，但效果不佳。我希望得到一些建议。

我不是在寻找答案，但更多的是我正在寻找关于在哪里寻找的想法。任何人对我在哪里可以找到有关如何处理这种规模的结构化系统的信息有任何想法？

Answer 1

您已经提到子系统是隔离的，所以我认为更换/升级组件不是很成问题。主要的痛点似乎是数据库的变化。之所以如此，是因为您在SAAS环境中使用共享数据库模型。对于SAAS应用程序，高度灵活到最不灵活的推荐DB模型是：

  

为每个客户分开数据库，共享数据库但不同   schema，共享数据库共享模式。

问题在于第三种模式。它价格最便宜但非常严格。

要解决这种痛苦，每个客户都可以由不同的数据库或模式实例提供服务。 这可以一次为少数客户完成。例如，对于客户A，根据选择创建不同的数据库/模式。导出该客户ID的所有记录并填充到新架构中。开始将新客户路由到新数据库，您仍然可以将旧数据库重新发送回。

一般来说，对于Web服务，

总是更好

  

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

我认为，它可能已经存在。因此，客户实际上调用路由器服务，该服务将路由到客户的适当Web服务。它就像更改路由器上的配置以退回或路由到不同版本或服务的安装一样简单。上述策略可以某种方式应用于不同的子系统。

Answer 2

杰夫，我注意到你在明尼阿波利斯，我也是。我会根据你描述的内容猜测DR或BI的缩写，但只是赃物。凭借为财富50强企业管理75个以上应用程序组合的经验，我知道随着需求的不断发展和技术超越对原始可能性的理解，过去10，20年内会有多疯狂。

对于您的多租户SaaS架构，我不确定您是否会在此获得任何银弹答案，但根据我在创业公司的经验，我们正在构建一个多租户saas Web应用程序平台（水平平台，需要照顾60％的需求，剩下40％由垂直应用程序解决）这是我的智慧之词：

我知道这很困难，但尝试将应用程序功能数据和租户数据绝对分离为两个不同的模式/数据库或其他任何东西。当更改与核心应用程序功能相关并且不会对客户或用户数据产生任何影响时，这将允许您显着减少部署时间和测试要求。基本上，您将不得不让您的团队经历痛苦的​​痛苦，以识别并剥离严格定义应用程序功能（应用程序元数据）的所有表。 一旦实现这一目标，您就必须优化所有开发和测试流程，以分离影响核心应用程序平台功能与垂直应用程序功能与客户数据相关的任务。这就是我们的工作，对我们来说，升级到核心应用程序平台只需要几个小时即可。

...独立

• 核心平台功能数据/元数据
• 垂直应用程序功能元数据和事务数据
• 最后，租户+用户元数据和交易数据

老实说，如果不对现有的景观进行彻底的分析，我无法告诉你如何实现这一目标。祝你好运！