如何设计分布式架构

微服务划分维度（本质有两个维度）

1.架构层面：如网关、业务逻辑、数据访问等这些层次。
2.业务层面：如商品销售系统中的商品查看、商品订单、商品瓶扣库存等这些业务。

微服务使用场景考虑

1. 产品的需求层面 :如果产品需求比较少，改动点少，业务单一，如：打卡系统，简单的HR系统等这些无系统频繁拓展的无需使用分布式。
2. 性能需要层面：如果系统某一块的吞吐量需求较大，就需要进行服务拆分；
3. 数据一致性层面:微服务在数据强一致性方面有所欠缺，没有强一致性可以使用，像有些比较苛刻的精确到1毫秒的不适用，保证最终一致性比较适合；

微服务架典型模式

1.链路架构模式：比如商品下单、商品扣款、商品扣库存这种一次执行的逻辑。
2.异步消息模式：比如用户需要申请二维码码包，这种码量比较大的不能即时返回，可以将用户请求参数保存下来然后发送一个消失给下游服务处理，即时返回给用户请求成功。

3.数据共享模式：比如多个服务共用一个库，一个负责负责写，一个负责读。
4. 聚合器架构模式：比如一个页面需要显示用户名、用户图片、用户感兴趣的领域，是请求一次后台还是请求三次后台呢?那肯定是请求一次后台比较好的，然后在一个接口的业务层调用其他需要查询的接口然后综合起来返回。

如何让服务高可用

1.无状态设计：比如spring cloud中网关层就是无状态服务的，便于服务冗余做扩容，配置部署多台机器；

2.负载均衡:广义的负载均衡需要考虑

• 幂等
  多次请求后端接口返回的结果一致，如多次付款最终肯定是只有一次付款成功的。
• 事故处理机制的：
  （1）故障自动发现，如果只通过注册中心发现故障是不太靠谱的，比如服务内部的异常就不能发现进行自动发现，有一个案例可以通过网关拦截多次错的；
  （2）故障自动处理解决,如熔断处理，再如上条说的通过网关发现异常后可以通过调用另外一个服务进行异常服务的重启，重启步骤(1.jstack2即打印两次堆栈消息便于排查问题；2.kill errorlogic杀掉异常服务；3.seleep 6s等待6秒的用处在于让注册中心将错误实例剔除掉；4.start errorlogic重新启动错误的服务，服务会再次注册提供相应业务服务);
  （3）请求自动重试，一般请求都是自动重试三次的，因为服务一次性不可能同时挂掉三台，请求第一次异常换一台实例请求，异常第二次异常再换一台重试，如果三次都异常暂时不要再重试了，不然有可能服务正扛着大负载，频繁请求会加重服务负载，很有可能将服务玩蹦了；

3.异步化设计：如果一项业务流程很长，要求即时返回就会有超时的风险，这种需要即时返回又不要求强一致性的可以使用异步处理的方式；

4.服务限流及熔断：如果吞吐量极大，很有可能就将你的服务瞬间干死，为避免这种突增的大流量，我们可以对服务进行限流，比如江请求放入一个队列中，如果队列达到峰值则暂时不进行后面的请求处理；

5.架构拆分:如服务中业务架构拆分，部门架构拆分，数据库方面（复制、缓存、sharding）等；

##微服务架构演进示例引用

• 初始架构：
  

• 改进后架构：

• 最终采用架构