我正在开发一个按组织划分用户的系统。每个用户都属于一个组织。每个组织都将其数据存储在自己的数据库中，该数据库驻留在数据库服务器机器上。数据库服务器可以管理 1 个或多个组织的数据库。
现有（遗留）系统假设只有一个组织，但是我想通过运行它的“实例”（绑定到一个组织）来“扩展”应用程序，并在服务器机器上运行多个实例（即运行多个实例的“单一组织”应用程序 - 每个组织一个实例）。
我将为运行在服务器上的每个实例提供一个 RESTful API，以便可以使用瘦客户端访问运行在服务器机器上的实例所提供的服务。
这是一个演示关系的简单示意图：
服务器 1 -> N 个数据库（每个组织有一个数据库）
组织 1 -> N 个用户
我的问题涉及如何将来自客户端的 RESTful 请求“定向”到处理来自该组织的用户请求的适当实例。
更具体地说，当我收到一个 RESTful 请求时，它将来自用户（属于组织），如何（或者实际上，最好的方式）将请求“路由”到服务器上运行的适当应用程序实例?
让公共 API 只指定用户对我来说听起来有点脆弱。我会更改公共 API，以便请求指定组织和用户，然后有一些简单的服务器端将组织映射到实例（例如，组织 foo -> 监听端口 7331 的实例）。
据我所知，这本质上是一个分片问题。无论您如何在硬件级别拆分实例（使用虚拟机、多台服务器、都在一台功能强大的服务器上等），您都需要在整体架构中使用中央注册表和代理层，将给定用户映射到每个请求的正确目标实例.
当然，有很多方法可以实现这一点，所以只需选择一种你知道的、速度快、可以扩展的方法，因为所有请求都会通过它。我建议一个轻量级的无状态 Web 应用程序，由一个简单的只读数据库支持，该数据库执行适当的客户端标识符 -> 实例映射，您可以将其加载到内存/缓存中。为了增加硬件和实例位置的灵活性，使用（假设是 Java）JNDI 来存储每个实例的硬件/端口/等信息，并在您的标识符映射中将客户端标识符映射到适当的 JNDI 查找键。
正如另一个答案所说，有很多方法可以解决这个问题。假设您无权访问旧版软件源代码，这意味着您无法修改它以侦听不同实例的不同端口。
编写 Apache 模块似乎非常极端地解决了这个问题（作为一个刚刚完成生产 apache 模块的人，我建议避免它，除非你正在赚大钱）。
这种方法可以像你喜欢的那样深奥。例如，如果您的旧软件在正常的英特尔架构上运行并且您拥有硬件容量，那么您应该能够创建一个瘦虚拟机，一个运行该软件的单个实例和一个多路复用器来连接它们的虚拟机解决方案。
另一方面，如果您运行良好的 HPUX 之类的东西 :-) 还有其他方法。你再详细一点怎么样？
艾哈迈德。