传统架构演进到分布式架构以及数据请求流向讲解

单体应用

10多年前:用户访问一个电商系统(所有功能包含在一个project里)>访问数据库
问题&＃xff1a;商品或者订单存在瓶颈时不能扩展。以前上网用户不多&＃xff0c;负载不高&＃xff0c;数据量几万几十万&＃xff0c;用一个mysql即可

分布式架构

五六年前(当前也有公司在用)&＃xff1a;也是单体应用&＃xff0c;只是采用集群式的分布式应用
用户>负载均衡器(nginx)>好多个电商节点&＃xff0c;部署多个(如果用户增多则部署多个)>数据库分主从>也会引入缓存集群

像这种架构就可以支持几百万数据量

缺点&＃xff1a;开发速度慢、启动时间长、依赖庞大等等

微服务方式

举电商系统&＃xff0c;搜索、支付、商品展示等模块&＃xff0c;将每一个模块抽取出来project进行集群部署。可以针对某一个模块进行扩展

负载均衡使用LVS&＃43;keepalive分布实现高可用

网关&＃xff1a;进行拦截&＃xff0c;比如去旅游&＃xff0c;进行检查&＃xff0c;签证&＃xff0c;之后进行分发检票口。更具用户url分发不同的服务
还有比如用户访问订单服务&＃xff0c;检查是否登陆了&＃xff0c;如果没有登陆就返回

多数据库&＃xff1a;按照维度单独放在一个库里&＃xff0c;减少压力。也可分主从数据库。还可将部分数据放在NoSQL当中

优点&＃xff1a;易开发、理解和维护。独立的部署和启动

不足&＃xff1a;分布式系统》分布式事务问题&＃xff1a;需要管理多个服务》服务治理

不足&＃xff1a;分布式系统》分布式事务问题&＃xff1a;需要管理多个服务》服务治理
举例&＃xff1a;原有单体服务下订单失败直接进行回滚&＃xff0c;但带微服务当中不是在一起的&＃xff0c;如果某个服务挂掉&＃xff0c;整个功能就挂掉了。

数据请求流向