1.1 架构的衍进
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
互联网产品常常面临庞大的用户量，日均数十亿 PV 的高并发， PB 级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。
互联网架构从简到繁的演进至今，大体上可分为这么几个阶段：单一应用架构 -> 垂直应用架构 -> 微服务架构。
1.1.1 单一应用架构
当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，用来减少部署节点和成本。这时，用于简化增删改查工作量的数据访问框架(ORM)是关键。我们更加关注的是简化开发工作。如图1-1：
特点：
- 所有的功能集中在一个工程中。
- 应用与数据库分开部署。
- 通过部署应用集群和数据库集群来提高系统的性能。
优点：
- 项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：
- 全部功能集中在一个工程中，代码耦合，对于大型项目不易扩展及维护。
- 提高系统性能只能通过扩展集群，成本高。
- 单点容错率低。
1.1.2 垂直应用架构
当访问量逐渐增大，功能逐渐复杂起来，单一应用架构就显得有些捉襟见肘，由于所有的功能都写在同一个工程中，整个工程会越来越庞大越来越臃肿，每次发布上线拆分代码版本和合并代码版本都将成为噩梦，同时，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。如图1-2：
特点：
- 将项目以单一应用架构的方式，将一个大应用拆分成为几个互不干扰的应用。
- 应用于应用之间互不相干，功能和数据都会存在冗余。
优点：
- 通过垂直拆分，防止单体项目无限扩大。
- 系统间相互独立。
缺点：
- 项目拆分之后，项目与项目之间存在数据冗余，耦合性较大。
- 提高系统性能只能通过扩展集群，成本高，并且存在瓶颈。
1.1.3 微服务架构
当垂直应用越来越多，应用与应用之间的交互不可避免，这时需要将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务，使前端应用能更快速的响应多变的市场需求。如图1-3：
特点：
- 系统服务层完全独立，并且抽取成一个一个的独立服务。
- 微服务遵循单一原则。
- 使用服务中心进行服务注册与发现。
- 每个服务有自己的独立数据源。
- 微服务之间采用 RESTful 等轻量协议传输。
优点：
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。
- 可以更加精准的制定每个服务的优化方案，提高系统可维护性。
- 微服务架构模式是每个微服务独立的部署，可以使每个服务独立扩展。
- 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量协议通信。
缺点：
- 微服务过多，服务治理成本高，对系统运维团队挑战大。
- 分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。
