微服务用例

几个月前我写了一篇捍卫巨石的文章 ，然后进行了讨论 。 总体而言，不应该转向微服务，因为其开销和风险远高于任何自称的好处。 但是我在这里遗漏了一些微服务的合法用例。

这些用例可能不是“典型的”微服务，但它们大多符合独立，独立部署独立功能的概念。

最明显的用例是应用程序中占用大量CPU或RAM的部分。 通常，这需要进行单独的部署，并提供与应用程序其余部分的接口。

首先，很容易按需生成无状态，CPU密集型微服务的多个实例。 他们甚至可能是“工人”，负责处理给定的峰值，然后死亡，其中包括分叉联接设置。 而且，他们不应因为处理要求而使应用程序的其余部分卡住–应该将它们分开。

有些服务会消耗大量RAM（例如，包含大型宪报，训练有素的模型，自然语言处理管道的文本分析工具），这些服务在开发人员每次启动其正在处理的应用程序时都无法运行。 在生产环境中重新部署和重新启动它们甚至有问题。 而且如果它们很少改变，则有理由将它们分开。

上面这些常见的是他们没有数据库。 它们公开了其处理功能，但不存储任何内容（除了某些缓存）。 因此，例如，协调数据库事务就没有复杂性。

另一个“部分”用例是让多个团队共同开发同一产品。 这看起来适用于所有项目–例如，数千名Facebook开发人员仅在从事Facebook工作。 首先，不是。 实际上，许多非十亿美元用户的公司都会将一个或少量团队专用于一个项目。 甚至Facebook实际上还有许多项目（移动，广告，聊天，照片，新闻提要）。 这些不是“微”服务。 它们是功能齐全的产品，碰巧以某种方式与其余产品集成。 但是回到用例–有时微服务可能会给多个团队带来更大的灵活性。 不过，这很大程度上取决于领域。 而且，两个团队要通过适当的程序在同一个整体上工作并非不可能。

通常，如果您确定微服务的网络和协调开销与正在完成的工作量和灵活性相比可以忽略不计，那么它们是一种有效的方法。 但是我相信那是罕见的。 马丁·福勒（Martin Fowler）谈到了复杂性与生产力的关系 ，因此，从理论上讲，如果您事先知道您的项目将变得多么复杂，那么也许您就有一个有效的微服务用例。

将一项功能分离到其自身的服务中并通过Web服务与之通信不应该引起太多关注。 但是显然我们必须说“不，不是每个项目都适用”和“是的，这种方法本身并不愚蠢，在某些情况下它很有用”。

翻译自: https://www.javacodegeeks.com/2016/01/microservices-use-cases.html