三层架构的优缺点

优缺点"/>

三层架构的优缺点

三层架构

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

从历史角度考虑优缺点

单一应用结构

优势

    - 结构简单- 性能高

劣势

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

面临什么问题？

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

改进

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

垂直应用架构（三层架构）

优势

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

缺点

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

改进

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

案例：Spring

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

分布式服务架构

优势

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

劣势

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

面临的问题

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

改进

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