文档章节

[译]一体化架构(Monolithic Architecure)

douxingxiang
 douxingxiang
发布于 2014/12/16 23:04
字数 1738
阅读 6185
收藏 103

This a translation of an article ( http://microservices.io/patterns/monolithic.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

模式:一体化架构

背景

假设你在开发一个服务端应用。该应用必须支持各种各样的客户端,包括桌面浏览器、手机浏览器和本地手机应用。应用可能也需要公开部分API供第三方使用,还可能与其他应用通过web service或消息代理(message broker)相集成。应用执行业务逻辑来处理请求(HTTP请求或者消息);访问数据库;与其他系统交换消息;并返回HTML/JSON/XML类型的响应。

应用或是多层架构或是六角架构,并且包含多种类型的组件:

  • 表示组件(Presentation components) - 响应处理HTTP请求,并返回HTML或JSON/XML(对于web service API)

  • 业务逻辑(Business logic) - 应用的业务逻辑

  • 数据库访问逻辑(Database access logic) - 数据访问对象用于访问数据库

  • 应用集成逻辑(Application integration logic) - 消息层,如基于Spring的集成

这些逻辑组件分别响应应用中不同的功能模块。

问题

应用的部署架构是什么?

推动力

  • 该应用由一个开发者团队在维护

  • 团队新成员必须快速上手

  • 应用应该易于理解和修改

  • 你想对应用进行持续集成

  • 你必须在多台机器上部署多份应用的拷贝,以满足可伸缩性和可用性的要求

  • 你想使用新技术(框架、编程语言等)

解决方案

使用一体化架构构建应用。如:

  • 单个Java WAR文件

  • 单个Rails或NodeJS目录结构

举例

我们假设你在构建一个电子商务应用,应用从客户接收订单,验证库存和可用额度,并派送订单。应用包含多个组件,包括StoreFrontUI,用来实现用户接口,以及一些后台服务,用于检测信用额度、维护库存和派送订单。

应用作为一体应用部署。例如,一个Java web应用运行在Tomcat之类web容器上,仅包含单个WAR文件;一个Rails应用使用Phusion Passenger部署在Apache/Nginx上,或者使用JRuby部署在Tomcat上,它们都仅包含单个目录结构。为了伸缩和提高可用性,你可以在一个负载均衡器下面运行该应用的多份实例。

结果

这个方案有一些好处:

  • 易于开发 - 当前开发工具和IDE的目标就是支持这种一体应用的开发

  • 易于部署 - 你只需要将WAR文件或目录结构放到合适的运行环境下

  • 易于伸缩 - 你只需要在负载均衡器下面运行应用的多份拷贝就可以伸缩

但是,一旦应用变大、团队增长,这种方法的缺点就愈加明显:

  • 巨大的一体代码库可能会吓到开发者,尤其是团队的新人。应用难于理解和修改。因此,开发速度通常会减缓。另外,由于没有模块硬边界,模块化也随时间而破坏。还有,因为难于理解如何实现变更,代码质量也随时间下降。这是个恶性循环!

  • 超载的IDE - 代码库越大,IDE越慢,开发者效率越低。

  • 超载的web容器 - 应用越大,容器启动时间越长。因此开发者大量的时间被浪费在等待容器启动上。这也会影响到部署。

  • 难于持续部署 - 对于频繁部署,巨大的一体应用也是个问题。为了更新一个组件,你必须重新部署整个应用。这还会中断后台任务(如Java应用的Quartz作业),不管变更是否影响到这些任务,此外还可能引发问题。未被更新的组件也可能因而不能正常启动。因此,鉴于重新部署的相关风险会增加,不鼓励频繁更新。这尤其对用户界面的开发者来说是个问题,因为他们通常需要快速迭代,频繁重新部署。

  • 难于伸缩应用 - 一体架构只能在一个维度伸缩。一方面,它可以通过运行多个拷贝来伸缩满足业务量的增加。某些云服务甚至可以动态地根据负载调整应用实例的数量。但是另一方面,该架构不能伸缩满足数据量的增加。每个应用实例都要访问全部数据,这使缓存低效,并且提升了内存占用和I/O流量。而且,不同的组件所需资源不同 - 有些可能是CPU密集型的,另一些可能是内存密集型的。一体架构下,我们不能独立伸缩各个组件。

  • 难于调整开发规模 - 一体应用对调整开发规模也是个障碍。一旦应用达到一定规模,将工程组织分成专注于特定功能模块的团队通常更有效。比如,我们可能需要UI团队,会计团队,库存团队等。一体应用的问题是它阻碍组织团队相互独立地工作。团队之间必须在开发进度和重新部署上进行协调。对团队来说也很难改变和更新产品。

  • 需要对一个技术栈长期投入 - 一体架构迫使你娶下开发初选择的技术栈(某些情况下,是那项技术的某个版本)。一体架构下,很难递增式地采用更新的技术。比如,想象下你选了JVM。除了Java你还可以选择其他使用JVM的语言,它们比如Groovy和Scala也可以与Java很好地进行互操作。但是一体架构下,非JVM语言写的组件就不行。而且,如果应用使用了后期过时的平台框架,将应用迁移到更新更好的框架上就很有挑战性。还有可能,为了采用新的平台框架,你要重写整个应用,这就太冒险了。

相关模式

微服务架构是解决一体化架构缺点的替代模式。

已知案例

著名的互联网服务,如Netflix, Amazon.com和eBay开始都使用一体架构。作者开发的大部分web应用也是一体架构的。

变更


第一篇:一体化架构(Monolithic Architecture)

第二篇:微服务架构(Microservices Architecure)

            伸缩立方(Scale Cube)

第三篇:API网关(API Gateway)

© 著作权归作者所有

douxingxiang
粉丝 30
博文 12
码字总数 16723
作品 0
徐汇
程序员
私信 提问
加载中

评论(14)

谭世霖
虽然是发表于三年前,但是我相信经过这么多年的浏览,如此细小的问题也应该早就被发觉了
谭世霖
在---》
难于持续部署 - 对于频繁部署,巨大的一体应用也是个问题。为了更新一个组件,你必须重新部署整个应用。这还会中断后台任务(如Java应用的Quartz作业),不管变更是否影响到这些任务,此外还可能引发问题。未被更新的组件也可能因而不能正常启动。因此,鉴于重新部署的相关风险会增加,不鼓励频繁更新。这尤其对用户界面的开发者来说是个问题,因为他们通常需要快速迭代,频繁重新部署。
《---
一段中的“”中断后台任务“”,这个其实是没有问题,因为就算是单体架构,如果运维架构师做的好,会对需要升级的服务器进行慢慢较少接收任务,直到为0,至于像这种定时服务,会将数据通过备份导入到另外服务器中,完全不会说一下关掉所有的服务器进行升级,而是选择选择在平稳时段关掉一半服务器,在升级另外一半服务器之后,利用DNS平滑上线已升级服务器,而接下来升级另一半服务器,但是这样也是有瓶颈的
郭恩洲_OSC博客
郭恩洲_OSC博客
看懂了,很有感触
douxingxiang
douxingxiang 博主

引用来自“BaiYang”的评论

并且持续集成时也可以以模块、插件为单位,而不需要每次都做 whole world deployment。当然,即使这样 AIO 也有自己的缺点,仍然是需要根据具体情况进行权衡的。
赞@BaiYang,确实不管新的还是旧的技术/框架/库都是满足“特定时间”下“特定场景”的“特定需求”的,大家都有自己的适用范围
BaiYang
BaiYang
并且持续集成时也可以以模块、插件为单位,而不需要每次都做 whole world deployment。当然,即使这样 AIO 也有自己的缺点,仍然是需要根据具体情况进行权衡的。
BaiYang
BaiYang
这不就是 SOA 和 AIO(All-in-one)之间的权衡么。各有利弊,各有适应的场合,而且 AIO 也可以做成模块化、插件化,每个开发人员只需要了解自己的模块。
douxingxiang
douxingxiang 博主

引用来自“开源中国投资人”的评论

看了两遍也没看到..到底说的是什么意思..我的经验告诉我 所有功能能拆分的话就拆分到最细化.模块之间分开部署.业务交叉的地方使用接口.但是博主这篇文章真心没读懂..想表达的是什么样的架构呢?
monolithic跟microservice做对比的,两者组织的方式不同。monolithic是普通的组织方式,比如我们要写一个网站,选择Rails框架,那么所有的业务逻辑都在一个目录下,rails的运行容器监听一个端口响应客户端请求;但是微服务,可能把功能分拆后,每一个单独的功能都做成一个小网站形式,监听不同的端口,每个功能可能用rails,也可以用django,zend等等,不同的小网站直接通过HTTP/JSON/XML等协议进行通信。后面还有一篇介绍微服务架构,可以对比起来看
douxingxiang
douxingxiang 博主

引用来自“寒凉”的评论

摘要中原文url有错,域名microservice.io少了一个字母"s", 正确链接是——http://microservices.io/patterns/monolithic.html
多谢@寒凉, 已更正
寒凉
寒凉
摘要中原文url有错,域名microservice.io少了一个字母"s", 正确链接是——http://microservices.io/patterns/monolithic.html
netkiller-
netkiller-
看不懂
OSChina 技术周刊第十四期 —— 每周技术精粹

每周技术抢先看,总有你想要的! 移动开发 【软件】医疗和生物医学移动应用框架 mHealhDroid 【博客】Android Studio 使用NDK开发 【博客】Android 4.4(KK)中利用APP打开关闭数据流量 前端...

OSC编辑部
2014/12/21
2.6K
1
[译]API网关(API Gateway)

This a translation of an article ( http://microservices.io/patterns/apigateway.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson). 模......

douxingxiang
2014/12/19
20.9K
2
[译]微服务架构(Microservices Architecture)

This a translation of an article ( http://microservices.io/patterns/microservices.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).......

douxingxiang
2014/12/18
10.7K
0
Kotlin 很受 Java 开发人员的欢迎

RebelLabs通过深入调查得到2017年开发者生产力报告,该报告重点介绍为什么开发人员使用这些工具以及他们对开发工具,体系结构还有其他方面的满意程度。 该报告是基于全球Java开发人员超过200...

周其
2017/11/18
3.9K
21
服务治理好文章{转}

微服务架构是由Martin Fowler在他这篇microservices博客中提出来的,与之对立的是monolithic架构。 monolithic架构概念 vs. 微服务架构概念 monolithic架构指的是应用被以单一单元构建。比如...

强子哥哥
2016/08/26
42
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周三乱弹 —— 调查人员问狗 那你在做什么啊?

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 小小编辑推荐:《Let It Be》- John Denver 《Let It Be》- John Denver 手机党少年们想听歌,请使劲儿戳(这里) @FalconChen :每天看一遍,...

小小编辑
今天
6
0
高效程序员的45个习惯总结版-文末脑图

1 做事 一个重大的错误应该被当做一次学习而不是指责他人的机会,团队成员一起工作,应该互相帮助,而不是互相指责 2 欲速则不达 不要为了修复问题而去修复,要投入时间和精力保持代码整洁 ...

阿提说说
今天
18
0
带南海九段线分位数地图可视化(R语言版)

今天带来一篇承诺虾神的可视化博客。内容是使用R语言进行带南海九段线分位数地图可视化。虾神的原博文地址如下(Python版)。 Python实现带南海九段线分位数地图完整可视化版本(附代码及数据...

胖胖雕
今天
12
0
Nginx 的进程结构,你明白吗?

Nginx 进程结构 这篇文章我们来看下 Nginx 的进程结构,Nginx 其实有两种进程结构: 单进程结构 多进程结构 单进程结构实际上不适用于生产环境,只适合我们做开发调试使用。因为在生产环境中...

武培轩
今天
20
0
蓝鲸平台部署

环境 系统:Centos7 依赖包:java8 主机: 10.0.1.150 域名:paas.ops.net;cmdb.ops.net;job.ops.net 生成SSH key ssh-keygen -t rsa -P '' 生成证书 https://bk.tencent.com/download_ssl/......

以谁为师
今天
7
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部