项目架构演进

​

 单体架构：

用户量也不多，项目也不稳定

​编辑

优点：

• 单体架构简单，小型项目开发成本低。
• 项目部署在一个节点上，维护也比较方便。

缺点：

• 全部功能集成在一个工程中，对大型项目来说不易于开发和维护。
• 项目模块之间紧密耦合，单点容错率低。
• 无法针对不同模块进行针对性优化和扩展。

搭建集群：

提升项目稳定性，并发承受度提高，某一台服务器挂了，也没什么问题。

但是搭建集群后会出现的一些新的问题，例如（包括但不仅仅是这三种）：

• 用户的请求如何分发给不同的服务器，从而缓解用户量增加的压力。
• 用户登录成功后，数据共享问题。
• 当数据量庞大时，如果还直接去数据库查询，速度很慢，如何提升查询效率

​编辑

可以通过Nginx【解决请求分配问题】、Redis【解决数据共享和缓存问题】、Elasticsearch【解决数据查询问题】等技术，解决上述问题。

​编辑

垂直架构：

所谓的垂直架构就是将原来的一个应用拆成互不相关的几个应用，以提升效率。

比如我们把一个系统拆分为用户模块、订单模块、商品模块，一旦订单模块访问量过大，只需增加订单模块节点即可。

​编辑

分布式架构：

项目一般分为controller、service、dao三层，实际上导致程序变慢的重灾区可能在service或者dao层，而搭建集群时是针对三层都搭建了集群，效果不是很好，所以开始演进到分布式架构。

​编辑

分布式架构问题：

问题1：使用分布式架构之后，服务器直接的通讯都是同步的，在一些不是核心业务的功能上肯定希望它是异步通讯，为了实现服务器之间的异步通讯就出现了MQ【RabbitMQ、RocketMQ等】

​编辑

问题2：由于模块繁多，并且模块搭建集群的数量增加，会导致其他模块需要维护各种ip地址等信息，导致项目的维护性极低，耦合性极高，并且也无法实现负载均衡的效果

也就出现可以帮助我们管理服务信息的技术【Nacos或者Eureka】，【ribbon】可以帮助我们实现服务的负载均衡

​编辑

问题3：如果订单模块出现问题，只要涉及到该模块的内容都无法使用，可能会导致服务提供的线程池耗尽，也无法给用户友好提示

于是有【Sentinel 】技术来解决

​编辑

问题4：海量数据会导致数据库无法存储全部内容或者在查询数据时响应极其缓慢，在用户高并发情况下，数据库也是无法承受住的。

于是可以基于【mycat】实现数据库的分库分表

​编辑

微服务架构

微服务架构是在分布式架构的基础上再次拆分，使每个服务只做一件事。

​编辑

问题：模块过多导致运维成本增加

解决：采用【docker】容器化技术帮助我们管理

​