微服务：弊大于利

微服务炒作甚嚣尘上，抨击单体应用似乎在 HackerNews 和 Reddit 上成了主流。很高兴听到 DHH 将理智带回讨论。

大型公司通常有充分的理由将应用程序积极地拆分为百、毫和微服务。对于只有个位数或两位数工程师的团队来说，这简直是疯了。

（微）服务解决的问题

微服务从根本上解决了大型工程师团队中的协作问题。

它们使得独立部署大型应用程序的不同部分变得容易。它们还将问题分解为小的复杂单元，无需理解整个系统即可理解、测试和修复。

一旦你拥有一个庞大的单体应用，将其拆分还可以大幅提高开发人员的生产力，因为如果你只在一个服务的范围内工作，编译、代码检查和测试时间会大幅减少。

它们还通过部署机制强制实现这种分离，而不是通过在一个单一代码库中使用库的约定。这使得人们更难通过强制他们使用已发布的 API 来破坏代码的封装。

讽刺的是，它们还解决了公司政治中长期存在的必须与他人良好合作的问题。现在你可以忽略集成问题，只需指向你的微服务说“所有测试都通过了，它正常工作！”，并在下次绩效评估中表现良好。

解决你实际面临的问题

太棒了。听起来这是一个解决大型复杂公司中高效、大型工程团队面临的许多政治问题的绝佳方案。

这描述了你当前的问题吗？如果你是一个典型的早期创业公司，你的问题应该看起来像这样：

• 验证产品是否能为其目标用户提供服务
• 找出客户获取策略，并快速迭代产品中促进此目的的边缘功能
• 通过使部署更简单、更少出错来增加睡眠时间
• 帮助公司其他 overworked 的人员完成他们的工作

所以……把应用程序拆分成服务究竟能给你带来什么，再说一遍？

单体应用是早期创业公司的理想选择

部署简单。设置 CI，自动化部署并频繁部署。使用单体应用，你可以知道它是否已部署。

系统范围的更改可以在一个地方完成，你无需显式地对破坏性更改进行版本控制，因为所有代码都在一个地方。这使得迭代新功能的速度**快得多**。

所有内容都在一个地方。虽然这意味着需要理解的东西更多，但有一种奇怪的观点认为，将代码分散到 10 多个仓库中会更容易理解整个系统。当然，对于初级开发人员来说，查看单个服务并理解它更容易。但认为创建数十个服务的心理模型比在单个代码库中创建等效模块更容易的想法是疯了。当然，当你的代码量达到 100 万行以上时，这会变得很复杂，但那不是你现在面临的问题。

微服务的分析后果

那么，除了互联网上“某人是错的”这个老问题之外，为什么这会出现在 Metabase 博客上呢？嗯，主要是因为使用微服务会对你提供分析的能力产生非常严重的影响。

如果你的数据模型是解耦的，那么在某个时候你会想……将其重新耦合起来，这样你就可以分析业务的运行情况。微服务的主要支持者往往是大型公司的工程师（他们有小规模的数据工程师团队来重新整合数据……你也有吗？）、顾问（任何能让个人顾问看起来不错并能赚取更多计费时间的事情都是好事），或者是不想与公司其他部门协调的工程师。

如果你在微服务之上再增加“为工作选择正确的数据库”的额外疯狂，情况会更加恶化。这样，你将突然需要在所有这些闪亮的小雪花之间有一个稳定的 ETL 方案。

为什么要在乎？

好吧，大多数时候，当你在早期创业公司时，你并不知道到底要构建什么。你可能会有一个想法，希望能有一些早期用户和一个梦想。为了改进你的产品，你需要了解正在发生什么，哪些产品功能有效，哪些无效，用户行为如何等等。

而且，顾名思义，你的人手也会不足以完成工作。所以为了运营业务，你需要让非工程师（或者在这种情况下，除了编写微服务的人之外的任何人）轻松地提取数据。

在某个时候，代码库的大小会促使你将其分解为服务，并承担随之而来的所有操作麻烦。在那之前，尽可能长时间地使用一个简单无聊的单体应用。

总结：微服务解决了早期创业公司没有的问题，并使迭代变得更加困难。尽可能长时间地使用单体应用。