侧边栏壁纸
博主头像
MobotStone - 技术宅博主等级

行动起来,活在当下

  • 累计撰写 191 篇文章
  • 累计创建 80 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录

为什么不在项目使用微服务

MobotStone
2022-12-27 / 0 评论 / 0 点赞 / 236 阅读 / 1374 字

image-1672140037515

真实案例

1、在多次项目交流中,会经常被问为什么没有使用微服务,很是不解。

其实,那就是个内部系统,用户少、业务简单、数据量小,怎么看也不复杂。

2、领导希望上微服务,专门找了些架构师。

在领导的安排下,架构师们选取了两个新项目进行试点,搞了一年多,勉强上线。

上线后,新项目问题不断。老的项目,也就不再改造了。

Jason Warner的建议

即便是大公司、大团队,想上微服务,也不一定吃得消。

GitHub 前 CTO Jason Warner 也在推特上表示:

I’m convinced that one of the biggest architectural mistakes of the past decade was going full microservice.

(我确信过去十年中,最大的架构错误之一就是全面使用微服务。)

从他的表达可以看出,他不是反对使用微服务,而是不建议全面使用。

不分场景地使用微服务,确实没必要。

Warner给出的建议是:

apps > services > microservices

(单体>应用程序>服务>微服务)

这个建议是很中肯的,也符合现实情况。

现实感受

现实中,技术都要配合业务的节奏。

系统,就不可避免地,按阶段生长。

系统一开始不复杂,需要快速上线,最适合单体应用。

有了三五个系统,需要交互。做好功能规划,按功能细化接口设计,做对接。

系统之间可拆可合,不怕业务变动,不怕组织架构调整,这样的架构一般能扛很久。

业务进一步发展,几个系统之间交互变得复杂了,就需要提高维护效率。

可以抽离一些公共服务,比如统一的身份验证服务等。

剥离出公共服务,业务系统就轻了,可以专注于业务。

架构也合理,各团队理解起来也不复杂。

现实中的系统,随着时间的推移,几乎都是混合的。

架构修修补补,代码看起来像屎山。

其实是一波波程序员智慧的结晶,不宜轻言废立!

0