抖音技术能力大揭密!钜惠大礼、深度体验,尽在火山引擎增长沙龙,就等你来! 立即报名>> 了解详情
写点什么

MonolithFirst:单体应用优先策略

2015 年 6 月 09 日

微服务是近年兴起的一个概念,是指将应用程序设计成一套可以单独部署的服务。 Martin Fowler ThoughtWorks 的首席科学家。他与 ThoughtWorks 首席顾问 James Lewis 合作发表的《微服务》,可谓是了解微服务架构风格的入门必读。近日,Fowler 又提出了 MonolithFirst 策略。

在许多使用微服务架构的案例中,Fowler 注意到了如下两种常见的模式:

  • 几乎所有成功的微服务案例都始于分解过大的“单体(monolith)”应用;
  • 几乎所有从头构建的微服务系统最后都陷入了麻烦。

Fowler 认为,虽然微服务是一种有用的架构,但由于会产生“微服务佣金( MicrservicePremium )”,所以它只适用于复杂的系统。服务管理成本会减缓项目进度,因此,简单的应用更适合采用单体架构。在此基础上,他提出了 MonolithFirst 策略,其基本思想是:即使应用后续可能受益于微服务架构,但开始时仍然将新应用构建为单体应用。这主要是出于以下两个方面的考虑:

  • Yagni 原则——确定软件思路是否有用,最好的方法是创建一个简化版本,然后看它的使用效果。在这个阶段,最重要的是速度,而该原则可缩短反馈周期,避免微服务佣金。
  • 明确的有界上下文集合——只有服务存在良好且稳定的边界,微服务才能有效地发挥作用。但是,任何微服务间的功能重构都比在单体架构中难度大,即使是经验丰富的架构师在自己熟悉的领域里,也很难在一开始就恰当地定义出边界,而首先构建一个单体应用有利于明确功能边界。

Fowler 列举了如下几种 MonolithFirst 策略执行方法:

  1. 仔细设计一个单体应用,留意软件模块划分,包括 API 边界和数据存储方式。做好这些工作后,向微服务切换就相对简单了。
  2. 开始时采用单体架构,然后逐步从系统边缘剥离出微服务。
  3. 首先构建一个单体架构作为“牺牲架构(SacrificialArchitecture)”,然后整个的替换掉。
  4. 以几个粒度较大的服务开始,待功能边界稳定后再分解成细粒度的服务。

对于第一种方法,Fowler 指出,并不是任何一个系统都可以分解成微服务。有许多系统,由于模块之间相互依赖度太高而难以分开。而且,目前为止,他还没有看到多少采用这种方法的成功案例。第二种方法会在微服务架构的内部保留一部分单体架构,新开发功能采用微服务架构模式。对于第三种方法,Fowler 提醒说,“不要害怕构建一个将来会被丢弃的单体应用,尤其是当它能使软件快速推向市场时。”第四种方式可以让团队获得服务开发及管理经验,而粗粒度的服务还能减少服务间的重构,这有利于后续向微服务迁移。

Fowler 承认,他现在还不知道如何确定一个项目是否要使用 MonolithFirst 策略。但同时,他认为,除非团队有适当的微服务系统构建经验,否则,不要从微服务开始构建一个新系统。Sam Newman 是 Fowler 的同事,他分享了一个团队考虑在新项目中使用微服务的案例,感兴趣的读者可以进一步阅读。

Fowler 的文章在Hacker News 上引发了激烈的讨论,许多网友都提出了不同的看法,krisdol 就是其中之一。他认为,Fowler 的观点与他所处的环境有很大的关系。ThoughtWorks 是一家帮助其他公司解决问题的顾问公司,也就是说,他们会在某个公司的单体应用出现问题时提供帮助,将其重构为微服务架构。因此,Fowler 才能得出MonolithFirst 的结论。而实际上,现在已经有许多微服务优先的案例,只是身在顾问公司的Fowler 接触到的可能比较少。所以他的观点是,微服务优先,尤其对小团队而言,比每个人都共享同一个代码库更有助于项目的快速进展。

而有两年微服务开发经验的网友room271 则表达了相反的观点,他认为,在小公司/ 团队中,采用微服务可能不太明智,因为它对技能的要求比较高,会导致得不偿失。但同时,他觉得,MonolithFirst 是顾问公司的立场,因为当单体应用出现问题时,他们可能已经完成项目离开了。

当然,也有许多网友表示支持,认为微服务设计很难上手也很难重构,而且对技能要求太高。网友btilly 就指出,即使不采用MonolithFirst 策略,构建一个原型单体系统也是很有价值的。


感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015 年 6 月 09 日 08:101899
用户头像

发布了 1008 篇内容, 共 322.2 次阅读, 收获喜欢 293 次。

关注

评论

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

实战 Java8-CompletableFuture

lee

Java 多线程 java8 CompletableFuture

怎么控制老板不断加需求?

kimmking

谈谈控制感(10):怎么做一个靠谱的人

史方远

职场 心理 成长

我的时间管理之路(附工具集合及使用心得)

YoungZY

App 时间管理

一文带你彻底厘清 Kubernetes 中的证书工作机制

首富手记

Kubernetes

python实现·十大排序算法之希尔排序(Shell Sort)

南风以南

Python 排序算法 希尔排序

写给产品经理的信(2):产品设计能力怎样进阶

punkboy

产品 个人成长 产品经理 产品设计 进阶

要和竞争对手做比较吗?

邓瑞恒Ryan

创业 战略管理

自制操作系统

贾献华

【转载】如何在团队中做好Code Review?

北纬32°

已发表的技术文章-大数据方面

绝影-大数据

技术工作中的颜值

N维空间的尘埃

孩子,我们在睡前一起来阅读 15 分钟的好书,让彼此都带着好的故事入眠。

叶小鍵

正确阅读 托马斯·奥本 Doug Antin 蒂·泰德罗克

面试官问你MyBatis SQL是如何执行的?把这篇文章甩给他

cxuan

mybatis

我们都可能陷入经济困境

董一凡

生活

关于用户体验的一些思考

brave heart

android 产品开发

不要抱怨,也别憋屈

孙苏勇

职场 随笔杂谈

内容比形式更重要

Winann

内容 生活 工作 形式主义

Java开发工具与HelloWorld

编号94530

Java eclipse Hello World ! IDEA 开发工具

docker19.03读取NVIDIA显卡

首富手记

Docker Dockerfile

阿里的OceanBase上天了,但你还不会用Explain看SQL的查询计划吗?

Super~琪琪

MySQL 数据库 后台开发 后端

如何在团队中做好Code Review

Ken

团队协作 代码审查 Code Review 代码质量

ARTS打卡 第1周

引花眠

ARTS 打卡计划

ARTS week 1

丽子

重新开始,被自己搞砸的生活

小天同学

个人感想 日常思考

字符与编码

引花眠

计算机基础 utf-8

C#刷遍Leetcode面试题系列连载(1) - 入门与工具简介

Python名人堂

C# .net 算法 LeetCode

这个名字,你不能再读错了

小天同学

历史 科普

有点干货 | Jdk1.8新特性实战篇(41个案例)

小傅哥

函数式接口 Lambda 小傅哥 jdk8 编码

Java运算符实际运用

凌轩

Java 编程语言

df 和 ls 命令执行夯主

首富手记

生产力

Study Go: From Zero to Hero

Study Go: From Zero to Hero

MonolithFirst:单体应用优先策略-InfoQ