三层架构的优缺点

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u010080215/article/details/74011367

三层架构

三层架构一般包含:控制层,业务逻辑层,数据访问层。

从历史角度考虑优缺点

单一应用结构

优势

    - 结构简单
    - 性能高

劣势

    - 业务杂糅。代码杂糅的不同的业务,要求开发人员能理解所有的细节,维护费时间。

面临什么问题?

    - 当处理的业务越来越多时?
        - 代码变得庞杂,需要重构。
        - 当需要有共同的业务处理的任务时,需要抽取公共类。
        - 如不重构,会出现很多重复的代码段。改动一个地方,很多地方相同的代码都需要改动,既提升了产生bug的风险,又让修改时间变长,对开发人员细心程度高。
    - 当代码中需要添加日志,事务,权限控制,数据监控,会增加诸多重复的、相似的代码块
    - 当参与的人员越来越多时,不同的风格代码结构会造成理解上的困难。

改进

    - 提取公共类
        - 抽取公共的模型类
        - 抽取帮助类或者utils类
    - 大类变小类
        - 大的业务处理的类,根据业务聚焦的不同,划分成几个业务处理类
    - 使用组合和继承(设计模式)的方式,让结构具有可扩展性,可复用性
        - 使用责任链模式,策略模式,访问者模式等模式让的业务处理类得到有效的利用

垂直应用架构(三层架构)

优势

    - 层次清晰,每个层次都提供了接口定义
        - 很容易用新的实现替换原来的层次实现。例如对sql进行性能优化,并不会影响其他层的代码结构。有利于后期维护。
        - 有利于实现切面编程,减轻业务的复杂程度,加快编码效率。
        - 每个层次的定位明晰,业务处理的内容明确。依据层次,可以划分不同的分工。开发人员可以只关注整个结构的其中某一层。
        - 接口定义也提供了良好的可扩展性。例如数据库从mysql切换到oracle,只需要通过配置来切换。
    - 降低了代码之间,层与层的依赖关系
    - 复用性:利于各层代码逻辑的复用
    - 安全性:接口设计需要符合对扩展开发,对修改关闭的原则,增强了系统的安全性

缺点

    - 降低了系统的性能。使用中间层访问数据库,对数据进行转换等等都需要计算时间。
    - 新增业务处理时,需要在各个层增加功能。
- 面临的问题
    - 不同的层次对接口规范理解的层次不一样,对接口维护,调用,监控都会产生影响
    - 当用户访问量增大时,性能会遇到瓶颈。
    - 单点服务问题
        - 部署会造成服务中断
        - 服务挂了之后,需要人工及时的处理,给用户和公司带来损失

改进

    - 明确良好的接口规范,团队内部统一接口规范
    - 使用缓存减轻服务的性能压力
    - 转向分布式架构:将服务改造成无状态的分布式服务,通过集群来增强计算能力。

案例:Spring

    - 优点:为开发者实现了中间层次的共同的逻辑,让开发者更多的关注业务实现,而不是代码结构,提升开发效率。

分布式服务架构

优势

    - 通过集群(负载均衡,分布式调度服务,分布式应用,分布式存储),MQ,noSql,流处理等技术来提升计算、存储的性能

劣势

    - 系统结构变得复杂
        - 新增一项业务,可能涉及到不同的分布式应用,造成调试成本的增加
        - 部署一套服务包含很多过程

面临的问题

    - CAP只能同时满足其中两个
    - 业务拆分、数据拆分的问题
    - 集群的节点越多,意味着更高的成本
    - 集群治理问题凸显
        - 状态如何在多个服务器上共享
        - 不同的服务器处理性能不一,造成某些服务器压力大,某些服务器压力小
    - 越来越大的数据量吞没更多的存储

改进

    - 使用持续集成技术,一键部署
    - 使用领域驱动设计划分不同的业务领域,为业务拆分、数据拆分奠定基础
    - 优化代码性能,减少计算服务器的数量;通过压缩技术,减少存储服务器的数据。
    - 使用dubbo,spring cloud的技术增加分布式服务治理功能
展开阅读全文

没有更多推荐了,返回首页