纳米服务的噩梦

在深入研究纳米服务之前，让我们先回顾一下微服务为何成为科技界的宠儿。在微服务架构中，您的产品被分解为较小的独立服务，这些服务通过网络（通常通过 API）进行通信。每项服务负责一项功能 - 无论是用户身份验证、支付处理还是产品搜索。

微服务非常适合拥有庞大、复杂系统的大公司。它们提供可扩展性、灵活性和故障隔离。例如，Netflix可以在不破坏整个平台的情况下更新其推荐引擎，因为每个功能都是独立运行的。

但是对于处于早期阶段的创业公司来说呢？你可能拥有一支小团队，预算有限，而且——让我们面对现实吧——只是想让人们关心你的产品。在这个阶段，微服务可能会带来不必要的开销和复杂性。

纳米服务的噩梦
这就是问题所在：为了遵循“最佳实践”，一些初创公司将其产品分解为许多微服务，以至于架构变成了由微小、细粒度的功能组成的纠结网络——我称之为“纳米服务”。

想象一下，将你的系统分解成不仅仅是一个身份验证服务，而且为该服务中的每个微小功能提供一个单独的微服务。一个用于用户名验证。一个用于密码验证。一个用于生成 CAPTCHA。听起来很荒谬，对吧？那是因为它确实如此。

这会导致几个问题：

1. 开销过大：突然之间，您需要负责管理、测试和部署数十个小型服务。每个服务都有自己的依赖关系、部署流程和潜在故障点。当初创公司快速发展并快速迭代时，它们不需要这种程度的复杂性。
2. DevOps 混乱：微服务需要一台运转良好的 DevOps 机器。我指的是可以同时处理数十种服务的容器化、编排和持续部署管道。大多数初创公司没有专门的团队来处理这些事情。有趣的事实：根据 DataDog 的一项调查，55% 使用微服务的公司表示，他们需要改进监控和警报流程，才能应对复杂性。
3. 过早优化：初创公司最容易陷入的一个陷阱就是在需要之前就进行规模优化。我明白——你想打造一款能够处理数百万用户的产品。但实际上，你可能还在考虑是否有人愿意使用你的产品。CB Insights 的一项研究（CB Insights 报告）发现，42% 的初创公司失败是因为市场不需要他们的产品。因此，你的首要任务应该是产品与市场的契合，而不是微服务和可扩展性。

发展中问题：
随着初创公司进入扩展和增长阶段，复杂性变得必不可少，甚至是有益的。此时，您的产品已得到验证，您的用户群不断增长，并且您正在以更快的速度添加功能。现在正是微服务大放异彩的时候：

• 可扩展性变得至关重要：您可以独立扩展系统的特定部分。
• 故障隔离：一个服务的故障不应该导致整个产品的崩溃。
• 团队灵活性：不同的团队可以独立开展不同的服务，从而加快开发和部署。

大辩论：我与微服务布道者约翰的对话
在 LinkedIn 上发布此消息后，我与软件工程师兼微服务倡导者 John* 进行了一次愉快的交谈。他提出了一些非常好的观点，突出了这场辩论的细微差别。
约翰争辩说：

1. 微服务本身并不意味着更多的服务。它只是关于如何组织功能。
2. 如今，有了 AWS 等平台为您管理服务，部署变得更加容易。
3. 即使是在早期的初创企业中，也应该从一开始就考虑到可扩展性。

是的，部署已经变得更容易了，但并非每个早期团队都具备有效管理微服务架构的能力。如果您的团队具备这些技能，那就太好了——去吧。但如果没有，也就是大多数初创公司的情况，那么请从简单开始，并根据需要进行扩展。

关于可扩展性：虽然可扩展性至关重要，但早期的重点应该是产品与市场的契合度。规模是其次。过早优化规模可能会在你应该加速的时候拖慢你的速度。*名字已更改，因为我承受不起另一场诉讼。

从简单开始，稍后扩展
我对初创企业的建议是：从简单开始！构建一个整体，验证您的产品，然后快速迭代。一旦您获得关注，并且用户开始要求更多功能，那么就考虑扩展到微服务。但不要陷入纳米服务陷阱，这样您就会产生不必要的复杂性，浪费时间管理开销，而不是创造价值。

关于作者：Thiago
前微软工程师，现创业迷。我卖掉了一家公司，又创办了另一家，花了太多时间思考技术。我的观点就像我的代码一样——它们可能有缺陷，但它们是开源的。