微服务vs单体，为什么说单体在绝大部分时候是更好的选择

在微服务大行其道的今天，其实已经有很多大师或者有务实的研发者已经意识到微服务在研发过程中，可能不是你想要的银弹，很多时候起到了反作用。

在本文中，我们学习一下由软件大师“Martin Fowler”在2015年就提出的“单体优先”（Monolith First）的思想。

Martin Fowler发现所有成功的微服务都遵循了通用的模式：

1、几乎所有成功的微服务故事，都是从一个变得太大而被分解的单体开始的。

2、几乎所有我听说过的从头开始构建为微服务系统的系统都以严重的麻烦告终。

这种模式导致Martin Fowler的许多同事认为：“你不应该用微服务开始一个新的项目，即使你确信你的应用程序将足够大，值得这么做...”

图片描述

单体优先：

单体允许你探索系统的复杂性和组件的边界；

当复杂性增加时裂变出微服务；

当你边界和服务管理的业务知识增加时裂变出更多的微服务。

直接微服务:

直接使用微服务架构风险太大。

微服务是一种有用的架构，但即使是它们的拥护者也说使用它们会产生显著的“微服务附加费”，这意味着它们只对更复杂的系统有用。

这种附加费，本质上是管理一套服务的成本，将拖慢团队的速度，让使用单体应用成为更简单的选择。

这成为了“单体优先”策略的有力论证，即使你认为它可能会在以后从微服务架构中受益，你也应该在最初使用单体来构建应用。

原因一：Yagni（You Aren't Gonna Need It，你不会需要它）。

当你开始一个新的应用程序时，你有多确定它对你的用户是有用的？也许很难扩展一个设计不佳但成功的软件系统，但这仍然比它的反面要好。

正如我们现在所认识到的，通常发现一个软件想法是否有用的最好方法是建立一个简单的版本，看看它的效果如何。

在这个第一阶段，你需要优先考虑速度（也就是反馈的周期时间），所以微服务附加费是你应该避免的拖累。

在很多情况下，你的程序或许活不到必须使用“微服务”的那一天！这种情况下使用微服务只能拖慢你的交付和推向市场的速度！

原因二：微服务只在服务间有良好、稳定的边界下才能工作

微服务之间的任何功能重构都比在单体中要难得多。

即便是在熟悉的领域工作的有经验的架构师也很难在一开始就能确定正确边界。

通过先建立一个单体，你可以在使用微服务设计之前弄清楚什么是正确的边界。这也给了你时间来开发更好粒度的微服务。

单体优先策略一：模块化单体

合乎逻辑的方法是仔细设计一个单体应用，注意软件内部的模块化，包括 API 边界和数据存储方式。

做好这一点之后，从单体应用转向微服务是一件相对简单的事情。

单体优先策略二：边缘剥离

一种更常见的方法是从单体开始，逐渐剥离边缘的微服务。

这种方法可以在微服务架构的核心留下一个实质性的单体。

大多数新的开发都发生在微服务中，而单体是相对静止的。

单体优先策略三：整体替换

很少有人把这种做法看成是一种值得骄傲的做法，然而把单体作为一种牺牲性的架构来建造是有好处的。

不要害怕建造一个你会丢弃的单体应用，特别是如果一个单体应用能让你快速进入市场。

单体优先策略四：粗粒度服务

从几个粗粒度的服务开始，这些服务比你最终得到的微服务要大。

使用这些粗粒度的服务来习惯与多个服务一起工作。

同时享受这样一个事实，即这种粗粒度减少了你必须做的服务间重构的数量。

然后，随着边界的稳定，分解为更细粒度的服务。

微服务 or 单体？

“单体优先”的思想，目前已逐渐开始成为是业界普遍共识。现在已经属于后微服务时代!

在一个人数不多、资金不是无限充裕，需要快速将产品推向市场的团队，建议使用“单体优先”的实现方式。

在很多团队中，使用微服务其实是一种Hype Driven Development（炒作/简历驱动开发），不是为了真正为了解决业务问题。

使用“单体优先”，是一个务实的选择！试想如果是你自己创业，你会是选择“单体”还是“微服务”，那么请为你的企业进行务实的选择。

参考资料：https://martinfowler.com/bliki/MonolithFirst.html

文章出自：​​爱科学的卫斯理​​，作者：汪云飞。如有转载本文请联系爱科学的卫斯理今日头条号。