我正在设计一个多租户系统，并且正在考虑在应用层级别而不是数据库上按租户进行分片。
假设，这应该工作的方式是，对于传入请求，路由器进程具有包含主要属性的租户的全局集合，以确定此请求的租户以及虚拟分片 ID。此虚拟分片 ID 进一步映射到实际分片。
实际的分片既包含应用程序的代码，也包含此租户的全部数据。这些分片将是 LNMP（Linux、Nginx、MySQL/MongoDB、PHP）服务器。
路由器进程应该充当代理。它应该能够运行一些代码来根据存储在某些本地数据库或文件中的集合来确定传入请求的目标分片。为了能够更好地扩展，我正在考虑让分片本身也充当路由器，以便它们可以运行反向代理，将请求转发到适当的分片。也许在 shard 上运行的 nginx 实例也可以充当那个反向代理。但是它将如何执行将请求与适当的分片匹配所需的应用程序逻辑。
我将不胜感激有关此路由器实施的任何想法和建议。
谢谢
另一种选择是使用 dbShards 等产品。dbShards 是唯一在应用程序级别进行分片的分片产品。通过这种方式，您可以使用任何 RDMS（Postgres、MySQL 等），并且仍然能够对数据库进行分片，而无需在中间放置某种代理。许多其他分片产品依赖代理将事务指向正确的分片，但 dbShards 无需“询问”其他任何人就知道去哪里。
很棒的产品。数据库分片
除非您希望租户生成大致相等的数据量，否则按租户分片不会非常有效。
对于一般的应用级分片，我来分享一下我自己的经验：
我们的大容量 SaaS 产品的第 1 版在应用程序级别进行了分片。您会发现，如果您在应用程序级别针对 SQL 类型的解决方案进行分片，那么随着您的成长重新分片将是一个令人头疼的问题，或者您将不得不编写重要的工具来自动化该过程。
我们切换到 MongoDB（在考虑了包括 Cassandra 在内的多种替代方案之后）在很大程度上是因为随着数据增长对重新分片/重新平衡的所有内置支持。
如果您的应用程序不需要 MySQL 的关系功能，我建议您将精力集中在 MongoDB 上（因为您已经将其确定为可能的数据平台），如果您期望的数据增长不止适度。允许 MongoDB 处理数据分片。