问题描述
我正在寻找一些专家和正确的建议，以开始在 POC 上的工作，以决定使用 DotNet Core 开发到部署的微服务。
POC 概念：客户将选择一些产品，下订单，申请折扣，然后付款。客户可以看到他过去的订单。
我已经浏览了很多关于微服务架构的互联网文章和视频。并使用 dotnet 核心进行开发。大多数情况下，教程或指南都会将其带到云端。
我正在寻求帮助to give a start in local machine no cloud involvement。
在开始之前，我有一些疑问，并就此寻求一些专家建议：
Q1：在 dotnet core 中创建服务的正确方法是什么？
- 我是否需要在 dotnet 核心中为每个微服务“产品”、“订单”、“折扣”、“付款”创建不同的解决方案 (.sln)，即总共 4 个解决方案？
- 或者一个包含 4 个不同 API 项目的解决方案是否可行？
Q4：微服务通信：我将使用 RabbitMQ 创建异步通信，
Q3：Docker 部署
- 我是否需要将所有 4 个微服务（每个不同的 .sln）都包装在一个容器中？
- 还是分开 4 个容器然后部署？
Q4：容器是否会相互通信或微服务遵循异步通信。
Q5：是否可以做 Docker-Swarm orchestration 本地机器。
我的理解和概念：
- 微服务是指作为 SRP 运行的每个模块或独立服务。
- 微服务包含自己的代码、数据库和库，并充当 SRP。
- UI 与每个服务交互，（我们可以根据需要进一步实现 API Gateway）
- 微服务可以使用任何基于 AMQP 协议的技术（例如 RabbitMQ、Kafka、Azure）以异步方式相互通信 服务总线
- 这种基于 AMQP 的方法被视为事件溯源
- 对于同步通信，我们仍然可以使用 REST、GraphQL、gRPC 等同步模式
开发工具：
- Visual Studio 2019
- DotNET 核心
- RabbitMQ 用于异步通信，REST API 用于同步通信
- Docker 桌面（我正在运行 Windows 容器）
- 用于测试的 xUnit
- 服务的 API 管理 (Ocelot)
流行语编排：
当超过 2 个服务正在运行时（在我的 POC 案例中），我们需要 管理他们，所以我们将转向大流行
- Docker Swarm（在我的情况下会跟进）
- K8
- 服务结构
解决方法
Q1：在 dotnet core 中创建服务的正确方法是什么？
我是否需要在 dotnet core 中为每个解决方案创建不同的解决方案 (.sln) 微服务“产品”、“订单”、“折扣”、“付款”，即总共 4 个 解决方案？或者一个包含 4 个不同 API 项目的解决方案是否可行？
两者都可以。一些公司将 Mono 存储库用于微服务。您可以将 Mono 存储库用于微服务，但您也可以将单独的存储库用于一个 Monolith 应用程序的各个部分。类似的情况也适用于解决方案，您可以将所有微服务放在一个解决方案中，但您也可以将它们放在单独的解决方案中。出于实际原因，我更愿意将每个解决方案放在单独的解决方案中。这样你就分开了。这带来了很多好处。其中之一是您的代码将在物理上分离，您将没有机会在另一个微服务中意外使用来自一个微服务的代码。请阅读关于一个或多个存储库上的多个微服务的答案 here。在这里可以应用很多要点，因为将它们放在同一个解决方案中通常意味着将它们放在一个物理位置（这有缺点），类似于将它们全部放在一个存储库中的情况。根据我的经验，每个微服务拥有单独的解决方案并拥有单独的存储库通常更好。
Q4：微服务通信：我将创建一个异步通信 使用RabbitMQ，
我是否需要创建一个单独的类库项目/解决方案然后 需要将其容器化并部署在 docker 上吗？
不，您不会将其容器化。微服务通信通常发生在从微服务-A 到微服务-B。您将容器化 micro-service-A 和 micro-service-B 但不会容器化 RabbitMq 库。通常用于横切关注点，例如用于 RabbitMq 交互的代码、数据库访问层公共类、测试基础设施、一些常见事物的共享代码，您将放在单独的项目/解决方案中。您可以将其称为 micro-service-common-library 或 micro-service-common-infrastructure 或类似名称。您可以从该库构建一个 nuget 包（或多个 pacakges），并将其添加为每个微服务中的参考。通过这种方式，您将重用通用代码并将所有横切关注点集中在一处。
Q3：Docker 部署
我是否需要将所有 4 个微服务（每个不同的 .sln）包装在一个 单个容器？还是分开 4 个容器然后部署？
每个微服务都应该在自己的容器中。把这想象成它在生产中的位置。如果它们都在一个容器中，你将如何独立扩展微服务？你不会那样做。我知道您在谈论本地开发环境，但容器并不重，我们希望它靠近生产设置，以便更容易地发现错误并在与生产环境类似的设置中工作。
Q4：容器之间是否会相互通信或将微服务通信到 遵循异步通信。
两种方式。微服务之间可以通过多种方式进行通信。请阅读以下答案 here，其中我已经解释了沟通方式:)
Q5：是否可以做 Docker-Swarm Orchestration 本地机器。
我不太确定您在问什么，但问题是您是否可以在本地机器上使用 Docker-Swarm？那么答案是肯定的。为此，您也可以使用 docker-compose。
- 微服务是指作为一个单独的模块运行的每个模块或独立的服务 建议零售价。
是的。
- 微服务包含自己的代码、数据库和库，并充当 SRP。
不完全是，上面解释了libs的部分:)
- UI 与每个服务交互，（我们可以根据需要进一步实现 API Gateway）
是的。
- 微服务可以使用任何基于 AMQP 协议的技术（例如 RabbitMQ、Kafka、Azure）以异步方式相互通信 服务总线
是的。请查看上面有关微服务到微服务通信的信息的链接。
- 这种基于 AMQP 的方法被视为事件溯源
不仅是事件采购。还有其他与微服务结合使用的事件模式。 Here 是 Martin Folwer 的一篇不错的文章，他解释说：事件通知、事件携带状态转移和事件源和 CQRS。
- 对于同步通信，我们仍然可以使用 REST、GraphQL、gRPC 等同步模式
是的。