项目中遇到问题的解决方案

1：微服务架构的一个缺点是服务间接口调用太过频繁。特别是在获取一个数据集合，每条记录都需要去调用其他微服务的接口时，过多的服务间接口调用会导致速度慢，性能降低。

   项目中遇到问题如下：

   需要从一个业务模块中获取订单详情，其中还包括销售人员的名字一起展示，但是该业务模块只有订单信息，订单信息中只有销  售人员的id，没有名字，这个时候如果采用微服务的接口调用方式，从员工模块中根据销售人员id获取名字的方式，会导致每条订单记录都需要调用员工模块接口，导致大量的系统间频繁的通信。

解决方案：

     传统的解决办法是将订单表扩展一个销售人员名字的字段，增加数据冗余，修改订单下发接口。但如果已经上线的项目后期小的优化这样改的话存在风险。

     另一种替代办法在采用微服务的接口调用方式的基础上，将每次获取的销售人员的id和名字都保存到redis中，每次调用员工模块时都先去redis中查询是否其已存在。这样的话可以降低系统间的通信，同时减少数据库的数据冗余。

    还有一种方式就是在调用接口查询时将列表数据一次性发送请求，接收端查询出所有列表结果数据返回，避免多次请求，减少网络通信次数。

2：电商项目中数据库表不推荐外键关联，但是在被关联表中删除数据时会导致关联表中经常出现数据缺失的问题，但如果在删除数据时在业务层删除数据做关联查询来判断是否被关联使用，会导致业务层逻辑复杂，特别是被多个业务表关联，会导致多次关联查询操作，后面每次增加一个业务关联都得增加一次判断。

解决方案：

  可以在关联表中增加一个被关联次数的字段，每次关联时都加1，每次取消关联都减一。      

3: 在使用Activities 工作流过程中，无法满足业务人员可视化的定义流程，也无法去修改已创建好的流程。

   解决方案:  可以做一个节点任务池，将业务中用到的大部分节点任务都提前创建好，在定义流程时，将各个节点任务做串联就可！

4: 订单表水平切分多库时如何存储数据，业务方面有客户查询和商家查询的需要，是通过客户ID来做hash还是通过商家ID来做hash?

      可以通过客户ID里面包含商家ID，对商家ID做hash.