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