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