微服务：MonolithFirst？

我一直在研究微服务体系结构，以期全面了解所有优缺点，何时何地为什么。等等。我正在阅读/观看的许多信息都来自ThoughtWorks（Martin Fowler，Neal Ford等）。 al）。

马丁·福勒（Martin Fowler）在该主题上的大部分工作都还存在数年，那时微服务（如果不是一般实践，在编程中是家喻户晓的名字）还很年轻，因此，我对其中的大部分内容持保留态度。

特别要注意的是：

当我听到有关使用微服务架构的团队的故事时，我注意到了一种常见的模式。

• 几乎所有成功的微服务故事都始于一个庞大的整体，并且被分解了
• 在几乎所有我听说过从头构建为微服务系统的系统的情况下，它都遇到了严重的麻烦。

这种模式使我的许多同事争辩说，即使您确定应用程序足够大，也值得这样做，但您不应该使用微服务启动新项目。。

（参考：https : //martinfowler.com/bliki/MonolithFirst.html-强调他们的）

现在，三年后的今天，微服务这个词更普遍了，人们普遍同意一个新系统通常可以通过拥有更大（比微服务大但比整体式小）的服务块来更好地服务，并且作为进化措施的一部分，它们是否更细化？

或者，与上述陈述相比，是否有规范从头开始使用粒度微服务架构开始项目？

似乎是理智的一般方法，但对社区的思想感到好奇。

如果您的公司已经进行了一段时间的微服务，那么可能已经构建了一些微服务，而您只需要合并它们即可。可能的示例可能是作为服务的身份验证或存储Blob数据。在这种情况下，您已经定义了边界，并在新应用程序中重用了代码。这是好事。

对于不确定边界需要在哪里的新代码，请在一项服务中进行构建。如果保持模块化，则可以根据需要从中拆分微服务。特别是当您发现服务的各个部分需要与其他部分进行不同的扩展时。

微服务的好处是您可以添加实例以扩展按需完成的工作。如果您的某些工作突如其来，可能有必要将其分离到自己的微服务中。

一般来说：

• 如果您已经构建了微服务，请重用它们
• 如果您要构建新的东西，请先将想法付诸实践
• 在构建时，请尝试使事物保持模块化，以便可以轻松分解某些服务
• 在构建过程中，如果您的服务的一部分需要能够以不同的速率按需扩展，则可以将其分成自己的服务

很多时候，我们会听到像马丁·福勒这样的声誉卓著的聪明人的有用指导，然后将其转变成一个坚不可摧的学说，无论如何都不能改变。

您必须本着自己的意思接受这样的陈述。马丁·福勒（Martin Fowler）试图通过分析使人们摆脱瘫痪，并告诉他们建立起最有效的方法。当您进一步了解应用程序的实际工作原理时，可以随时将其拆分。

通过简单的代码模块化，可以实现微服务最直接的价值。您可以使用任何模块系统（Maven，npm，nuget等）将功能组隔离到模块中。每个模块都可以服务于一个目的，可以拥有自己的存储库，使用自己的数据库架构，管理自己的配置，拥有自己的功能积压和发布时间表。它们仍然可以一起部署在一个整体上。这是非常可管理的开销，并带来了一些好处。更大的开销来自分离部署，这只有在您有足够的规模来实现它时才真正有价值。如果您的代码已经模块化，那么在需要的时候它将变得更容易迁移。

我认为，首先开发一个整体（或更好的方法是：将应用程序的一部分开发为整体）可能会有所帮助。

在某些情况下，您不确定问题的范围和边界（例如，我建立了船舶管理站点，是否需要船舶服务和船队服务，或者船舶服务是否足够？），在这种情况下，整体可能更容易开发。

如果您需要将各种技术结合使用（例如，您现有的部分是用C＃编写的，但是您的新问题需要机器学习，最好使用python来完成），则应该停止这样做，对您的域有一个很好的了解专案或您的整体方案来刺激，例如，每个人都只是建造这种整体并压缩单独服务的概念。

我敢肯定，关于MF的这篇确切文章有几个问题。

我的看法是这样的：

具有维护或可伸缩性问题的Monolith通过将其细分为微服务而得到改善。这样的项目几乎总是“成功的”，因为即使分解一小部分也可以带来可观的收益，并且当您感到高兴时可以在其下画一条线。

是否将半个整体+一条消息队列和几个工作进程视为“微服务架构”，这是使酒馆倒闭的一个理由，但是当您谈论该项目时，您肯定会称呼它。

另一方面，无论选择哪种体系结构，任何新项目都存在无法达到预期的风险，因此自然而然地，您会期望较低的成功率。另外，如果您最初的目标是从头开始打造整个“最佳实践微服务架构”，那么您可能会尝试新技术和微服务的艰巨任务。

我们还必须记住，MF是从大的OOP角度编写的。他自然对更现代的分布式方法表示怀疑。

在这个时代，我希望任何大型企业解决方案都可以包含微服务元素，只有傻瓜才会建议您制作一个巨型的整体应用程序，除非您要分发单个桌面样式的应用程序。

在我的丰富经验中，我目睹了更多的项目失败是由于人员问题而不是技术问题。不幸的是，人们不喜欢失败，因此往往会错误地报告失败的原因并归咎于技术。

在我的金融领域，如今，大多数新项目都遵循微服务架构，从TCO（总拥有成本）的角度来看，它似乎是一个成功的架构。这些项目似乎并不会经常失败，而且当他们这样做时，给出的原因并不经常将应用程序体系结构列为问题。