具有多个客户接口的微服务的正确架构

Question

我是微服务的新手，我热衷于使用这种架构。我很想知道对于具有多个客户接口的系统应该使用哪种架构结构，其中客户系统可能使用一种或多种可用服务。以下是我认为可以使用的几种方式的简单说明：

此类系统的一个示例可能是：

1. 拥有多名员工的公司使用产品报价系统

   • 使用产品、报价和用户 mirco 服务

2. 公司有网站展示产品

   • 使用产品微服务

3. 拥有多名员工的公司使用自己的报价系统

   • 使用报价和用户微服务

这些公司都有自己的自定义构建界面，只显示相关服务。

如图所示，所有报价、产品和用户都可以存储在 mirco 服务的本地，使用唯一的引用来识别每个公司的记录。我不知道这是否可取，因为它可能会使数据难以管理，并且可能会快速增长，从而难以管理。

或者，我可以存储客户端系统本地的用户和报价等，并引用微服务以获取通用数据。这里的 mirco 服务可以用来处理常见的逻辑和返回结果。这确实让我觉得有些不合逻辑和有问题。

我无法在网上找到任何内容来解释这种情况下的最佳行动方案，如果对此提供任何有经验的反馈，我将不胜感激。

Answer 1

恐怕您还没有找到很多有用的微服务架构秘籍或模式。我认为你的问题相对安静是因为它没有足够的细节让任何人都容易掌握。我会摇一摇：

从第一原则开始，您就有了 quote 的概念，它必须询问 产品 以获得价格和其他详细信息。它可能需要访问 users 以生成佣金信息，并访问 customers 以获取折扣和交货时间等信息。类似的概念可以用在不同的应用中；例如 inventory、catalog、ordering [与 quote 略有不同]。

微服务中的想法是通过将公共操作作为它们自己的（微）服务分派，并根据它们构建聚合服务来减少这些概念之间的重叠。仅仅因为某些东西作为服务存在并不意味着它必须是公开的。它可以只对这些服务私有。

当您将系统压缩为这些单一功能服务时，生成的系统将进行更多通信，但能够更灵活地部署。例如，更多资源 &|如果 product 服务因来自许多服务的请求而负担过重，则冗余可能会应用于该服务。最后，像服务网格这样的基础设施有助于将这些微服务的实现与各种部署考虑因素隔离开来。

不要误以为有免费午餐。微服务架构需要更多的前期工作来定义服务边界。这个关键领域的失败可能会产生比规模不佳的单体应用程序更糟糕的问题。即使您已经很好地定义了您的服务，您也可能会发现它们依赖于没有得到充分考虑的外部服务。唯一的安慰是，如果您已经将系统的其余部分与其部分隔离，那么将您自己与这些隔离起来会容易得多。

Answer 2

经过 Netflix 提供的各种在线课程、视频教程和一些文档的大量研究，我已经理解了图中的第一个结构是最佳解决方案。

每个服务都应该能够有效地独立运行，除了参考其他服务以获取更多信息。实际上，每个服务都应该能够被拾取并放入另一个系统，而无需了解架构的 API 层之外的任何内容。

我希望这对试图掌握这种架构的人有所帮助。