SpringCloud（1）——背景

一、架构演变

1、传统项目

       在传统项目中，我们的项目通常打成一个war，部署在tomcat中，所有的功能点都在这个war包中，为请求方提供服务。也就是 浏览器——>系统——>数据库这种模式。优点在于架构简单，部署起来方便，但是同样存在缺点：代码维护困难，当需要修改某个功能点时，可能会影响到全局。并且并发量有限。

2、升级1.0

当并发量变大时，单个tomcat就撑不住了，最简单方式就是加服务器，在每台服务器上都部署一套系统，通过nginx进行负载均衡。如下：

这种架构优点在于提高并发量 ，但是同样存在缺点：

1、代码维护困难

2、资源浪费，该项目中可能只有少数功能点经常被访问，其他功能点无需负载均衡，但是每台服务器上都部署了整个项目，造成资源的浪费

3、升级2.0

对功能点进行拆分

通过对功能点的拆分，我们可以根据每个功能点的使用量部署多台服务器，减少资源浪费。另外每个功能点都拆分为单独的工程，代码修改不会影响到其他功能点，便于维护。但是同样存在缺点：

当需要新增机器部署一个功能点时，需要修改nginx配置文件，当扩容频繁时，维护量就变得巨大

4、升级3.0——SOA框架

基于注册中心的SOA框架，一般分为三种角色：注册中心、服务提供者、服务调用者

首先启动注册中心，这里选择eureka

再启动服务提供者（功能点B）时，会自动向注册中心进行注册（ip，端口，服务名称等），该过程称之为服务注册

当服务调用者（功能点A）启动时，会自动从注册中心拉取服务列表，该过程称之为服务发现

当功能点A需要请求功能点B时，会根据服务列表，负载均衡访问功能点B