写点什么

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

  • 2019-12-27
  • 本文字数:1759 字

    阅读完需:约 6 分钟

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

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


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


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

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

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


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

1. 应对复杂

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


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


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

2. 小团队,大工作

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


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

3. 小到无法拆分

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


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

4. 与遗留系统共舞

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


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

5. 紧密集成

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


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

要不要采用微服务?

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

英文原文

5 Reasons Not to Use Microservices


2019-12-27 15:556137
用户头像
小智 让所有人认同的文字称不上表达

发布了 408 篇内容, 共 402.9 次阅读, 收获喜欢 1986 次。

关注

评论

发布
暂无评论
发现更多内容

GaussDB CN服务异常实例分析

华为云开发者联盟

数据库 华为云 GaussDB

诚迈科技深耕汽车操作系统领域,获评优质供应商

科技热闻

解读Vue3模板编译优化

yyds2026

Vue

技术分享 | TiUP工具 - TiDB集群滚动升级核心流程解析

TiDB 社区干货传送门

TiFlash 源码阅读(六) DeltaTree Index 的设计和实现分析

TiDB 社区干货传送门

Vue3, setup语法糖、Composition API全方位解读

yyds2026

Vue

安防厂商在企业数字化转型中的机遇和挑战

慕枫技术笔记

AIOT 11月月更

React性能优化的8种方式

xiaofeng

React

React-hooks+TypeScript最佳实战

xiaofeng

React

Vue.nextTick核心原理

yyds2026

Vue

Webpack中的plugin插件机制

Geek_02d948

webpack

深度解读Webpack中的loader原理

Geek_02d948

webpack

React生命周期深度完全解读

夏天的味道123

React

# 分布式数据库新秀TIDB初探

TiDB 社区干货传送门

TiDB 底层架构 TiDB 源码解读

React中常见的TypeScript定义实战

xiaofeng

React

低代码实现探索(五十三)后台逻辑的控制

零道云-混合式低代码平台

将业务从mysql迁移至TIDB,有哪些需要注意的?

TiDB 社区干货传送门

管理与运维 应用适配 大数据场景实践

TiFlash 源码阅读(八)TiFlash 表达式的实现与设计

TiDB 社区干货传送门

老板拍脑袋决策,团队群魔乱舞

填空时光

决策 团队内耗 企业敏捷

React的5种高级模式

夏天的味道123

React

React源码中的dom-diff

夏天的味道123

React

10年码农生涯经验总结,聊聊工作中18种接口优化方案!

Java全栈架构师

Java 数据库 程序员 程序人生 性能优化

双机热备软件原理简单说明以及品牌重点推荐

行云管家

高可用 ha 热备 双机热备

详解webpack构建优化

Geek_02d948

webpack

CQRS与Event Sourcing

胖子笑西风

架构 DDD CQRS Event Sourcing #java

技术分享 | 多测试环境的动态伸缩实践

LigaAI

云原生 自动化测试框架 测试环境 测试自动化 kubenetes

使用Docker踩坑,排查完问题之后,又涨知识了

程序员小毕

Java Docker 程序员 程序人生 后端

TiDB常用SQL

TiDB 社区干货传送门

性能调优 集群管理

AntDB入选《2022爱分析·信创厂商全景报告》

亚信AntDB数据库

AntDB 信创 国产数据库 aisware antdb AntDB数据库

教你一招,安全的从 MySQL 切换到 TiDB

TiDB 社区干货传送门

迁移 实践案例

TiFlash 源码阅读(七)TiFlash Proxy 模块

TiDB 社区干货传送门

这5种场景不适合采用微服务_架构_Michael Churchman_InfoQ精选文章