在这一点上，停止并讨论逻辑体系结构和物理体系结构之间的区别，以及这如何应用于基于微服务的应用程序的设计是很有用的。
首先，构建微服务不需要使用任何特定的技术。例如，Docker容器并不强制创建基于微服务的体系结构。这些微服务也可以作为普通进程运行。微服务是一种逻辑架构。
此外，即使微服务可以物理地实现为单个服务、进程或容器（为了简单起见，这是eShopOnContainers的初始版本中采用的方法），在构建大型由数十个甚至数百个服务组成的复杂应用程序。
这就是应用程序的逻辑架构和物理架构之间的区别。系统的逻辑架构和逻辑边界不一定将一对一映射到物理或部署架构。它可能发生，但通常不会。
尽管您可能已经确定了某些业务微服务或有界上下文，但这并不意味着实现它们的最佳方法总是为每个业务微服务创建单个服务（如ASP.NET Web API）或单个Docker容器。有一条规则说每个业务微服务都必须使用单个服务或容器实现，这太僵化了。因此，业务微服务或有界上下文是
一种逻辑体系结构，可能与物理体系结构重合（或不重合）。重要的一点是，业务微服务或有界上下文必须是自治的，允许代码和状态独立地进行版本控制、部署和扩展。
如图4-8所示，目录业务微服务可以由多个服务或流程组成。这些服务可以是多个ASP.NET Web API服务，也可以是使用HTTP或任何其他协议的任何其他类型的服务。更重要的是，这些服务可以共享相同的数据，只要这些服务对于同一个业务领域是一致的。
具有多个物理服务的业务微服务
示例中的服务共享相同的数据模型，因为Web API服务的目标是与搜索服务相同的数据。因此，在业务微服务的物理实现中，您将拆分该功能，以便可以根据需要放大或缩小每个内部服务。也许Web API服务通常需要比搜索服务更多的实例，反之亦然。
简而言之，微服务的逻辑体系结构并不总是与物理部署体系结构一致。在本指南中，每当我们提到微服务时，我们指的是可以映射到一个或多个（物理）服务的业务或逻辑微服务。在大多数情况下，这将是一个单一的服务，但可能更多。
