高并发体系设计之架构分层

打印 上一主题 下一主题

主题 924|帖子 924|积分 2772

什么是分层架构



  • 软件架构分层在软件工程中是一种常见的设计方式,它是将整体体系拆分成 N 个层次,每个层次有独立的职责,多个层次协同提供完整的功能。
  • “MVC”(Model-View-Controller)架构。它将整体的体系分成了 Model(模型),View(视图)和 Controller(控制器)三个层次,也就是将用户视图和业务处置惩罚隔离开,并且通过控制器连接起来,很好地实现了表现和逻辑的解耦,是一种标准的软件分层架构。

  • 别的一种常见的分层方式是将整体架构分为表现层、逻辑层和数据访问层:

    • 表现层,顾名思义嘛,就是展示数据效果和接受用户指令的,是最靠近用户的一层;
    • 逻辑层内里有复杂业务的详细实现;
    • 数据访问层则是主要处置惩罚和存储之间的交互。

  • 这是在架构上最简单的一种分层方式。其实,我们在不经意间已经按照三层架构来做体系分层设计了,比如在构建项目的时间,我们通常会建立三个目次:Web、Service 和 Dao,它们分别对应了表现层、逻辑层还有数据访问层。

  • Linux 文件体系也是分层设计的,可以清晰地看出文件体系的层次。在文件体系的最上层是捏造文件体系(VFS),用来屏蔽不同的文件体系之间的差异,提供同一的体系调用接口。捏造文件体系的下层是 Ext3、Ext4 等各种文件体系,再向下是为了屏蔽不同硬件装备的实现细节,我们抽象出来的单独的一层——通用块装备层,然后就是不同类型的磁盘了。可以看到,某些层次负责的是对下层不同实现的抽象,从而对上层屏蔽实现细节。比方说 VFS 对上层(体系调用层)来说提供了同一的调用接口,同时对下层中不同的文件体系规约了实现模型,当新增一种文件体系实现的时间,只需要按照这种模型来设计,就可以无缝插入到 Linux 文件体系中。

分层有什么好处



  • 分层的设计可以简化体系设计,让不同的人专注做某一层次的事变。
  • 想象一下,假如你要设计一款网络步调却没有分层,该是一件多么痛苦的事变。

    • 因为你必须是一个通晓网络的全才,要知道各种网络装备的接口是什么样的,以便可以将数据包发送给它。你还要关注数据传输的细节,并且需要处置惩罚类似网络拥塞,数据超时重传这样的复杂问题。固然了,你更需要关注数据如安在网络上安全传输,不会被别人窥探和篡改。
    • 而有了分层的设计,你只需要专注设计应用层的步调就可以了,其他的,都可以交给下面几层来完成。
    • 再有,分层之后可以做到很高的复用。比如,我们在设计体系 A 的时间,发现某一层具有一定的通用性,那么我们可以把它抽取独立出来,在设计体系 B 的时间使用起来,这样可以减少研发周期,提升研发的效率。
    • 最后一点,分层架构可以让我们更容易做横向扩展。假如体系没有分层,当流量增长时我们需要针对整体体系来做扩展。但是,假如我们按照上面提到的三层架构将体系分层后,那么我们就可以针对详细的问题来做过细的扩展。

如何来做体系分层



  • 最主要的一点就是你需要理清晰每个层次的边界是什么。你大概会问:“假如按照三层架构来分层的话,每一层的边界不是很容易就界定吗?”没错,当业务逻辑简单时,层次之间的边界简直清晰,开发新的功能时也知道哪些代码要往哪儿写。但是当业务逻辑变得越来越复杂时,边界就会变得越来越模糊。我们可以将原先的三层架构细化成下面的样子:

  • 分层架构中的每一层的作用:

    • 终端显示层:各端模板渲染并实验显示的层。当前主要是 Velocity 渲染,JS 渲染, JSP 渲染,移动端展示等。
    • 开放接口层:将 Service 层方法封装成开放接口,同时举行网关安全控制和流量控制等。
    • Web 层:主要是对访问控制举行转发,各类基本参数校验,或者不复用的业务简单处置惩罚等。
    • Service 层:业务逻辑层。
    • Manager 层:通用业务处置惩罚层。这一层主要有两个作用,其一,你可以将原先 Service 层的一些通用本领下沉到这一层,比如与缓存和存储交互策略,中心件的接入;其二,你也可以在这一层封装对第三方接口的调用,比如调用支付服务,调用审核服务等。
    • DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase 等举行数据交互。
    • 外部接口或第三方平台:包罗其它部分 RPC 开放接口,基础平台,其它公司的 HTTP 接口。

  • 在这个分层架构中主要增长了 Manager 层,它与 Service 层的关系是:Manager 层提供原子的服务接口,Service 层负责依据业务逻辑来编排原子接口。
分层架构的不足



  • 任何事物都不可能是尽善尽美的,分层架构虽有上风也会有缺陷,它最主要的一个缺陷就是增长了代码的复杂度。
  • 这是显而易见的嘛,明显可以在接收到请求后就可以直接查询数据库获得效果,却偏偏要在中心插入多个层次,并且有可能每个层次只是简单地做数据的传递。有时增长一个小小的需求也需要更改全部层次上的代码,看起来增长了开发的本钱,并且从调试上来看也增长了复杂度,本来假如直接访问数据库我只需要调试一个方法,现在我却要调试多个层次的多个方法。
  • 别的一个可能的缺陷是,假如我们把每个层次独立摆设,层次间通过网络来交互,那么多层的架构在性能上会有损耗。这也是为什么服务化架构性能要比单体架构略差的原因,也就是所谓的“多一跳”问题。
  • 那我们是否要选择分层的架构呢?答案固然是肯定的。你要知道,任何的方案架构都是有上风有缺陷的,天地尚且不全何况我们的架构呢?分层架构固然会增长体系复杂度,也可能会有性能的损耗,但是相比于它能带给我们的好处来说,这些都是可以接受的,或者可以通过其它的方案解决的。我们在做决议的时间切不可以偏概全,因噎废食。
你知道的越多,你不知道的越多。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

汕尾海湾

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表