多租户微服务设计

我们正在将单片应用程序迁移到微服务架构。由于某些法规要求，我们必须将来自不同国家/地区的客户数据保存在单独的（特定于国家/地区）数据库中。即美国客户的美国数据库，英国客户的英国数据库...

我们正在考虑的以下设计如下：

选项1：具有休眠多租户支持的多租户应用程序，可以根据需求扩展到N次（例如kubernetes pod）。该应用程序的单个实例将能够连接到所有数据库。

选项2：每个国家/地区数据库部署1个微服务实例。通过它们前面的API网关路由流量

如果要设计这种类型的系统，您会选择什么？

microservices

— 你好，世界
source

我认为这将取决于您的特定功能和非功能需求。

— 罗伯特·哈维

不同的数据库但是相同的实例正在读取吗？这也违反法规要求吗？

— Jimmy T.

选项1似乎与微服务体系结构风格不太一致。

— Laiv

您提到了Kebernetes，但不清楚是否使用容器。例如，如果使用Docker进行此操作，则只需创建一个连接数据库的应用程序即可。然后，当您启动容器并通过参数和/或配置指定连接详细信息时。具有一个连接到许多类似数据库的应用程序只会造成潜在的问题。它不会给设计增加任何好处。

— JimmyJames

Answers:

我认为选项2不错，但可能不需要。微服务用于让您处理多个应用程序的需求。

这里的一个重要因素是两种模式之间是否存在任何差异，以及将来是否存在任何差异。

通常，我认为对存储库使用接口是不必要的。但是，在这种情况下可能值得付出努力。储存库工厂对您很重要。

我对选项1的问题是它太具体了。您应该能够从所描述的设置转到两个单独的实例，每个实例都指向自己的数据库。该应用程序不应该在意从中获取数据的位置。

尽管两个不同的数据库的架构没有不同，但是您可以让一个存储库轻松处理这两个数据库，而应用程序不知道它们之间的区别：

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

如果数据库模式在美国和英国之间变得截然不同，那么您将把功能分成两个完全不同的存储库。这将很容易，因为您要做的就是更换工厂。

— 猫语者
source

我不明白为什么你需要这个工厂。为什么不在启动时直接传递配置详细信息的路径？这样，您每次想添加新的地区/国家时都需要修改代码。

— JimmyJames

这里的问题不是与不同国家的用户打交道，而是与不同的数据库打交道。如果有不同的架构怎么办？消费类为什么要负责弄清楚从哪里获得数据库连接字符串？

— TheCatWhisperer

我不懂你的意思代码中的任何内容都不应对“弄清楚”从何处获取连接字符串负责。它的配置。我不明白为什么这与对QA数据库和生产使用配置没有什么不同。您不会在代码中添加if语句，对吗？

— JimmyJames

这是一个与两个数据库通信的应用程序。

— TheCatWhisperer

我认为您误解了这个问题：“我们必须将来自不同国家的客户数据保存在单独的（特定于国家/地区的）数据库中”，不需要单个应用程序“实例”与两个数据库进行对话。我怀疑这只是两个数据库。OP键入“ ie”时可能表示“ eg”

— JimmyJames

我会选择第二种选择，它减少了开发和部署中的摩擦。

因为您将应用程序分布到每个区域1个（或至少一个）实例，而不是整个世界中的至少一个实例，所以这将提供更好的可伸缩性和可用性以及更好的零停机时间部署选项。

随着需求的变化，您可能会具有更多特定于区域的业务逻辑以及数据可能也会发生变化，我将尝试按区域划分代码及其数据，并避免共享特定于区域的业务逻辑（您可能最终会共享一些核心代码）。

说得通？

— 肖恩·法玛（Sean Farmar）
source