单体应用
10多年前:用户访问一个电商系统(所有功能包含在一个project里)>访问数据库
问题：商品或者订单存在瓶颈时不能扩展。以前上网用户不多，负载不高，数据量几万几十万，用一个mysql即可
分布式架构
五六年前(当前也有公司在用)：也是单体应用，只是采用集群式的分布式应用
用户>负载均衡器(nginx)>好多个电商节点，部署多个(如果用户增多则部署多个)>数据库分主从>也会引入缓存集群
像这种架构就可以支持几百万数据量
缺点：开发速度慢、启动时间长、依赖庞大等等
微服务方式
举电商系统，搜索、支付、商品展示等模块，将每一个模块抽取出来project进行集群部署。可以针对某一个模块进行扩展
负载均衡使用LVS+keepalive分布实现高可用
网关：进行拦截，比如去旅游，进行检查，签证，之后进行分发检票口。更具用户url分发不同的服务
还有比如用户访问订单服务，检查是否登陆了，如果没有登陆就返回
多数据库：按照维度单独放在一个库里，减少压力。也可分主从数据库。还可将部分数据放在NoSQL当中
优点：易开发、理解和维护。独立的部署和启动
不足：分布式系统》分布式事务问题：需要管理多个服务》服务治理
不足：分布式系统》分布式事务问题：需要管理多个服务》服务治理
举例：原有单体服务下订单失败直接进行回滚，但带微服务当中不是在一起的，如果某个服务挂掉，整个功能就挂掉了。