系统为什么需要分层?

在日常的软件开发当中,我们一般都是采用了分层的方式来架构系统,但是为什么我们需要分层进行架构呢?在此之前,我觉得需要搞明白两个概念,什么是软件的伸缩性,什么是性能。

首先,什么是软件的伸缩性(Scalability)?我们都知道设计良好的系统可以应对不断增加的系统访问量,但是我们如何能在系统用户增多的时候,来提高系统的吞吐量呢?这就是伸缩性之魅力所在。

伸缩性可以有两个方面,垂直伸缩性和水平伸缩性,垂直伸缩性是通过在同一个业务单元中增加资源来提高系统的吞吐量,比如增加服务器cpu的数量,增加服务器的内存等。水平伸缩性是通过增加多个业务单元资源,使得所有的业务单元逻辑上就像是一个单元一样。比如ejb分布式组件模型,集群配置等都属于此种方式。

下面我说一下,我对性能的理解,我们在日常的开发当中,当说到性能的时候,一般都会首先想到系统有多“快”,我想说的就是性能还涉及到另一个方面,那就是系统有“多少”,也就是说系统的吞吐量。我们在考虑性能的时候,一般都会考虑到这两方面。

理解了伸缩性和性能这两个概念以后,我们来看看系统为什么需要分层架构。

首先采用分层架构的好处,我想大家肯定都会普遍接受的是,系统分层有利于系统的维护,系统的扩展。这其实就是系统的可维护性和可扩展性。

其次,我围绕伸缩性以及性能来说一下,为什么需要分层架构。比如在目前的J2EE系统开发当中,我们普遍采用了分层构架的方式,一般分为表现层,业务层和持久层,当然了我们还可以对各层进行进一步的划分,但是层次划分也不能太细,具体项目要具体对待,原因下面讨论。我们想想,采用分层以后会带来什么不好的地方?想这个问题,我们可以先反过来想一下,不采用分层有什么好处,这当然是每个业务处理速度会更快,因为层与层之间通信会引来额外的开销,所以采用分层后,给我们软件系统带来的就是每个业务处理开销会变大。

转自:http://www.jdon.com/36525

好了,既然采用分层会带来额外的开销,那么我们为什么还要进行分层呢?这就涉及到了伸缩性和性能的问题。

如果不采用分层的话,系统的扩展和伸缩也主要靠垂直伸缩,但是垂直伸缩是有限度的,随着系统规模的扩大,垂直伸缩带来的代价也将变得非常昂贵。当采用了分层以后,虽然带来了层与层之间的通信开销(这得益于计算机硬件的飞快发展,如果计算机硬件的发展水平不足以抵消分层以后带来的额外的开销,那么分层架构也会有一个巨大的问号,所以从某种程度上来说,分层架构也利用了一点垂直伸缩性),但是它有利于层的水平伸缩性,并且各个层都可以进行独立的伸缩而不会影响到其它的层,比如EJB分布式组件模型以及目前采用的分成架构的方式就有利于水平伸缩性

对于性能方面,我上面也说了,性能存在两个方面,一是“快”,二是“多少”,采用分层架构,当然会影响到性能快的方面,因为层次之间通信会带来额外的开销,但是采用了分层架构后,我们的软件系统可以更容易变大(“多少”的问题),也就是说当系统要应对更大的访问量的时候,我们可以通过增加多个业务单元资源(此时的多个业务单元逻辑上看起来就像一个逻辑单元,这对外界是透明的)来增加系统吞吐量。所以对于那些实时性比较高的系统,层的划分不应该太细,太细必然带来实时性的减低,而对于实时性不高,而需要高度的伸缩性的系统,我们可以通过引入不同的层来达到系统水平伸缩的目的。

