前言:如今spring微服务以其灵活开发易于维护已基本占领开发占地,项目从一开始并不是这种服务的拆分,是一步步演变成现在的架构;
项目演化之路:
1 单体架构:开发和运维都较简单:
- 单体架构,一个tomcat作为项目的容器,一个sql作为数据存储,一个文件服务器,所有的代码都在一个包里,
运维维护成本很低; - 随着用户量的增加,单体架构出现响应慢,已经不满足现实业务,需要部署多个服务以满足用户量:
2 项目集群:通过堆叠服务器部署多个应用提高访问并发量
- 将项目部署到多个Tomcat容器中,通过Nginx做负载均衡将请求进行分配,通过多个服务来满足用户访问量的需求;
- 从最开始我们只有一个mysql 作为数据存储,并且提供数据查询;随着数据量的增加,我们发现即使加了索引和硬件支持,mysql因为数据量的问题效率依然很低;针对于此可以对mysql 进行读写分离,将mysql 拆为两个实例,一个实例对外提供增删改,另外一个实例对外提供查询,两个实例进行数据的同步;在业务层面定义路由规则进行读和写不同数据库的访问;
- 通过部署多个文件服务器来较少单台服务的压力;
随着业务的增多,所有的代码业务全都放在一个项目中,每次修改就需要进行更新,这样耦合程度太高,所以需要按照业务进行服务的拆分,将一个项目模块,拆分成不同的服务 以达到业务的解耦。
3 微服务架构:业务进一步细化,运维难度也增加:
- 按照业务进行服务的拆分,以达到各个服务的解耦;
- 通过网关服务统一进行用户鉴权,日志记录,限流等服务;
- 各个服务之间通过feign\dubbo 等中间件完成通信;
- 通过中间件完服务发现和配置;
- 通过xxljob 完成 任务的调度,通过kafka,mq等完成消息的投递和消费;
- 通过mysql ,Es ,redis等进行数据的存储;
4 msyql的拆分:
后续随着数据量增加,即使使用了mysql 的读写分离依然无法满足,针对于此就需要进行mysql的拆分:
- 垂直拆分:按业务组成不同的数据库实例如,订单数据库,库存数据库,用户数据库;
- 水平拆分:将表按照某个方面将表进行拆分,如按照日期没有查分;
在拆分的同时,可以将热点数据进行优先缓存,以较少数据库的io操作;同样可以使用es ,mongdb 存储非关系型数据,在对mysql 进行数据的修改和增加时,可以通过消息中间件的形式,发送信息,进行对es数据的处理;