在过去的几年里，我曾围绕微服务这个话题采访过数百个人，很多人都自豪地讲述了他们使用微服务架构开发项目的故事。然而，无需太多提问就可以看出他们发射了一枚大火箭，最后却只是干掉了一只老鼠。

微服务很难。每个接触过这类架构的人都有着痛苦的经历。终有一天，你会被复杂性淹没，而且你不得不对架构进行多次重构。我很纳闷，为什么这种架构对开发人员如此有吸引力？然后，我想起十年前自己也被这种框架所吸引。

大多人的共同经历是，他们不得不面对一个遗留下来的单体系统，而且整个代码库都是一团糟。遇到这种情况很令人沮丧。实现需要很长时间，编写测试很乏味甚至几乎不可能，理解代码也很困难，bug 堆积如山，部署也不可靠，每次代码变更都会引发问题。重构遗留代码似乎是不可能的，而且一想到这个问题就会让你觉得头疼，甚至彻夜难眠。

这个时候，微服务就会变得非常具有吸引力。那一刻，小型、可管理、分离的代码库会带给你极大的安全感和解脱感。

但是，使用微服务也是有代价的，而且往往容易被低估。

弊端1：无法正确切分领域

只有当你能够正确切分领域时，使用微服务才有效。然而，领域的划分非常艰难。你需要知道自己构建的是什么，但往往大多数时候我们并不是特别清楚。完全绑定到一个领域，会导致系统的灵活性降低，而这恰恰与你实际的期望背道而驰。

在切分领域时，有可能你还不清楚产品需求。将来难免会出现一个功能，迫使两个服务纠缠在一起，这就导致它们属于同一个领域，却还是分布式的。

弊端2：复杂性

虽然刚开始的时候，微服务的架构看起来非常简单。架构师非常确定这种架构不会被打破，而且对于团队来说，只需要维护一个小型代码库，感觉很舒服。然而到了部署服务时，情况就会发生变化。你需要协调一切。仪表板、监控系统、日志聚合器、部署、CI 作业、警报、文档……而且你引入这些服务只是因为你的架构有这种需求。你需要分布式队列、共享缓存、共享数据库、服务发现、多个负载均衡器、动态路由器、API 网关、中央配置服务器……

于是，代码泥沼变成了基础设施泥沼。优步这样的大公司经历过惨痛的教训后，终于意识到了这一点：

弊端3：过早优化

几十年来，我们将软件分割成了各种服务，只不过我们没有称它们为“微服务”。我们拆分应用程序主要有两个原因。

首先，这种拆分对组织来说有意义。

很明显，我们应该建立两个独立的团队分别负责客户关系管理工具和电子商务平台，尽管这两个平台有时候需要相互交流。这已经是一个面向服务的架构。为了实现销售产品的单一业务目标，我们需要两项服务。只不过我们从未称其为微服务架构。

其次，为了性能。

根据我的经验，受这个原因影响的软件只有1%。如果只有几百个用户，使用垂直扩展就可以了。我们开发的系统有数以万计的并发用户，这些用户与系统进行了大量交互，但我们仍然能够垂直扩展。

我们想要什么？

我们发现了一个问题：遗留系统这个巨大的泥潭。可惜微服务架构并不是解决这个问题的正确方法。你需要的是模块，正确的模块，因为模块使得我们很难越界，而且可以根据需要轻松、独立地部署模块。这个概念本身并不新颖，但很多人往往无法正确实施。

十年前，我想要模块，却采纳了微服务架构，现在是时候结束这种过度设计了。

转：

https://code-held.com/2022/07/28/microservices/