Eureka的自我保护机制：默认情况下EurekaClient定时向EurekaServer端发送心跳包，如果EurekaServer在一定时间内没有收到EurekaClient发送的心跳包，便会直接从服务注册列表中剔除该服务(默认90S)，但是在短时间丢失大量的服务实例心跳，这时候EurekaServer会开启自我保护机制，不会剔除该服务。

Ribbon本地负载均衡算法实现方式：总请求数%服务器数量得到实际下标服务器位置。

服务雪崩解决方法：服务降级、服务熔断、服务隔离

服务降级分为：超时降级、失败次数降级、故障降级、限流降级。

超时降级：也就是大部分人网上说的，再高并发情况下，防止用户一直等待，直接返回一个友好提示给客户端。

失败次数降级： 主要是一些不稳定的API，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况 。

故障降级： 如要调用的远程服务挂掉了（网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常），则可以直接降级 。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）。

限流降级： 当触发了限流超额时，可以使用暂时屏蔽的方式来进行短暂的屏蔽。当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

吐槽：咦，最开始学习服务降级的时候，网上写的都是这模样还都是千篇一律，乱七八糟的，最后还是专门去纯洁微笑大佬博客去找，才找个能说服我的，现在在搜索网上的博客开始向纯洁介绍的靠拢了，不再是单独一种降级手段。网上说的降级一种是就是12306说的限流降级，另一种说的就是淘宝双11时候关闭评论功能达到降级。然后就蒙蔽了。。。

我觉得应该再加一个资源降级：就是关闭非核心功能，节省资源（服务器器、流量、数据库，嗯，，不过我觉得在微服务下这些都是隔离的，可以直接开新机器就可以了）来保证核心功能的稳定，我觉得也算一种降级方案。

设计一套接口：

接口权限（开放接口还是内部接口），考虑幂等性、安全性（https）,使用网关拦截接口实现黑名单和白名单、接口使用http协议+json格式restfull方便跨平台。考虑高并发 对接口服务实现服务保护、服务降级、熔断、隔离之类、最后使用API统一管理平台 api swagger.