这5种场景不建议你采用微服务架构

　　在这个世界上没有什么事情是绝对正确的，微服务也不例外，在里，我们着重讨论在设计或重构技术应用程序时，哪些场景可以使用微服务，哪些场景要避免使用微服务。
　　首先，我们要了解什么是微服务能力以及微服务有哪些发展优势。
微服务是什么？
　　顾名思义，微服务工作就是这样一个具体的软件服务，通常是基于应用程序上下文定义的一个发展规模合理的最小化服务，例如，“将文档发送给系统打印机驱动程序”可以算是一个微服务，但“打印字母 n”或许就算不上是，一个应用程序可以由多个微服务组成，这些服务的部署和管理是独立的，它们组合在一起实现了应用程序的功能。

　　这意味着我们可以在不重新设计或更新整个应用程序的情况下更新单个微服务，也意味着单个微服务（或多个微服务）发生故障并不会导致整个应用程序瘫痪，一个受到攻击的微服务也不会导致整个应用程序变脆弱。 对于复杂的大型应用程序，微服务体系结构比单体体系结构（传统的非微服务体系结构）更易于管理。
1. 应对复杂
　　既然微服务这么好，为什么不都使用微服务架构呢？事实证明，适用于大型企业系统的架构不一定适用于规模相对较小的系统。在设计新系统时所使用的设计方式并不一定适合用来维护或更新自己已有的系统。
　　复杂性可能是微服务体系结构的关键考虑因素。Martin Fowler 曾经说过：“……除非你的系统复杂到难以管理，否则不要考虑采用微服务……”。换句话说，相比其他因素，复杂性是采用微服务架构最关键的考虑因素，如果复杂性不是你首要需要解决的问题，那么微服务可能不适合你。
　　微服务架构需要额外的开销，如使用该服务的设计，通信服务，服务管理和系统资源。 采用微服务体系结构是有成本的，如果一个应用程序不能充分利用微服务，那么采用微服务体系结构的成本就有点太高了。
2. 小团队，大工作
　　想象一下，一个中等规模的，中等复杂的应用程序，该应用程序负责开发和维护是一个相对较小的团队。如果它是一个单一的系统，服务之间的通信可以是非常直接的，可以针对特定任务进行优化，对于学生熟悉代码的小团队来说，维护工作任务就相对比较容易。 开发有时可能有点麻烦，但大多数时候它是可控的。
　　如果这个小团队开发和维护相同的应用程序，但将其更改为微服务架构，他们的工作量将显著增加。 微服务之间的通信已经变得普遍，即使是一个小的变化也需要更多的时间，甚至可能需要对微服务编排和管理系统进行更改，这可能会给运维和开发人员造成压力。
3. 小到无法拆分
　　并不是我们所有的应用系统程序都大到足以被拆分成微服务。 一组由中型服务组成的应用程序可能已按要求被拆分，即使它们仍然包含子服务。
　　有些管理模块（比如库存模块和应付账款模块）真的有必要拆分成微服务吗？或者它们其实运行得还不错？他们可能已经大小正好，他们分裂成微服务不仅会降低复杂性，反而会使系统更复杂。
4. 与遗留系统共舞
　　大部分企业软件开发人员几乎每天都要面对遗留代码，如果你正在维护一个遗留系统，那么不管他有原有的设计多随意，无论是现在已经多糟糕，重构成微服务之前，我们必须认真思考，它正处在生命周期的什么阶段？ 是否为任务关键系统（如包含不可替代的遗留数据库）？你需要多长时间来替换整个系统？ 更新或替换过程是否需要长期的详细计划？
　　微服务架构在更新或替换旧系统起着重要作用，但整个过程可能会很长，没有策略的指导将有可能导致灾难性的后果。
5. 紧密集成
　　有些应用需要的各种组件和服务紧密集成，如应用程序需要快速处理的实时数据的应用程序。在服务之间添加新的层会导致处理速度减慢，如果系统需要快速处理的数据（例如来自自动驾驶汽车的传感器数据），则延迟可能是灾难性的。
　　嵌入式应用程序通常在响应时间和可用资源方面发展具有很严格的限制，所以它们的后端通常不太适合采用微服务架构。在设计嵌入式应用程序时，从一开始就要考虑企业如何维护变得更简单以及如何让资源使用最优化， 微服务通常在资源丰富的系统中容易发挥作用，并有助于降低系统的复杂性。
要不要采用微服务？
　　您的应用程序适合用微服务架构？如果它非常大，非常复杂，为了更好地管理它，可以考虑采用微服务架构，但如果它运行得很好，那就不要盲目追赶这个潮流。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！