跨不同项目重用微服务

Question

我们开发了一个用于SAAS的单块API。在公司中，我们也为一些客户开发定制产品。

我们的一些客户要求提供一些已经在单块应用程序中实现的特性。

我们正在考虑将API拆分为微服务，但我们的主要问题如下：

• 可以跨不同的项目重用微服务吗？
• 如果我们进行拆分，我们是创建每个人都使用的微服务还是根据自定义构建创建实例?

例如：

project A use "User", "Project" so we deploy 2 microservices
project B use "User", "Project", "Store" so we deploy 3 microservices

total number of microservices deployed : 5

如果我们为每个自定义构建创建每个微服务实例，那么在同一个自定义构建中管理所有微服务之间的通信就不会太困难了？

• 还是坚持每个每个微服务都使用一个实例，然后指定项目源?

？

因为我们使用的是C# GraphQL。我们还考虑为每个组件创建Nuget包，因此每个包将包含：

Mutations

• His

• 公开了GraphQL查询/

• 自己的db

• --他自己的逻辑

例如：

- Api A install "User" & "Project" packages
- 3 db are instantiated "Api.A", "Api.A.User", "Api.A.Project"

- Api B install "User", "Project" & "Store" packages
- 4 db are instantiated "Api.B", "Api.B.User", "Api.B.Project" & "Api.B.Store"

但这样做有意义吗？

在我看来，它可能非常类似于Hangfire https://www.hangfire.io/

注意，我们目前正在使用AWS Serverless来承载我们的应用程序。重要的一点是我们是一支2-4的小分队.

我们非常开放，所以听到任何建议都是好的。

谢谢！

Answer 1

首先，我想说的是，这里没有正确的方法，我从我们已经做过的事情中提供我的观点，希望它能指导你找到一个最适合你的需求的解决方案。

因此，为了理解您的困境，您有一个基本的普通产品，它是一个API SAAS，还有一个针对某些客户的定制部署。但是，当您必须为每个客户构建自定义部署时，您注意到了一个共同的模式，其中许多功能在SAAS中为每个客户重复。

现在假设我的需求是正确的，我会说，在您的情况下，微服务将在扩展和客户特定定制方面提供明确的好处，这些定制将由独立的团队管理。

但是，这在很大程度上取决于您的业务逻辑是如何构造的，以及您的定制有多大。这些问题中的一些应该驱动您的解决方案。

1. 可以将特定于客户的数据存储在中央数据存储区或客户端吗？&您的数据库将如何构建，其中有多少？
2. ，定制的规模有多大？它们是化妆品还是工作流？
3. ，您期望在用户、商店和项目等各种服务之间进行多大程度的跨通信，以及是否有跨A.User - B.User或A.Project - B.Store等的通信？

。

现在转到一些重要的事情，你可能想考虑张贴回答上面的问题。

考虑1. --如果可以允许数据存储在一个单一的中心位置，您可以使用一个集群来部署您的所有微服务。但是，查看所提供的数据，我可以假设每个客户都有多个数据库，我建议将它们分开，不要在它们之间引入任何耦合。因此，您可能会得到每个客户一个微服务或微服务，这只会与该客户的数据库对话。(更多见图1)

考虑2.按照规范，定制应该与服务本身分开，您的每个服务都应该有一个用于配置加载的输入，这将驱动服务行为。同样，取决于您的自定义有多大，这种配置可能会有限制，在这种情况下，我建议创建一个内置自定义的新服务。

考虑3. --这是决定您可能拥有的微服务数量的一个主要因素，但是每个服务的边界应该由域定义，例如，用户服务、存储服务和项目服务。这些是相互交互以生成有效业务场景的普通服务。每个客户都只是这些服务的专门实例。

好了，既然这件事已经解决了，让我们来掩盖一下你的主要问题.

可以在不同的项目中重用

1. Des微服务？-是的，你可以，但这同样取决于您如何设计业务工作流，配置我们进行拆分的配置，我们是创建每个人都使用的微服务，还是根据自定义构建创建一个实例？-是的，这将是一个理想的场景，因为我们不希望将数据边界和特定于客户端的敏感配置混合在一起。也就是说，可能会出现这样一种情况，即需要使用单一的微服务解决方案，但要谨慎行事。如果我们为每个自定义构建创建每个微服务实例，那么在同一个自定义构建中管理所有微服务之间的通信难道不太困难吗？--跨微服务之间的通信是一个重要的部分或因素，在大多数情况下，这往往是不可避免的。因此，考虑到您需要某种形式的跨微服务通信，您可以根据您的需求查看企业总线或API通信。但我认为，这是一个众所周知的琐碎问题。
2. 还是说，我们是否坚持每个微服务都使用一个实例，然后指定项目的来源？--我不推荐这个例子，因为在你的问题中，对于一个数据库注入模块来说，这个例子听起来不太好。这将导致高度耦合的系统设计。这也可能意味着，如果一项服务失败，您的所有客户站点都会崩溃。你肯定不想那样！

就像人们说的，一幅画值一千字.

​

​