高可用
对等节点的故障转移
非对等节点的故障转移，如MySql主从切换，redis哨兵等
接口层面的幂等、超时、重试策略等
接口层面降级，非核心接口熔断、核心接口有备选链路（针对调用方）
hystrix熔断原理
熔断
时间窗口内某个错误达到某个量并且超过指定比例，熔断器开启（熔断器会开启一定时间 sleepWindows）
熔断恢复
当发生熔断，达到SleepWindows指定时间后，则状态会由OPEN转换为HALF_OPEN，此时只会让一个请求通过，如果该请求执行成功，状态则会转换为CLOSED，否则会回到OPEN状态，并且熔断时间设置为当前时间，重新等待SleepWindows的时间（达到一定时间后，放行一个请求去尝试是否要继续熔断）
限流（对超过接口处理能力的请求直接返回错误码或拒绝请求，针对被调用方）
4种限流算法对比
1. 固定窗口（计数器），缺点很明显，管理粗放，而且临界情况下会超过限流阈值
2. 滑动窗口，窗口越多越平滑，但是窗口越多，算法需要的空间容量越多，且本身还是窗口算法，无法完全解决临界情况下超过限流阈值的情况
可以通过redis的zset实现<br>score是记录请求的时间戳，利用zremrangeByScore删除（当前时间-窗口）时刻之前的数据，<br>利用Zcard（统计key对应队列元素数量）判断当前时间所在窗口的请求数来进行限流<br>（窗口=队列长度）<br>由于要统计每个请求，在限流阈值较高的情况，所占容量会很大<br>限定 60s 内操作不得超过 100w 次这样的参数，它是不适合做这样的限流的，因为会消耗大量的存储空间。<br>
sentinel实现：<br>通过环形数组实现，环形数组可以代表一分钟或者一秒钟，通过当前时间戳取模定位到数组元素，即在环中，属于第几个窗口，窗口元素保存当前窗口请求数，错误数，窗口起始时间等数据；窗口过期则数据重置，窗口实例本身是复用的，减少ygc压力。<br><br>举个例子，我们需求统计1min内的数据，可以申请size=60的数组，每个元素代表1秒内的统计窗口。我们拿到当前的时间戳，1577017699235，去掉毫秒数得1577017699，对60取模得19，取数组中index=19的窗口，获取WindowWrap的windowStart，如果windowStart=1577017699000，取直接使用当前窗口统计数据，否则，说明此窗口已过期，重置WindowWrap对象的值，新窗口统计。<br><br>
3. 漏桶，流量经过漏桶后速度恒定（实现可以是请求存到队列排队，然后消费队列的速度恒定，队列满了直接拒绝请求），无法应对突发流量，适合性能较弱服务
4. 令牌桶，可以通过控制令牌发放速度应对突发流量，压榨机器，适合性能较强服务
MQ场景的可靠性保证，Producer的重试机制，Broker的持久化机制，Consumer的ACK机制
灰度发布，支持按机器维度小流量发布，观察日志后平稳后全量上线
监控报警：全方位的监控体系，基本的如CPU、内存、磁盘、网络，另外像JVM、中间件、数据库等监控及业务指标的监控
业务指标监控怎么做？<br>
日志接入监控平台，监控平台根据正则统计，例如10秒周期内下单成功数，失败数等等
灾备演练，类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。
高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。
高扩展
合理的分层架构
但是要平衡服务多了之后的性能问题（网络上多了一跳）
存储层的拆分（分库分表）
业务层的拆分
业务流程分，如电商场景的商品服务、订单服务这种
按核心、非核心接口拆分
按请求源，如ToC、ToB或App、H5这样分
