一、微服务相关
1.1 微服务调用雪崩问题
微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。
微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了。
处理方案
超时处理
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
舱壁模式
仓壁模式来源于船舱的设计，船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
断路器
由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
限流
限制业务访问的QPS，避免服务因流量的突增而故障。
限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。
超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。
二、数据库相关
2.1 分库分表带来的问题
事务一致性问题 由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。
跨节点关联查询 但垂直分库后[商品信息]和[店铺信息]不在一个数据库，甚至不在一台服务器，无法进行关联查询。 可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数 据，最后将获得到的数据进行拼装。
跨节点分页、排序函数 跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据 进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。 在使用Max、Min、Sum、Count之类的函数进行计算的时候，与排序分页同理，也需要先在每个分片上执行相应 的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。 主键避重 在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据 库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题
公共表 实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。例子中地 理区域表也属于此类型。 可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。