项目需求
市面上主流架构设计
2. 单体架构
- 特点：所有的功能都打包在一个单一的应用程序中，通常部署在同一个进程中。
- 适用场景：适合小型项目或初期开发阶段，因为它简化了开发和部署流程。
1. 微服务架构
- 特点：将应用程序分解为一系列小的服务，每个服务运行在其独立的进程中，并通过明确定义的API通信。服务是围绕业务能力构建的，可以独立部署、扩展和更新。
- 适用场景：适用于大型企业级应用，特别是那些需要快速迭代和大规模扩展的应用。
技术选型理由
-
市面上架构，主流都是微服务设计。
-
开发起来，微服务可以向下兼容单体服务。微服务只是一种设计思想，模块化设计，每个模块都看作单体服务就好了，想怎么设计就设计。
基本中间件选择：
- nacos：主要是动态更新配置而无需重启应用。主要是运营的时候考虑，降低成本使用。
- mybatisplus：快速curd的.
- redis:非关系型数据库，主要是注册用户的时候，把验证码存储到内存中，订单量大时候调优用的（1个月时间还是紧的）。
- Mysql：关系型数据库，存储数据用的。
扩展中间件
1.如果订单量过大，可以考虑消息队列。 2.搜索表，可以考虑用搜索引擎。
技术
- spring Security安全框架，用于认证，授权的框架。基于RABC的资源授权，白名单，黑名单配置。
- Feign :远程调用，熔断降级。
- gateway:网关，用于负载均衡，统一入口。 这样技术需求就可以基本满足。
粗略设计
- 认证中心，用户服务，为一个独立模块，认证授权模块。
- 商品服务，购物车服务。为一个独立模块。
- 订单服务，结算服务，支付。为一个模块。
- 基础模块：工具类，常用的类为一个模块
- 网关模块：统一认证入口，jwt令牌校验
为什么:功能拆分不是随便拆分的，尽量让每个相似功能模块合并一起。实现相对独立。
如果都盲目拆分一个个模块，各个模块藕断丝连，远程调用乱飞。
性能下降，造大孽了，部署困难，成本也上去了。
小编倒是设计的时略有不同，商品服务和购物车服务拆分了出来。
