三层架构

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

从历史角度考虑优缺点

单一应用结构

优势

    - 结构简单
    - 性能高

劣势

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

面临什么问题？

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

改进

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

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

优势

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

缺点

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

改进

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

案例：Spring

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

分布式服务架构

优势

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

劣势

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

面临的问题

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

改进

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