系统架构的演变

1.集中式架构
这种架构将所有的项目功能容纳到一个工程里面去（也就是说从头到尾只有一个工程）。

存在优点：项目好做。
当网站流量很小时，只需一个应用将所有功能都部署在一起，以减少部署节点和成本。
存在缺点:代码耦合度高。
（举个例子：功能复杂的网站，比如京东这类电商网，一般团队人数上百人，当大家将自己的代码都往一个项目上传时，必定会出现大量冲突） 将来开发和维护都会很复杂。
很难对项目的某个功能做优化
单点容错率低（一台机子挂了，全都会出问题）

但是以前传统项目一般会采用集中式架构。因为传统式项目 项目功能相对单一，用户量小，并且开发人员一般只有十几人。但是在互联网电商之类行业，用户并发量大，这种架构就不能再适用，随之演变出来的架构就是接下来要讨论的垂直拆分架构

2.垂直拆分架构
根据业务功能对系统进行拆分
将项目的各功能拆分开来，各团队独立开发，独立发布（解决了代码耦合问题）
系统拆分实现了流量分担，解决了并发问题

这种架构也存在问题，代码出现了重复（当各功能都要调用相同的服务时）

3.分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务服用及整合的分布式调用是关键。
（首先相互独立，其次又相互依赖。）

存在缺点：
服务之间调用错综复杂
当服务越来越多时，容量的评估，小服务的浪费等问题逐渐显现。

4.流动计算架构
为解决分布式服务出现的问题，在项目中增加一个调度中心基于访问压力实时管理集群容量，提高集群的利用率。此时用于提高机器利用率的资源调度和治理中心soa是关键
soa 面向服务架构（多了一个服务的注册中心)

什么叫服务的注册中心（可以比喻为，租房时的中介机构）
服务拥有方相当于房东
服务调用方相当于租房者