1. 系统架构演变
随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
1.1 单体应用架构
Web 应用早期，很多项目都时以单体项目存在，然后项目中分为 Controller、Service、Dao 层，将所有的功能模块都开发在一个项目中，进行打包和部署，当服务能力不够时，采用横向拓展的方式解决。
缺点：
- 耦合性高，所有模块放在通一个项目中，使得各个模块的耦合性很高
- 灵活性差，在某个模块需要横向拓展的时候，需要整个项目一起部署
- 不易维护，部分模块代码发生修改，需要所有模块一起重新上线，另外整个项目的代码量较大，较为庞大
1.2 垂直应用架构
当访问量逐渐增大，单一应用横向拓展增加机器带来的加速收益越来越小，随之应运而生的是将应用拆成互不相干的几个应用，以提升效率。
缺点：
- 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
- 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
2. 分布式 SOA 架构
2.1 什么是 SOA
SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合。
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
2.2 优点
- 抽取公共的功能为服务,提高开发效率；
- 对不同的服务进行集群化部署解决系统压力；
- 基于 ESB/DUBBO 减少系统耦合。
2.3 缺点
- 抽取服务的粒度较大；
- 服务提供方与调用方接口耦合度较高（感觉这个是最主要的缺点）。
3. 微服务架构
微服务架构和分布式 SOA 架构有一点类似，但是区别也很明显，SOA 是面向服务的架构，从顶层的应用到底层的数据库设计都是基于应用来设计，但是微服务是将服务原子化，独立拆分成各个独立的系统。
3.1 优点
- 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降；
- 微服务遵循单一原则。微服务之间采用 Restful 等轻量协议传输。
3.2 缺点
- 微服务过多，服务治理成本高，不利于系统维护；
- 分布式系统开发的技术成本高（容错、分布式事务等）。
随着 Spring Cloud 全家桶不断深入引入，微服务这些缺点都得到了解决。
4. 分布式 SOA 架构和微服务架构对比
SOA（面向服务的架构）:他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。
微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。
| 功能 | 分布式 SOA 架构 | 微服务架构 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
