一、架构演变
1、传统项目
在传统项目中,我们的项目通常打成一个war,部署在tomcat中,所有的功能点都在这个war包中,为请求方提供服务。也就是 浏览器——>系统——>数据库这种模式。优点在于架构简单,部署起来方便,但是同样存在缺点:代码维护困难,当需要修改某个功能点时,可能会影响到全局。并且并发量有限。
2、升级1.0
当并发量变大时,单个tomcat就撑不住了,最简单方式就是加服务器,在每台服务器上都部署一套系统,通过nginx进行负载均衡。如下:
项目1 | |||
浏览器 | nginx | 项目2 | 数据库 |
项目3 |
这种架构优点在于提高并发量 ,但是同样存在缺点:
1、代码维护困难
2、资源浪费,该项目中可能只有少数功能点经常被访问,其他功能点无需负载均衡,但是每台服务器上都部署了整个项目,造成资源的浪费
3、升级2.0
对功能点进行拆分
功能点A | ||||||
功能点A | 功能点B | |||||
浏览器 | nginx | 功能点A | nginx | 功能点B | nginx | 功能点C |
功能点A | 功能点B | |||||
功能点A | ||||||
数据库 |
通过对功能点的拆分,我们可以根据每个功能点的使用量部署多台服务器,减少资源浪费。另外每个功能点都拆分为单独的工程,代码修改不会影响到其他功能点,便于维护。但是同样存在缺点:
当需要新增机器部署一个功能点时,需要修改nginx配置文件,当扩容频繁时,维护量就变得巨大
4、升级3.0——SOA框架
基于注册中心的SOA框架,一般分为三种角色:注册中心、服务提供者、服务调用者
首先启动注册中心,这里选择eureka
再启动服务提供者(功能点B)时,会自动向注册中心进行注册(ip,端口,服务名称等),该过程称之为服务注册
当服务调用者(功能点A)启动时,会自动从注册中心拉取服务列表,该过程称之为服务发现
当功能点A需要请求功能点B时,会根据服务列表,负载均衡访问功能点B
注册中心eureka | ||||
功能点A |