单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

优点

• 小项目开发快，成本低（为什么开发快？）
• 架构简单
• 易于测试

• 易于部署

  缺点

• 大项目耦合严重，不易开发，维护(为什么不易开发？)

• 新增业务困难（为什么？困难在哪？）
• 核心业务与边缘业务混合在一块，出现问题容易互相影响

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

优点

• 实现了流量分担，解决了并发问题
• 可以针对不同系统进行优化
• 方便水平扩展，负载均衡，容错率高

• 系统之间相互独立，互不影响，新的业务迭代时更加高效

  缺点

• 服务系统之间接口调用硬编码

• 搭建服务集群后，实现负载均衡比较复杂
• 服务系统接口调用监控不到位，调用方式不统一

• 数据库资源浪费，充斥慢查询，主从同步延迟大（？）

  面向服务架构（SOA）

  SOA全称Service Oriented Architecture，即面向服务的架构。 它是在垂直划分的基础上,将每个项目 拆分出多个具备松耦合的服务,一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网 络调用，这使得构建在各种各样的系统中的服务可以 以一种统一和通用的方式进行交互。
  

  优点

• 服务以接口为粒度，为开发者屏蔽远程调用底层细节

• 业务分层后架构更加清晰，并且每个业务模块职责单一，扩展性更强
• 数据隔离，权限回收，数据访问都通过接口，让系统更加稳定、安全

• 服务责任易确定，每个服务可以确定责任人，这样梗荣以保证服务质量和稳定

  缺点

• 粒度控制复杂，如果没有控制好服务的粒度，服务的模块会越来越多，就会引发超时、分布式事务等问题

• 服务接口数量不宜控制 容易引发接口爆炸 所以服务接口建议以业务场景进行单位划分 并对 相近的业务做抽象防止接口爆炸
• 版本升级兼容困难 尽量不要删除方法 字段 枚举类型的新增字段也可能不兼容
• 调用链路长 服务质量不可监控 调用链路变长 下游抖动可能会影响到上游业务 最终形成连 锁反应 服务质量不稳定 同时链路的变成使得服务质量的监控变得困难

  微服务架构

  微服务架构是一种将单个应用程序 作为一套小型服务开发的方法，每种应用程序都在其自己的进程中独 立运行，并使用轻量级机制(通常是HTTP资源的API)进行通信。这些服务是围绕业务功能构建的，可以 通过全自动部署机制进行独立部署。这些服务的集中化管理非常少，它们可以用不同的编程语言编写， 并使用不同的数据存储技术。
  微服务是在SOA上做的升华 , 粒度更加细致，微服务架构强调的一个重点是“业务需要彻底的组件化和服 务化”。