如果我正在构建一个遵循微服务架构的可伸缩应用程序，那么如何决定应用程序的哪些组件应该是自己的服务呢？例如像facebook这样的网站，它可以分为非常广泛的服务，新闻源，信使，搜索等，或者它可以分成更小的服务。将应用程序拆分为服务以确保可伸缩性和效率的正确方法是什么？
答案 0 :(得分：2)
很抱歉，但是对于这些场景中的每一个，答案都是，这取决于。您作为架构师的角色的一部分是根据您的场景确定这一点，并且没有真正的规则，只有意见。此外，没有人会站在它上面判断你。在一天结束时，应用程序只需要有用，可扩展，可靠且易于维护。这相当于建筑师询问砖块应该是圆形，方形还是矩形。这取决于。如果把它等同于房子，我们不是在谈论如何安排厨房，更像是地下室的管道。在某些时候，没人会关心。
答案 1 :(得分：1)
分解微服务没有任何硬性或快速的规则。这取决于几个因素。根据我的经验，它主要依赖于这两个关键因素。
让我们重温一下打破微服务的想法。我们希望以这种方式将我们的服务部署为独立模块，每个服务的可用性都是独立的。因此，我们正在努力实现以下目标：一个服务向下意味着当时只有一个服务不可用。其他人都可以。
现在，我已经提到了两个因素。
（1） 依赖 （模型，库，dbs等）
让我们采取一个简单的方案，只是为了掌握这个想法。想象一下，有一个在线零售商平台。在那里，我们有一组独立的（隔离的）数据库表来存储与服装相关的库存数据。并且它是这样的，它更难以进一步分解（例如：女性服装，男士服装等的不同隔离）。
所以在这里，当我们要开发api服务时，我们可以决定为服装提供单独的微服务（因为我们为该部分提供了一组独立的隔离表），但不能进一步细分为部分服装（因为不能再隔离这些表）。请注意，在这里，由于我们对服装有单独的数据库隔离，因此该隔离的任何数据库故障都不会影响任何其他服务（反之亦然）。并且想想如果我们进一步破坏服务会发生什么（女装/男装等单独的微服务）。由于我们对所有人都有一个共同的数据库隔离，如果这种常见的依赖关系失败，所有服务都会崩溃。因此没有任何意义因为没有获得可用性而努力进一步打破。
（2） 业务
我也会在这里看到上面的例子。让我们像客户付款一样进行业务运营。由于它是业务的关键部分，大多数时候，我们可以推断出我们将为支付制作单独的微服务。几分钟无法获得客户付款，可能会使企业损失数百万美元。因此，我们希望将其作为一个独立的独立微服务，并在部署时给予特别关注。
最后，既然你已经提到了facebook，我猜他们会让这些微服务崩溃。