这 种场景不适合采用微服务.docxVIP

这 5 种场景不适合接受微服务 顾名思义，微服务就是一个具体的软件服务，通常是基于应用程序上下文定义的一个规模合理的最小化服务。例如，“将文档发送给系统打印机驱动程序”可以算是一个微服务，但“打印字母n”或许就算不上是。一个应用程序可以由多个微服务组成，这些服务的部署和管理（部署在pod 或集群中）是独立的，它们组合在一起实现了应用程序的功能。 这意味着我们可以在不重新设计或更新整个应用程序的情况下更新单个微服务，也意味着单个微服务（或多个微服务）发生毛病并不会导致整个应用程序瘫痪，一个遭到攻击的微服务也不会导致整个应用程序变脆弱。对于简单的大型应用程序来说，微服务架构比单体架构（传统的非微服务架构）具备更高的可管理性。 1. 应对简单 既然微服务这么好，为什么不都使用微服务架构呢？现实证明，适用于大型系统的架构不肯定适用于规模较小的系统，在设计新系统时所使用的设计方式并不肯定适合用来维护或更新已有的系统。 对于微服务架构来说，简单性可能是一个关键考虑因素。?Martin Fowler?已经说过：“……除非你的系统简单到难以管理，否则不要考虑接受微服务……”换句话说，相比其他因素，简单性是接受微服务架构最关键的考虑因素。假如简单性不是你首要处理的问题，那么微服务可能不适合你。 微服务架构需要额外的开销，比如服务设计、服务通信、服务管理和系统资源的使用。接受微服务架构是有代价的，假如一个应用程序无法充分利用微服务的优势，那么为了接受微服务架构而付出的代价就有点太高了。 2. 小团队，大工作 试想有一个中等规模、中等简单度的应用程序，这个应用程序由一个相对较小的团队担任开发和维护。假如它是一个单体系统，服务之间的通信可以很直接，可以对一些特定的任务进行优化。对于生疏的代码的小团队来说，维护任务就相对简约。可能有时候开发会有点麻烦，但大多数时候是可控的。 假如让这个小团队开发和维护同样的应用程序，但改成了微服务架构，那么他们的工作量就会显著添加。微服务之间的通信变得很普遍，即便是做一个很小的改动也需要更多的时间，甚至还可能需要修改微服务编排和管理系统。这可能会给运维和开发形成压力。 3. 小到无法拆分 并不是全部的应用程序都大到足以被拆分成微服务。一组由中等规模服务组成的应用程序可能已经依据要求拆分完毕，即便这些服务仍旧包含了子服务。 有些模块（比如库存模块和应付账款模块）真的有必要拆分成微服务吗？或者它们其实运转得还不错？可能它们现在的规模已经是恰到好处了，把它们进一步拆分成微服务不只不会降低简单性，反而会让系统变得更简单。 4. 与遗留系统共舞 大部分软件开发人员几乎每天都要面对遗留代码。假如你正在维护一个遗留系统，那么无论它的原始设计多么任凭，无论它现在变得多么蹩脚，在把它重构成微服务之前，都要认真认真地思考一下。它正处在生命周期的什么阶段？它是一个任务关键型系统吗（比如包含了一个不行替代的遗留数据库）？你需要几年时间来替换整个系统吗？更新或者替换过程需要一个长期详尽的方案吗？ 微服务架构在更新或替换遗留系统方面扮演着重要的角色，但整个过程可能很长，一个没有策略指引的迁移很可能会形成灾难性的后果。 5. 紧密集成 有些应用程序要求各个组件和服务之间紧密集成，比如那些需要快速处理实时数据的应用程序。在服务之间添加新层会导致处理速度变慢。假如系统需要快速处理数据流中的数据（例如来自自动驾驶汽车的传感器数据），那么延迟可能是灾难性的。 嵌入式应用程序通常在响应时间和可用资源方面具有很严格的限制，所以它们的后端通常不太适合接受微服务架构。在设计嵌入式应用程序时，从一开头就要考虑如何让维护变得更简约以及如何让资源使用最优化。微服务通常在资源比较充裕的系统中简约发挥作用，可以挂念降低系统的简单性。 要不要接受微服务？ 你的应用程序适用接受微服务架构吗？假如它格外大，格外简单，为了更好地管理它，可以考虑接受微服务架构。但假如它运转得很好，那就不要盲目追逐这个潮流。