具有多个客户界面的微服务的正确体系结构

Question

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

这种类型的系统的示例可能是：

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

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

2. 有网站展示产品的公司

   • 使用产品微服务

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

   • 使用报价和用户微服务

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

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

或者，我可以存储诸如用户之类的信息，并在客户端系统本地引用，并引用微服务以获取通用的数据。在这里，mirco服务可以仅用于处理通用逻辑并返回结果。这确实使我感到不合逻辑和有问题。

我无法在网上找到任何东西来解释这种情况下的最佳操作方案，并且感谢对此提供的任何经验反馈。

Answer 1

恐怕您还不会找到针对微服务架构的许多有用的方法或模式。我认为您的问题相对安静，因为它没有足够的细节可供任何人轻易掌握。我要摇一摇：

从最初的原则出发，您有一个 quote 的概念，它必须询问 product 以获得价格和其他详细信息。它可能需要访问用户来生成佣金信息，并访问客户来获取折扣和交货期等信息。类似的概念可以用于不同的应用中。例如库存，目录，订购 [与 quote 略有不同]。

微服务中的想法是通过将常见操作作为自己的（微）服务进行调度，并根据它们构造 aggregate 服务来减少这些概念之间的重叠。仅仅因为某种事物作为服务存在并不意味着它必须是公开可用的。这些服务可以是私有的。

将系统压缩到这些单一功能服务中后，生成的系统将进行更多的通信，但可以更灵活地进行部署。例如，更多资源＆|如果 product 服务因许多服务的请求而使冗余负担过重，则可能会对其施加冗余。最后，诸如服务网格之类的基础架构有助于将这些微服务的实现与各种部署注意事项区分开。

不要误以为有免费的午餐。微服务架构需要在定义服务边界方面进行更多的前期工作。与规模不佳的单片应用程序相比，此关键区域的故障可能会产生更严重的问题。即使您已经很好地定义了服务，您仍可能会发现它们依赖未充分考虑的外部服务。唯一的安慰就是，如果您已经将系统的其余部分与其各部分隔离开来，那么将自己与这些事物隔离起来会容易得多。

Answer 2

在对各种在线课程，视频教程和Netflix提供的一些文档进行了大量研究之后，我开始了解最佳解决方案中图表的第一个结构。

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

我希望这对尝试掌握此体系结构的人有所帮助。