架构模型

单体架构

三级架构:前端(Web/手机端)+中间业务逻辑层+数据库层
Java Spring mvc或者Python Drango框架的应用

优点: 比较容易部署、测试
缺点

• 复杂性高 (模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌)
• 可靠性差 (某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃)
• 扩展能力受限 (无法根据业务模块的需要进行伸缩 CPU密集 IO密集)
• 阻碍技术创新 (必须使用相同的开发语言和框架)

分布式应用

中级架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互

特点

• 降低了耦合度：把模块拆分,使用接口通信,降低模块之间的耦合度。

• 责任清晰：把项目拆分成若干个子项目,不同的团队负责不同的子项目。

• 扩展方便：增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

• 部署方便:可以灵活的进行分布式部署。

缺点: 系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊

SOA架构

面向服务的架构

• 基础设施
  核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑

• 企业服务总线
  提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式

• 关键服务组件
  各种业务服务组件的分类

• 开发工具和管理工具
  提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期

微服务架构

微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用

代表框架有Spring cloud、Dubbo等

组成

• 服务注册与发现
  服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址

• 负载均衡
  服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的

• 服务网关
  服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能

• 配置中心
  将本地化的配置信息（Properties、XML、YAML等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移

• 集成框架
  微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统

• 调用链监控
  记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点

• 支撑平台
  系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效

特点

• 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少

• 单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快

• 局部修改容易部署: 对某个微服务进行修改，只需要重新部署这个服务即可

• 技术栈不受限: 微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈

• 运维要求较高: 更多的服务意味着更多的运维投入

• 分布式固有的复杂性：系统容错、网络延迟、分布式事务等都会带来巨大的挑战

• 接口调整成本高： 微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整

• 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复

Serverless架构

优点

• 低运营成本
• 简化设备运维
• 提升可维护性
• 更快的开发速度

缺点

• 厂商平台绑定
• 成功案例比较少，没有行业标准