微服务需要缴纳附加费，你准备好了吗？

2023-02-28

系统微服务复杂性

Microservicesarevaluable，butcomewithapremiumthatmakesthemunsuitableforless-complexsoftwaresystems.-MartinFowler微服务很有价值，但也有额外的费用，这使得它们不适合不太复杂的软件系统。-马丁·

Microservices are valuable，but come with a premium that makes them unsuitable for less-complex software systems. - Martin Fowler

微服务很有价值，但也有额外的费用，这使得它们不适合不太复杂的软件系统。- 马丁·福勒

Martin Fowler名言

微服务架构风格是这些年的热门话题。我们听到了很多微服务的消息。无论你认为它们是一种新的架构方法，还是仅仅是SOA的重新包装，这个概念都在开发人员社区中掀起巨大的风暴。本文主要思想是基于Martin Fowler的关于微服务的文章，告诉人们应该在什么时候考虑使用微服务。

我们目前能看到的现状是，太多团队太急于接受微服务，而没有意识到微服务为他们自己带来了复杂性。这不仅增加了项目的成本和风险，通常还会使项目陷入严重的麻烦。

虽然围绕微服务的大肆宣传令人讨厌，但微服务这个术语对描述一种存在一段时间的架构风格确实有用。这里重要的不是你对这种炒作有多反感，而是它提出的架构问题：微服务架构对你正在开发的系统来说是一个好的选择吗?

Any decent answer to an interesting question begins,"it depends..." - Kenct Beck

对于一个有趣的问题，任何得体的回答都以“这取决于……”开头。 - 肯特·贝克

Kent Beck名言

我的回答必须以“这取决于”开头，但随后我必须将关注重点转移到取决于哪些因素。是否使用微服务的关键在于你所考虑的系统的复杂性。微服务方法主要是为了处理一个复杂的系统，但为了做到这一点，该方法又引入了自己的一组复杂性。当你使用微服务时，你必须自动部署、监控、处理故障、最终一致性以及分布式系统引入的其他问题。有很多众所周知的方法来处理这些问题，但是这需要额外的努力，而且我所知道的软件开发中似乎没有人有大量的空闲时间。

微服务与复杂性

所以主要指导原则是：除非你的系统太复杂，无法作为一个单体来管理，否则根本不要考虑微服务。大多数软件系统应该构建为单一的单体应用程序。一定要注意在这个单体应用中保持良好的模块化，但不要试图将其分离为单独的服务。

Conway's Law：Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

康威定律：任何设计系统(广义上定义)的组织都将产生一个设计，这个设计的结构是该组织沟通结构的复制。

康威定律

驱使我们使用微服务的复杂性来自许多方面，包括处理：大型团队、多租户、支持多种用户交互模型、允许不同的业务功能独立演进以及可扩展性性。但最大的因素是其庞大的规模 - 人们发现他们拥有一个巨大的单体应用，无法修改和部署。

在这一点上，是让人感到某种挫败感。归咎于单体的许多问题对它这种架构风格来说并不重要。很多人会说，你需要使用微服务，因为不大可能使用单体来实现持续交付。然而，有很多组织成功地使用了千篇一律的部署方法：Facebook和Etsy就是两个著名的例子。

我们也常常听到过这样的说法：随着系统规模的增加，你必须使用微服务，以便拥有易于修改和替换的部件。然而，你没有理由不能开发一个具有良好定义的模块边界的单体应用。至少在理论上没有理由，在实践中，模块边界似乎太容易被打破，单体也很容易被纠缠。

我们还应该记住，不同微服务系统之间的服务规模也有很大的差异：微服务系统从60人的团队和20个服务到4人的团队和200个服务。目前还不清楚服务规模对额外成本的影响程度。

随着规模和其他复杂性因素进入项目，我们看到许多团队发现微服务是一个更好的选择。但除非你面对的是这种类型复杂性，否则请记住，微服务方法会带来很高的代价，这可能会大大减缓你的开发速度。所以，如果你能让你的系统足够简单，避免对微服务的需求，那就去做吧。

结语

就提高团队自主性和更快的变更频率而言，我们仍然相信微服务可以为组织提供巨大显著的优势。来自分布式系统的额外复杂性需要额外的成熟度和投资。但令人担心的是，一些团队急于采用微服务，却不了解做好微服务所需的开发、测试和运营方面的变化。中肯的一般建议仍然很简单：避免微服务羡慕（microservice envy），在匆忙开发更多服务之前，先从一个或两个服务开始，让你的团队有时间调整和理解正确的服务粒度级别。

微服务已经成为现代基于云的系统中的领先架构技术，但我们仍然认为团队在做出这一选择时应该谨慎行事。微服务羡慕诱使团队通过拥有大量的服务来使他们的架构复杂化，仅仅因为这是一种时尚的架构选择。Kubernetes等平台使得部署复杂的微服务集变得更加容易，各种供应商正在推动他们的解决方案来管理微服务，可能会引导团队在这条路上走得更远。但重要的是要记住：微服务以开发的复杂性换取运营的复杂性，并且需要自动化测试、持续交付和DevOps文化的坚实基础。

马丁·福勒是一个软件开发方面的著作者和国际知名演说家，专注于面向对象分析与设计，统一建模语言，领域建模，以及敏捷软件开发方法，包括极限编程。

肯特·贝克（英语：Kent Beck，1961年－），美国著名软体工程师与作家，在软体工程方面有很大的贡献。他是Smalltalk软体的开发者，设计模式的先驱，测试驱动开发的支持者，也是极限编程的创始者之一。曾在Facebook工作，现在在Gusto工作。曾为Smalltalk写作了SUnit单元测试架构，之后将这个架构移植到Java，写作了JUnit。

2001年，他参与了敏捷宣言（Agile Manifesto）的签署，是17名发起者之一。

马尔文·爱德华·康威是计算机科学家、程序员和黑客，他提出了著名的康威定律：“设计系统的架构受制于产生这些设计的组织的沟通结构。”