我正在阅读microservice architecture，内容涉及如何将应用程序分解为服务。有一些策略可以提供帮助，其中一种是decompose by business capability
它们以具有以下业务功能的在线商店为例：产品目录管理，库存管理，订单管理，交付管理，...
我在这里有一个问题：考虑相同的示例，假设客户可以通过两个不同的网页（webA和webB）将其产品订购到我们的在线商店。
哪种方法更好，是构建两个微服务（order-management-webA，order-management-webB）还是仅构建一个包含所有内容的微服务（order-management）？
我认为两种方法都有其优点和缺点，但是，您怎么看？
答案 0 :(得分：0)
选择划界的位置取决于您对业务的了解。 如果您是第一次（业务而非微服务）这样做，那么肯定会出错。而且，您不能仅仅选择与您的类似业务相匹配的业务并使用它们，因为就像您说的那样，每种方法都各有利弊。
此外，您还需要确保服务中关注点的分离。一种服务应处理一个域。同样，从哪里获取需求进行思考也是有意义的，如果您有不同的业务团队，则将来自这些团队的需求编码到不同的服务中也是有道理的（保持开放的态度，因为会涉及到交叉的问题）。
因此，要回答有关示例的问题，这取决于OMS对这些网页中的每个网页到底做了什么？我可以说一个请求可能来自您的Web应用程序，而另一个来自您托管产品（webB）的某个市场。
在这种情况下，如果订单流程不同，则选择不同的服务是有意义的，如果两者的规模或qps不同，那么您可能必须相应地设计oms或为它们的服务分别部署它们个人缩放需求。 如果您手头上还有其他信息或对biz有任何看法，使您认为拆分它们可以为您提供帮助，那么
但是对于所有事物都是相同的，并且说oms不会保留有关他们所销售的用户或所订购产品的信息，以及如何实现的信息（我的意思是它保留了参考信息，松散耦合），那么您可以使它与一项服务一起工作。
是的，每一个都有优点和缺点，您需要相互利用，而最适合您的是最适合您的解决方案。
还有一件事，最重要的是，这些服务很小。您会觉得自己做错了什么，或者有更好的方法，可以随时进行更改。微服务应该足够小，可以快速更改，并且灵活性非常重要。 而且通常，这种检查可以确保您在给定的服务中没有投入超过实际需要的东西