我正在使用一个复杂的系统，它背后有几十年的历史。它曾经是一个客户端/服务器调度应用程序，但它变得更复杂。最初，每个客户都有自己的实例，在自己的服务器上运行。现在，我们有一些仍在这种模式下运行的客户，但我们有一些人正在以软件即服务模式运行 - 所有应用程序都在我们的服务器上运行。我们已经添加了Web界面，我们有数百个客户只通过网络访问他们的系统。
目前，系统的每个安装都包括：
我们有十几个不同的装置，每个装置从一个到几百个客户。 （每个客户从少数用户到几百个用户。）
较旧的后台应用程序是用非托管C ++编写的，C＃中较新的。客户端应用程序是用VB6编写的，针对用非托管C ++编写的COM对象运行。网站和服务是用C＃编写的ASP.NET和ASP.NET / MVC。
很明显，多年来它变得非常复杂，有很多部分和很多相互关系。它仍然有效，并且效果很好，让我感到惊讶。当我们20年前开始构建初期时，让我觉得我们并没有做得太糟糕。但...此时，我们最大的问题是安装更新和升级所需的工作量。大部分系统都是分离的，因此我们可以毫不费力地更改一个通信程序，或修改网页等。但是，对数据库模式的任何更改都要求对系统进行全局更改。这需要很长时间，并影响到许多客户，并且涉及重大风险。因此，修复程序的实现会延迟，当我们进行更高级别的升级时会产生风险，从而导致更多延迟，并且通常会损害我们的响应能力。
所以，我正在寻找有关我们可能进行的架构更改的建议，这将使升级风险更低，成本更低。
在我理想的世界中，我们永远不会升级正在运行的安装，我们会并行安装升级，测试它，一旦我们确信它正在运行，我们就会将客户从旧系统转移到新的，一次一个，然后随着我们越来越自信而散装。如果事情不起作用，我们可以将客户推回旧系统。但我看到了一些问题：
我们的工作正在发挥作用，但效果不佳。我希望得到一些建议。
我不是在寻找答案，但更多的是我正在寻找关于在哪里寻找的想法。任何人对我在哪里可以找到有关如何处理这种规模的结构化系统的信息有任何想法？
答案 0 :(得分：0)
您已经提到子系统是隔离的，所以我认为更换/升级组件不是很成问题。主要的痛点似乎是数据库的变化。之所以如此，是因为您在SAAS环境中使用共享数据库模型。对于SAAS应用程序，高度灵活到最不灵活的推荐DB模型是：
为每个客户分开数据库，共享数据库但不同 schema，共享数据库共享模式。
问题在于第三种模式。它价格最便宜但非常严格。
要解决这种痛苦，每个客户都可以由不同的数据库或模式实例提供服务。 这可以一次为少数客户完成。例如，对于客户A，根据选择创建不同的数据库/模式。导出该客户ID的所有记录并填充到新架构中。开始将新客户路由到新数据库，您仍然可以将旧数据库重新发送回。
一般来说，对于Web服务，
总是更好使用路由器调用真正的Web服务。
我认为，它可能已经存在。因此，客户实际上调用路由器服务，该服务将路由到客户的适当Web服务。它就像更改路由器上的配置以退回或路由到不同版本或服务的安装一样简单。上述策略可以某种方式应用于不同的子系统。
答案 1 :(得分：0)
对于您的多租户SaaS架构，我不确定您是否会在此获得任何银弹答案，但根据我在创业公司的经验，我们正在构建一个多租户saas Web应用程序平台（水平平台，需要照顾60％的需求，剩下40％由垂直应用程序解决）这是我的智慧之词：
我知道这很困难，但尝试将应用程序功能数据和租户数据绝对分离为两个不同的模式/数据库或其他任何东西。当更改与核心应用程序功能相关并且不会对客户或用户数据产生任何影响时，这将允许您显着减少部署时间和测试要求。基本上，您将不得不让您的团队经历痛苦的痛苦，以识别并剥离严格定义应用程序功能（应用程序元数据）的所有表。 一旦实现这一目标，您就必须优化所有开发和测试流程，以分离影响核心应用程序平台功能与垂直应用程序功能与客户数据相关的任务。这就是我们的工作，对我们来说，升级到核心应用程序平台只需要几个小时即可。
...独立
老实说，如果不对现有的景观进行彻底的分析，我无法告诉你如何实现这一目标。祝你好运！