微服务的正确粒度是多少？ [关闭]

Question

我们有一个网站，该网站通过 API 调用向为我们提供航班库存和票价的聚合器调用来比较机票和预订机票。通过 API 调用我们网站上的支付网关来支付门票。我们有类似的酒店预订能力。酒店预订和航班预订使用 Lumen 作为单独的服务实施。由于酒店预订也使用与航班相同的支付网关，因此我们最终在酒店服务下复制了该代码。将支付转换为单独的微服务可能是一个更好的主意。问题是，微服务的正确粒度是多少？

Answer 1

答案是，视情况而定。回答您的问题的一种方法是查看您的团队的组织方式。您是否有围绕航班聚合、付款、酒店预订和航班预订组织的团队？如果你有，那么在你的微服务架构中模仿这种组织结构也许是有意义的。毕竟，康威定律规定，这最终将是您的服务以任何方式组织起来的方式。

话虽如此，我知道的另外两种方法是：

1. 按业务能力分解Decompose by business capability Context

2. 按业务子域分解。 Decompose by subdomain Context

Answer 2

如果代码重复是您关心的问题，我可以建议您编写一个通过 composer 拉入的包吗？这样您就可以将其拉入您将来可能需要的任何其他项目中。至于什么是正确的粒度，一段字符串有多长？