微服务是软件架构的银弹吗？或许不是。这个世界上很少有东西是百分百正确的，微服务也不例外。最近，技术作家迈克尔·丘奇曼（Michael Churchman）发文分享了在设计或重构应用程序时，哪些场景可以使用微服务，哪些场景要避免使用微服务。以下为原文编译内容。
微服务是一个具体的软件服务，通常是基于应用程序上下文而定义的一个规模合理的最小化服务。一个应用程序可以由多个微服务组成，这些服务的部署和管理是独立的，它们组合在一起实现了应用程序的功能。
这意味着我们可以在不重新设计或更新整个应用程序的情况下更新单个微服务，也意味着单个微服务（或多个微服务）发生故障并不会导致整个应用程序瘫痪，一个受到攻击的微服务也不会导致整个应用程序变脆弱。对于复杂的大型应用程序来说，微服务架构比单体架构（传统的非微服务架构）具备更高的可管理性。
既然微服务这么好，为什么不都使用微服务架构呢？事实证明，适用于大型系统的架构不一定适用于规模较小的系统，在设计新系统时所使用的设计方式并不一定适合用来维护或更新已有的系统。具体来说，以下这五种场景是不适合采用微服务的。
1. 复杂性不足
Martin Fowler 曾经说过：“……除非你的系统复杂到难以管理，否则不要考虑采用微服务……”换句话说，相比其他因素，复杂性是采用微服务架构最关键的考虑因素。
微服务架构需要额外的开销，比如服务设计、服务通信、服务管理和系统资源的使用。采用微服务架构是有代价的，如果一个应用程序无法充分利用微服务的优势，那么采用微服务架构所付出的代价就有点太高了。
2. 小团队，大工作
试想有一个中等规模、中等复杂度的应用程序，这个应用程序由一个相对较小的团队负责开发和维护。如果它是一个单体系统，服务之间的通信可以很直接，可以对一些特定的任务进行优化。对于熟悉代码的小团队来说，维护任务就相对容易。可能有时候开发会有点麻烦，但大多数时候是可控的。
如果让这个小团队开发和维护同样的应用程序，但改成了微服务架构，那么他们的工作量就会显著增加。即使是做一个很小的改动也需要更多的时间，甚至还可能需要修改微服务编排和管理系统。这可能会给运维和开发人员造成压力。
3. 小到无法拆分
并不是所有的应用程序都大到足以被拆分成微服务，如果当前规模已经恰到好处了，把它们进一步拆分成微服务不仅不会降低复杂性，反而会让系统变得更复杂。
4. 与遗留系统共舞
大部分软件开发人员几乎每天都要面对遗留代码。如果你正在维护一个遗留系统，那么无论它的原始设计多么随意，无论它现在变得多么糟糕，在把它重构成微服务之前，都要认真地思考一下。它正处在生命周期的什么阶段？它是一个任务关键型系统吗（比如包含了一个不可替代的遗留数据库）？你需要多长时间来替换整个系统？更新或者替换过程需要一个长期详尽的计划吗？
微服务架构在更新或替换遗留系统方面扮演着重要的角色，但整个过程可能很长，一个没有策略指引的迁移很可能会造成灾难性的后果。
5. 紧密集成
有些应用程序要求各个组件和服务之间紧密集成，比如那些需要快速处理实时数据的应用程序。在服务之间添加新层会导致处理速度变慢。如果系统需要快速处理数据流中的数据（例如来自自动驾驶汽车的传感器数据），那么延迟可能是灾难性的。
嵌入式应用程序通常在响应时间和可用资源方面具有很严格的限制，所以它们的后端通常不太适合采用微服务架构。在设计嵌入式应用程序时，从一开始就要考虑如何让维护变得更简单以及如何让资源使用最优化。微服务通常在资源比较充裕的系统中容易发挥作用，可以降低系统的复杂性。
以上就是今天的内容，总之，如果你的应用程序非常大，非常复杂，为了更好地管理它，可以考虑采用微服务架构，但如果它运行得很好，那就不要盲目追赶这个潮流。