我之前从未使用过微服务架构，而且有些重要的东西在我正在阅读的内容中仍然不清楚。
在微服务架构中，服务是单个端点还是具有多个端点的单个模块？
细粒度或粒度的端点是否处于更高级别？我在开始时认为端点是细粒度的，这就是为什么存在使API过于繁琐的风险的原因。
我现在发现的文章说，在微服务架构中，服务与“有界上下文”相关联。在我看来，有界上下文需要API中的多个端点。
答案 0 :(得分：3)
这取决于您希望架构的粒度。从理论上讲，为了获得最大的粒度，并且根据单一责任原则，您应该在每个有界上下文中为每个聚合创建一个微服务。这意味着每个命令都应该有一个端点（我假设每个端点都在一个URI上到达，即https://server/place/order）。
如果您使用CQRS架构，那么对于读取/查询方面，您还可以为每个读取模型提供微服务;通过这种方式，您可以独立扩展每个读取模型（使用数据库复制或整个微服务实例复制）。
答案 1 :(得分：2)
我建议查看以下两本书 - Building Microservices 和Production-Ready Microservices。非常适合每个想要开始使用微服务的人。
答案 2 :(得分：1)
在微服务架构中，服务是单个端点还是具有多个端点的单个模块？
从概念上讲，微服务只是服务，也就是说它们只是处理消息的对象。消息进来后，服务决定是否在内存黑盒中更新自己的消息，消息就会消失。
您放在微服务之前的集成层可能有几个不同的“端点”，以帮助您传递要处理的新消息。
细粒度或粒度的端点是否处于更高级别？
无论哪种方式 - 单个端点向服务发送一连串消息根本没有错。
我现在发现的文章说，在微服务架构中，服务与“有界上下文”相关联。
是的，我也是。我没有看到任何证明他们的意思是“有界背景”的意思，埃里克埃文斯最初在蓝皮书中描述。
答案 3 :(得分：0)
微服务架构（MSA），这是什么意思？好吧，首先，这意味着我们在谈论体系结构而不是实现，其次，这意味着我们在谈论微观层面的东西。在面向服务方面，如果软件服务的功能非常狭窄，那么它就是一个很小的规模。这意味着仅负责一项职责的服务，或者换句话说，服务将足够小（从业务角度），无需服务器端状态管理即可接收请求和响应。更温和地，我们的微服务需要限制上下文。让我用一个简单的例子清楚地说明，考虑开发一种支付服务，传统上，该服务将提供信用支付，债务支付，Pay-Pal，Web-Money等，而在MSA中，每一项都是独立的服务。 您可以在我的代码项目文章中阅读更多内容：
Dive-into-Microservices-Architecture-Part-I