认识达内从这里开始

认真做教育专心促就业

微服务架构不适合在哪些场景下使用

发布：运城达内教育官网
来源：infoq
时间：2019-12-30 09:58

微服务架构是我们在学习编程开发技术的过程中会逐渐接触和使用的一种架构方式，而今天我们就一起来了解一下关于微服务架构的应用场景都有哪些类型。

微服务架构不适合在哪些场景下使用

1.应对复杂

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

对于微服务架构来说，复杂性可能是一个关键考虑因素。相比其他因素，复杂性是采用微服务架构关键的考虑因素。如果复杂性不是你要解决的问题，那么微服务可能不适合你。

2.小团队，大工作

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

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

3.小到无法拆分

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

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

4.与遗留系统共舞

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

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

5.紧密集成

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

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。

< 上一篇：程序员成长过程中容易培养的不良编程习惯类型

下一篇：运城app应用开发常见的三种应用启动方式 >