微服务流行的今天，其实很多高手或者务实的开发者已经意识到，微服务在开发过程中，可能不是silverbullet你想要的，很多时候它会产生相反的效果。在这篇文章中，我们来了解一下软件大师“MartinFowler”在2015年提出的“MonolithFirst”的思想。MartinFowler发现所有成功的微服务都遵循一个共同的模式：1.几乎所有成功的微服务故事都始于一个变得太大并被分解的巨石。2.我听说过的几乎所有从头开始构建的微服务系统都以严重的问题告终。这种模式导致MartinFowler的许多同事认为：“你不应该开始一个带有微服务的新项目，即使你确定你的应用程序足够大以至于值得......”图片描述Monolithfirst：MonolithAllowsyouto探索系统的复杂性和组件的边界；当复杂性增加时裂变微服务；当您对边界和服务管理的业务知识增加时，裂变更多的微服务。直接微服务：直接使用微服务架构风险太大。微服务是一种有用的架构，但即使是它们的拥护者也说使用它们会产生显着的“微服务附加费”，这意味着它们只对更复杂的系统有用。这种附加费，本质上是管理一套服务的成本，将减慢团队的速度，并使使用单体成为更简单的选择。这成为“单体优先”策略的有力论据，即您应该在最初使用单体构建您的应用程序，即使您认为它可能会在以后从微服务架构中受益。原因一：Yagni（YouAren'tGonnaNeedIt，你不需要它）。当您启动一个新的应用程序时，您有多确定它对您的用户有用？扩展一个设计糟糕但成功的软件系统可能很困难，但它仍然比它的逆向要好。正如我们现在意识到的那样，通常最好的方法是找出一个软件创意是否有效，就是构建一个简单的版本，看看它的效果如何。在第一阶段，您需要优先考虑速度（也就是反馈的周期时间），因此微服务附加费是您应该避免的拖累。很多时候，你的程序可能活不到必须使用“微服务”的那一天！在这种情况下使用微服务只会减慢您的交付和上市时间！原因二：微服务只有在服务之间存在良好、稳定的边界时才能工作微服务之间的任何功能重构都比在单体中困??难得多。即使是在熟悉的领域工作的经验丰富的架构师也很难在一开始就确定正确的边界。通过首先设置单体，您可以在使用微服务设计之前弄清楚什么是正确的边界。这也让您有时间开发更细粒度的微服务。单体优先策略#1：模块化单体合乎逻辑的方法是仔细设计单体应用程序，注意软件内的模块化，包括API边界和数据存储方式。完成此操作后，从单体应用程序迁移到微服务就相对简单了。Monolith优先级策略二：边缘剥离一种比较常见的方法是从单体开始，逐步剥离微服务的边缘。这种方法在微服务架构的核心留下了一个庞大的整体。大多数新开发都发生在微服务中，而单体则相对静态。Monolith优先级策略3：整体替换很少有人将这种方法视为一种值得骄傲的做法，但将Monolith构建为一种牺牲架构是有益的。不要害怕构建一个你会扔掉的整体，特别是如果一个整体可以让你快速推向市场。Monolith-first策略#4：粗粒度服务从一些粗粒度服务开始，这些服务比您最终得到的微服务更大。使用这些粗粒度的服务来习惯使用多个服务。还可以享受这样一个事实，即这种粗粒度减少了您必须做的服务间重构的数量。然后，随着边界的稳定，分解为更细粒度的服务。微服务还是单体？“单体优先”的理念逐渐开始成为业界的普遍共识。现在属于后微服务时代！在人数少，资金又不是无限充裕的团队中，需要快速将产品推向市场，推荐使用“单体优先”的实现方式。在很多团队中，使用微服务其实是一种HypeDrivenDevelopment（炒作/简历驱动开发），并不是为了真正解决业务问题。使用“单体优先”是务实的选择！试想一下，如果你自己创业，你会选择“单体”还是“微服务”，那么请为你的企业做出务实的选择。参考：https://martinfowler.com/bliki/MonolithFirst.html文章来自：热爱科学的Wesley，如需转载本文，请联系热爱科学的Wesley今天头条号。
