系统架构演变概述
1、集中式架构
当系统流量小的时候，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本
| 优点 | 缺点 |
|---|---|
| 系统开发速度快 | 代码耦合度高，后期维护困难 |
| 维护成本低 | 无法针对不同模块进行针对性优化 |
| 适用于并发要求较低的系统 | 无法水平扩展 |
| 单点容错率低，并发能力差 |
2、垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，根本业务需求对系统进行拆分
| 优点 | 缺点 |
|---|---|
| 流量分担，解决了并发问题 | 系统相互独立，有很多重复开发工作，影响开发效率 |
| 可以针对不同模块进行针对性优化 | |
| 方便水平扩展，负载均衡，容错率提高 |
3、分布式服务
当垂直应用越来越多，应用之间的交互不可避免；将核心业务抽取出来，作为独立的服务；逐渐形成稳定的服务中心，使前端应用能够更快速的响应多变的市场需求
| 优点 | 缺点 |
|---|---|
| 提高代码复用率和开发效率 | 系统之间的耦合度高，调用关系错综复杂，难以维护 |
4、面向服务架构（SOA架构）
SOA（Service Oriented Architecture）面向服务架构：一种设计方法，包含多个服务；服务之间通过相互依赖，最终提供一系列功能。一个服务以独立的形式存在于操作系统进程中。各个服务之间通过网络调用
ESB（企业服务总线）：就是一根管道，连接着各个服务点。为了集成不同系统，不同协议的服务，ESB会进行消息转化解释和路由工作，让不同的服务互联互通
| 优点 | 缺点 |
|---|---|
| 降低系统之间耦合度，简化调用关系 | 每个供应商提供的ESB有偏差，自身实现较为复杂 |
| ESB服务粒度较大，集成整合所有服务和协议 | |
| 数据转换使得运维、测试部署困难 | |
| 所有服务都通过一个通路通信，直接降低了通信速度 |
5、微服务架构
使用一套小服务来开发单个应用的方式或途径，每个服务都基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。这些服务可以使用不用的编程语言实现，可以使用不同的数据存储技术，可以保持最低限度的集中式管理
微服务的特点：
单一职责：每个服务都只专注于自己的单一业务
微小服务：服务的粒度很小；服务虽小，却五脏俱全
面向服务：每个服务都对外暴露Rest风格的服务接口API。做到与平台和语言无关；并不关心、不限定服务的技术实现，只要提供Rest接口即可
高度自治：服务之间相互独立，互不干扰
团队独立：每个服务都有一个独立的开发团队
技术独立：不关心、不限定服务的技术实现
前后端分离：采用前后端分离，提供统一的Rest接口
数据库分离：每个服务都使用自己的数据源
部署独立：服务之间虽然有互相调用，但可以做到服务启动时不影响其他服务。有利于持续集成和持续交付
独立组件：每个服务都是独立的组件，可服用、可替换、降低耦合、易维护
微服务架构与SOA架构的对比：
| 功能 | SOA架构 | 微服务架构 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 易维护、易扩展、更轻量级的交互 |