需求分析设计

本地缓存   直接直接使用 服务器的本地缓存   但是会出现跟应用抢内存的情况

业务拆分 需用对业务环境对业务进行拆分，做集群，
水平拆分，按照业务进行拆分，每个模块不部署集群
垂直拆分，公共的服务可以进行拆分，比如说短信服务 可以单独抽取出来，因为不止一个服务需要用到短信服务

公共服务可以拆分出来给多个模块使用，

单一的数据库是比较单一的，随着用户的增加   数据库就成为了瓶颈。

分库分表，专注于数据库来进行，分库分表，读写分离。 主库主要处理写的操作，从库查询操作       因为主要用到的查询功能是比较多的  读的操作就可以从多个数据库中进行操作了的，按照业务对数据库进行拆分，

分表，订单表。可以按照月份进行拆分，按照时间上进行拆分，数据多的时候就会遇到数据库的瓶颈，单个数据库出现问题的时候 只需要  修复一个数据库就可以了   缺点：维护的成本增加以及数据库的分库的策略的维护，

***静态化和CDN
cdn做了一层缓存   如果  请求中已经有了缓存，那就直接返回就好了  提高用户的体验，一般CDN的部署都是就近原则（地理位置）  一般采用购买的方式来进行    主要使用的是一些静态化的页面  一些静态的资源可以 很好的利用到CDN的资源 

***异步解耦  
部署专门的消息中间件，把直接调用变成间接调用不用进行同步的处理，增强主线业务的调用，异步解耦  

***微服务架构
专注于业务的拆分，实现业务组件化，通过组件的服务来快速构建系统  类似搭积木  主要体现在业务的拆分    服务的请求控制轮询  配置的集群管理  以及 服务的熔断降级   微服务拆分只有 会出现很多的其他的问题   可以使用各种的组件来进行管理  nacos

***为什么进行服务优化 
公共功能的提取  重复的轮子的提取  历史遗留问题  通过组件化 还有服务化  把各个组件都单独部署    需要用到服务就直接调用就好了，分治的策略  大中台小前台  把主要的应用进行各种拆分  微服务的思想  把服务按照不同的维度进行组合 解耦   服务的可重用    服务化之后也会出现一些问题  得到好处的同时肯定也会遇到新的问题  

PM项目经理   对于同一个需求   不同的人会有不同的理解，需要真正理解用户的正确需求  需求分析做不好，那么就会导致需求的不断的变更    一些没必要的变更  不要以为用户需要什么需要真正理解用户的需求

分析清楚哪些是经常变化的需求 跟相对比较稳定的需求  不管是由谁引发的  需求分析的方法 需求需要从那几个方面来进行获取  

***电商订单系统 
下完订单  跟减少库存肯定是一起进行的    订单系统的流程
角色  以及设计到的一些系统  
订单服务  创建 查询  展示 流程  实体跟数据表的类型  基本上都是一致的用户的的编号 用户的收货信息等等