如果您正在考虑为MVP使用微服务，则可能做错了

这源于Slack小组中针对菲律宾Tech Hackers（或Phackers ）的一次对话。 我们的#architecture频道中存在一个有关使用微服务启动MVP的问题，这引发了关于何时使用或不使用时的良好讨论。

Igor Ovsyannykov的 “巴塞罗那港的集装箱堆积” ， Unsplash

微服务的“运动”是一个相当新的事物— Martin Fowler将其描述为“ 2014年的热门术语” 。 在其基本定义中，它是一堆小型应用程序，它们组合在一起形成一个复杂的应用程序（当然，我们都知道它比这更深入，但是为了简单起见，我将继续讨论）。

回到讨论中—有人问为MVP走微服务路线是否是一个好主意。 明确地说，此讨论源于以下事实：他们从头开始构建服务，并且计划使用微服务来进行服务。 那个人在质疑首先采用微服务是否是正确的决定，主要原因是将来的可扩展性。

很多人对此表示赞同，并且没有很好的理由首先使用微服务。 主要原因如下：

太复杂了

如果您要构建最小可行产品 ，则最有效，最快的方法就是最短的路径-阻力最小的路径。 现在，您可以说微服务很容易创建，因为您将创建较小的部分，但请考虑一下集成。 这意味着您将每个任务乘以服务数量。 例如，如果您打算创建5个微服务，则将构建5个独立的测试套件，部署脚本和存储库-更不用说您还将监视全部5个。如果您不打算这样做，那么您将微服务做错了，应该变得单板。

另一件事是规格更改时。 我们已经去过那里了（或者您将会！）–您正在用一个编写良好的规范引导一个绿色的应用程序，突然之间，规范发生了变化。 每个人都争先恐后地改变它，一切都很好。 除非您使用微服务。 对于微服务，每次更改都需要使用微服务传播到另一个服务，这使我进入了下一点：

团队管理将很困难

让我们从一个小团队开始。 想象一下，每个人都有5个人在做自己的服务。 首先，将它们集成起来将是一场噩梦。 您将如何与团队中的某人仍在构建的服务进行通信？ 您最多可以假设某些输入（或输出），仅此而已。 还记得我上面提到的规格更改吗？ 每次更改都意味着您将在开发过程中不断更改协议和API，这会成倍增加花费的时间。

契约破裂时，战斗爆发！ 由CloudVisual在Unsplash上拍摄

好的，你有一个很大的团队。 现在，您不必再像以前那样轻松地进行管理，而是可以管理四倍的人员。 当您有一个明确而直接的目标时，这一切都很好，也就是好，例如，将现有的整体拆分为微服务时，但从此开始呢？ 这意味着您需要在每次更改时更新所有二十个人。 同样，规范在开发过程中多久更改一次？

这是过早的优化

我们都知道这个词。 从根本上来说，优化是在不进行任何衡量的情况下进行的，例如“我想我们一路上会遇到很多流量，因此我们需要微服务”。 首先，整体组件也可以很好地扩展（有些甚至比微服务更容易实现）。 其次，这是基于推测的，通常当我们乐观时，我们会基于现有的度量。 请注意，尽管过早的优化与准备快速且可扩展的体系结构之间存在差异。 但是，在我看来，作为MVP，整体组件和微服务都可以轻松扩展，因此以快速和可扩展的唯一原因走微服务路线几乎毫无意义。

原因更多，其中包括与Martin Fowler的“ Monolith First”文章的链接，该文章具有比我所能说的更深入的见解。 如果还没有，请仔细阅读，然后重新考虑您的决定。 就我个人而言，我认为95％的情况下，正确的选择对于MVP来说是一个整体（再次，我需要强调的是，具体问题是针对MVP的）。 MVP和最终产品之间存在巨大差异。 如果您打算一开始就发布最终的成品产品（并且您有足够的时间和资源），微服务可能不是一个坏主意。 确实取决于您的目标，时间和预算。 我给剩余的5％的机会带来的疑问是，微服务是否会成为MVP的答案。

这样一来，我将在过去的几年中就微服务发表两项个人经验。 我的第一次经历是在我目前的公司中，在那里我们建立了史诗般的功能，该功能应该是我们的旗舰产品。 这是我的第一个引导项目，我们已经讨论了一个月（有点太长了！）来讨论如何正确执行此操作。

我们最初将其作为微服务进行了讨论。 在此之前，我们所有的功能都托管在一个巨大的Rails 3整体中。 我们经过漫长而艰苦的思考，我们都相信微服务将是最好的选择。 在开始工作的前两天，我的老板改变了主意，并说整装待发仍然是一个好主意。

首先，这意味着我们只需要监视站点（就像我第一点一样）。 其次，这也意味着我们将不再使用任何新技术或堆栈，而只是添加到当前的Rails堆栈中。 最后，我们正在为更改做准备-我们知道在实施所有内容时会有很多更改，因此我们变得一团糟。

这是一个很好的决定。 曾经有过关于生日场地应该去哪里的辩论。 移动它并不是一件容易的事：我们必须将其移动到另一个资源中，检查测试并修复所有集成测试。 在开发过程中（发布前），生日字段至少更改了3次，发布后更改了两次。 想象一下为此提供微服务-每当有人想到将某个领域迁移到某个地方时，我们都会更改两个应用程序！

那单片微服务呢？ （ InjaPavlić在Unsplash上撰写的 “标志性的巨石阵岩石群上的云” ）

我的第二次经历是最近一点。 我自愿参加了一项名为FLOW PERTH的活动，该项目旨在帮助Cahoots ，这是一个非营利性组织，旨在帮助残障儿童和年轻人。 （据我的估计）大概有30多名志愿者，所以计划是分成小组，然后帮助一名员工完成任务（通过提供服务或其他方式）或网站的另一部分。

现在考虑到这个问题，任何人都会首先想到微服务。 为什么？ 有多个独立的团队。 A团队不需要B团队的任何重要工作。但是每个项目都将集成到现有站点中。 而且，每个团队都有不同级别的经验和语言（有些人知道Rails，Node或Java）。

我们所有人都应该像黑客马拉松一样在一天之内做到这一点–很好，只是我认为我们都非常乐观（我非常高兴成为志愿者，我认为其他所有人也都一样！）过度承诺。 当将它们整合在一起的时候，一切都是不连贯的。 每个部分本身都很好，但是UI / UX不在那儿。 我们有一个样式指南（我的任务是做前端），但是跳入具有不同实现的每个项目是一场噩梦。 其中一个是带有angular和Typescript的节点应用程序。 另一个只是带有jQuery的简单HTML / CSS应用程序-即使使用统一的样式指南，将CSS复制到每个应用程序的效率也很低。

这导致我们将所有东西都拼凑成一个整体。 现在一切都变得更容易了，UI / UX也一样。 我们只需要选择一种大多数人都知道的通用语言（节点），我们就顺其自然。

我知道一些只喜欢微服务的开发人员。 我是他们其中的一员。 它们很容易实现和使用，但是对于MVP来说，它实际上并不是正确的工具。 即使这样，始终思考您正在构建的东西还是很棒的。 思考，重新思考和重新思考更多。 问自己“为什么？” 至少五次 即便如此，还是要质疑您的决定-您是否真的认为微服务是答案，还是仅仅是因为您想使用它？ 您是要决定使用流行语还是要解决整体解决方案无法解决的问题？

From: https://hackernoon.com/if-youre-thinking-about-microservices-for-an-mvp-you-re-probably-doing-it-wrong-6fef8341fce4