以上是有关伸缩性和性能,以及它们与分层架构之间的联系,下面我再说一下另外一个问题,这就是Amdahl law(阿姆达尔定律),这个定理主要说明了系统中串行部分对系统速度提升的影响,假设程序中串行部分占a%的比例,那么程序最多提升1/a%的速度。我从这个定律也看出了,软件垂直伸缩的局限性,因为无论增加多少个cpu,如果程序中有串行化的部分,那么程序的速度的提升是有一个极限的,是不能靠增加硬件来无限度的增强系统性能的。所以对于我们软件工程师来说,我们更加需要关注系统的水平伸缩性

系统为什么需要分层?

时间: 2024-11-02 11:56:25

系统为什么需要分层?的相关文章

标准Web系统的架构分层

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

标准Web系统的架构分层[转]

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

(系统架构)标准Web系统的架构分层

标准Web系统的架构分层 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的通信(这在下面的内容

系统思维--系统的思维分层抽象

系统的思维分层抽象 目的层(功能层,整体描述) 交互层(输入输出的描述,对目的层的进一步描述) 思维层(在逻辑层面对目的.问题进行分析综合) 架构层(组织.控制层) 实现层(组件层.析构层): 从上到下由思维到实现的过程. 由整体描述到具体实现的思维与实践过程. 原文地址:https://www.cnblogs.com/feng9exe/p/12109148.html

分析系统

系统分模块分层面的时机: 1)完成一次从功能需求,ui设计,代码设计,数据库设计的整体梳理或是迭代思考.这时结合经验判断哪些地方可能有较大的代码量,或是构造复杂度,则预先横向分块,纵向分层. 2)代码积累到一定程度,以当前能力,解决问题的速度越来越慢,碰上的问题的水准越来越低,数量越来越多,必须要析置出子系统. 3)信息流的某个下游模块,比如ui设计已经很复杂很完善,目标需求很明确的时候,可以在上游设计复杂和有针对性的功能和数据结构,为数据流的转承提供方便的子系统.

企业应用架构之分层 - 总结

原网址将会不断更新 :   作程的技术博客  <企业应用架构之分层 - 总结> it.zuocheng.net 常见分层架构模式 三层架构 3-tier architecture 微软.net 体系推荐的分层结构,因此早期在ASP编码的系统中被广泛应用,同时也被其他语言广泛借鉴. 表现层, Presentation layer(PL) 主要负责数据的输入接口和输出.输入指在WEB.客户端或为外界提供的API的数据请求接口:输出则是Web界面.客户端输出.API的数据输出. 页面模版. 对外AP

系统架构师-基础到企业应用架构-服务层

一.上章回顾 上篇我们主要讲解了系统架构中的四种架构模式,并且分析了四种架构模式的实现及应用场景,那么先来回顾下架构中的业务逻辑层的使用及总结.  如果大家对图中讲述的内容不明白或者说是不深入那么可以参考上篇讲 解的内容:系统架构师-基础到企业应用架构-业务逻辑层. 二.摘要 本文将已架构的方式去分析分层结构中的服务层的设计,如何设计出来满足我们说的业务需求及设计规范的服务层将是我们的目标,可能我想大家在项目架构的 过程中可能有些同仁,没有用到该层,或者说是采用的是常用的分层结构的设计,而没有把

系统架构师-基础到企业应用架构-企业应用架构

一.上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层.数据访问层.服务层.表现层,我们了解了这些分层的职责和分层之间的大概的关联 关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建.我们还是先对我们学习的四个分层的职责和功能做个大 概的回顾,我们先来看看下图来回顾下我们讲述的内容. 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应

学习笔记之TCP/IP协议分层与OSI參考模型

1.协议的分层      ISO在制定标准化OSI之前,对网络体系结构相关的问题进行了充分的讨论, 终于提出了作为通信协议设计指标的OSI參考模型.这一模型将通信协议中必要 的功能分成了7层.通过这些分层,使得那些比較复杂的网络协议更加简单化. 在这一模型中,每一个分层都接收由它下一层所提供的特定服务,而且负责为自己的上一层提供特定的服务.上下层之间进行交互时所遵循的约定叫做"接口".同一层之间的交互所遵循的约定叫做"协议". 协议分层就如同计算机软件中的模块化开发