微服务是软件架构的银弹吗？或许不是。这个世界上很少有东西是百分百正确的，微服务也不例外。

在这篇文章里，我们将讨论在设计或重构应用程序时，哪些场景可以使用微服务，哪些场景要避免使用微服务。

首先，我们要了解什么是微服务以及微服务有哪些优势。

微服务是什么？为什么要使用微服务？

顾名思义，微服务就是一个具体的软件服务，通常是基于应用程序上下文定义的一个规模合理的最小化服务。例如，“将文档发送给系统打印机驱动程序”可以算是一个微服务，但“打印字母n”或许就算不上是。一个应用程序可以由多个微服务组成，这些服务的部署和管理（部署在pod 或集群中）是独立的，它们组合在一起实现了应用程序的功能。

这意味着我们可以在不重新设计或更新整个应用程序的情况下更新单个微服务，也意味着单个微服务（或多个微服务）发生故障并不会导致整个应用程序瘫痪，一个受到攻击的微服务也不会导致整个应用程序变脆弱。对于复杂的大型应用程序来说，微服务架构比单体架构（传统的非微服务架构）具备更高的可管理性。

1. 应对复杂

既然微服务这么好，为什么不都使用微服务架构呢？事实证明，适用于大型系统的架构不一定适用于规模较小的系统，在设计新系统时所使用的设计方式并不一定适合用来维护或更新已有的系统。

对于微服务架构来说，复杂性可能是一个关键考虑因素。 Martin Fowler 曾经说过：“……除非你的系统复杂到难以管理，否则不要考虑采用微服务……”换句话说，相比其他因素，复杂性是采用微服务架构最关键的考虑因素。如果复杂性不是你首要解决的问题，那么微服务可能不适合你。

微服务架构需要额外的开销，比如服务设计、服务通信、服务管理和系统资源的使用。采用微服务架构是有代价的，如果一个应用程序无法充分利用微服务的优势，那么为了采用微服务架构而付出的代价就有点太高了。

2. 小团队，大工作

试想有一个中等规模、中等复杂度的应用程序，这个应用程序由一个相对较小的团队负责开发和维护。如果它是一个单体系统，服务之间的通信可以很直接，可以对一些特定的任务进行优化。对于熟悉的代码的小团队来说，维护任务就相对容易。可能有时候开发会有点麻烦，但大多数时候是可控的。

如果让这个小团队开发和维护同样的应用程序，但改成了微服务架构，那么他们的工作量就会显著增加。微服务之间的通信变得很普遍，即使是做一个很小的改动也需要更多的时间，甚至还可能需要修改微服务编排和管理系统。这可能会给运维和开发造成压力。

3. 小到无法拆分

并不是所有的应用程序都大到足以被拆分成微服务。一组由中等规模服务组成的应用程序可能已经按照要求拆分完毕，即使这些服务仍然包含了子服务。

有些模块（比如库存模块和应付账款模块）真的有必要拆分成微服务吗？或者它们其实运行得还不错？可能它们现在的规模已经是恰到好处了，把它们进一步拆分成微服务不仅不会降低复杂性，反而会让系统变得更复杂。

4. 与遗留系统共舞

大部分软件开发人员几乎每天都要面对遗留代码。如果你正在维护一个遗留系统，那么无论它的原始设计多么随意，无论它现在变得多么糟糕，在把它重构成微服务之前，都要认真仔细地思考一下。它正处在生命周期的什么阶段？它是一个任务关键型系统吗（比如包含了一个不可替代的遗留数据库）？你需要几年时间来替换整个系统吗？更新或者替换过程需要一个长期详尽的计划吗？

微服务架构在更新或替换遗留系统方面扮演着重要的角色，但整个过程可能很长，一个没有策略指引的迁移很可能会造成灾难性的后果。

5. 紧密集成

有些应用程序要求各个组件和服务之间紧密集成，比如那些需要快速处理实时数据的应用程序。在服务之间添加新层会导致处理速度变慢。如果系统需要快速处理数据流中的数据（例如来自自动驾驶汽车的传感器数据），那么延迟可能是灾难性的。

嵌入式应用程序通常在响应时间和可用资源方面具有很严格的限制，所以它们的后端通常不太适合采用微服务架构。在设计嵌入式应用程序时，从一开始就要考虑如何让维护变得更简单以及如何让资源使用最优化。微服务通常在资源比较充裕的系统中容易发挥作用，可以帮助降低系统的复杂性。

要不要采用微服务？

你的应用程序适用采用微服务架构吗？如果它非常大，非常复杂，为了更好地管理它，可以考虑采用微服务架构。但如果它运行得很好，那就不要盲目追赶这个潮流。