Spring架构篇--1 项目演化过程

前言：如今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数据的处理；