问混合多租户的模块化单体与微服务

EN

TLDR:我正在设计一个混合的多租户应用程序，需要处理来自客户(租户)的定制请求，我试图在模块化的monolith模式和微服务模式之间做出决定，这是处理定制的最佳方法，降低开发成本？我的意思是，既然模块/微服务的大小是正确的，那么我们应该如何处理自定义呢？

注：

如果问题需要澄清或混淆，请在评论中提出，我将急于澄清任何事情。

如果你需要更多的信息，请让我知道，我愿意提供它，请尽量温柔，这对我来说太混乱了。

对于这么大的帖子，我很抱歉，但我认为这个信息与我强烈建议阅读整个帖子的决定相关，这包含了我对这个主题所做的背景和研究：

上下文

我正在设计一个混合多租户应用程序，它必须处理自定义，例如:我有一个基本(默认)优惠券功能，但是一个客户(租户)需要在优惠券功能中添加一些特定的逻辑。

您可以在这里阅读更多关于多租户的内容：https://docs.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-app-design-patterns

需要考虑的事情：

1. 我们将处理客户要求的最低限度的更改，我们计算了~120个自定义请求，我们将在启动后开始工作。
2. 我们预计在启动后的第一个月内将有1000名租户(他们已经预先注册)。
3. 启动后，我们不能每次需要实现某些自定义功能时，中断只需要默认应用功能的客户的操作。

研究

我正在做一些关于架构模式的研究，我发现了两个主要有趣的模式，我认为这些模式可以解决我的问题：

微服务模式

来源：https://towardsdatascience.com/looking-beyond-the-hype-is-modular-monolithic-software-architecture-really-dead-e386191610f8

以下是Microservice体系结构的特点:整个应用程序被分割成单独的进程，其中每个进程可以包含多个模块。

1. 与模块化单体或SOA相反，微服务应用程序是垂直分割的(根据功能或域)
2. Microservice边界是外部的。因此，微服务通过网络呼叫相互通信。
3. 每个Microservice都有自己的数据库，而不是单一的数据库。
4. 由于“每个微服务数据库”，需要额外的数据同步。

模单点模式

来源：https://towardsdatascience.com/looking-beyond-the-hype-is-modular-monolithic-software-architecture-really-dead-e386191610f8

以下是模块化整体架构的特点：

1. 完整的软件系统是作为一个整体部署的(全部或无)
2. 模块边界是内部的，可以很容易地交叉，这会导致意大利面代码(如上面的黄色线所示)。
3. 应用程序作为一个单一进程运行。
4. 它是一种适用于所有类型的应用程序的解决方案--模块间没有严格的数据所有权

我所理解的

到目前为止，我所了解的是：

1. 每个微服务都是一个单独托管的应用程序，并且使用网络调用与其他微服务交互，所以我需要管理多个服务器(kubernetes或docker群)和microservices(RabbitMQ)之间的交互。
2. 模块化monolith是一个包含模块的应用程序，它更容易开发，因为您不需要管理不同的服务器，模块之间的交互也比较简单，但是由于我需要重新编译，所以很难处理定制，可能会给其他租户带来停机时间。
3. 如果我选择微服务模式，我将需要投资于一个devops团队来管理服务器和微服务交互，但它将更具可伸缩性。
4. 如果我选择模块化的一元模式，我需要对每个定制进行更多的投资。

问题

1. 我们应该使用哪种模式来处理定制，降低开发成本？
2. 我们应该如何处理自定义?我的意思是，既然模块/微服务的大小是正确的，我现在该如何处理？
3. 对于微服务的开发和交互，您推荐哪一种技术栈？

编辑

定制示例

我们所指的定制的一个真正的例子是：

这个基本的应用程序有一个商店功能，它用单位价格计算总价格，一个拥有杂货店的顾客(租户)不计算单位价格，但他在(x)公斤之后计算每公斤价格，他要求我们改变他的商店的定价制度。