在不同项目中重复使用微服务

Question

我们开发了单片API用作SAAS。在公司中，我们还为某些客户开发定制版本。

我们的一些客户要求在整体应用程序中已经实现的某些功能。

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

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

E.G：

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包，因此每个包将包含：

• 公开的GraphQL查询/突变
• 他自己的数据库
• 他自己的逻辑

E.G：

- 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微服务可以在不同项目中重复使用吗？-是的，您可以，但是同样取决于您如何设计业务工作流程，配置注入。

2. 如果进行拆分，是否创建每个人都使用的微服务，还是每个自定义构建都创建实例？-是的，因为我们不想混淆数据边界和特定于客户的敏感配置，因此这是一个理想的方案，可以在项目之间分离关注点。也就是说，在某些情况下可能需要单一微服务解决方案，但应谨慎行事。

3. 如果我们为每个自定义版本创建每个微服务的实例，在相同的自定义版本中管理所有微服务之间的通信会不会太困难？-跨微服务的通信是重要的组成部分或因素，在大多数情况下，这往往是不可避免的。因此，考虑到您将需要某种形式的跨微服务通信，您可以根据您的需求查看企业总线或API通信。但我认为这是一个众所周知的琐事。

4. 还是每个人都使用每个微服务的一个实例，并指定项目来源？-我不建议这样做，因为您的问题中提到的数据库注入模块示例对我来说不是一个好主意。这将导致高度耦合的系统设计。这也可能意味着，如果一项服务失败，那么您所有的客户站点都会关闭。您肯定不想要！！！]]

现在据说一张图片值得一千个单词...