分布式高可用

1.稳定性

高可用核心
服务可用性是对服务等级SLA描述
一个核心线路依赖10个服务，可用性99.99%，这个线路就是99.99%的10次方，在生成环境还有考虑服务发布，部署等导致宕机的情况，可用性会降低

1.1 高可用保证

海量用户请求
应用Docker容器化编排，分布式需要快速扩展集群
容器化编排操作简单，可以快速扩展实例
流量突增
典型秒杀系统的请求曲线，瞬间到达峰值。
通过独立热点集群部署，消息队列削峰，相关活动商品预热缓存等方案解决
避免服务雪崩，链路问题，故障传导
微服务调用通常通过一个链路的形式进行，各个服务之间是调用链，某个服务提供者宕机，整个链路失败
可以从限流，降级，熔断，隔离入手

2.限流

限制系统的流量来保护系统，需要结合容量规划和压测进行，外部请求接近或达到系统最大阈值时，触发限流，采用其他手段进行降级，常见降级策略包括延迟处理，拒绝服务，随机拒绝等

2.1 限流算法

线程池任务满后的拒绝策略：AbortPolicy 丢弃任务并抛异常
DiscardPolicy: 丢弃任务 不抛出异常。 DiscardOldestPolicy
计数器法：统计QPS,单点限流使用内存，集群限流可以用一个单独的储存节点，Redis，Memcached进行储存，在固定时间间隔内设置过期时间。
对临界流量不友好，俩个窗口交汇点峰值可能超过阈值。
优化：滑动窗口
漏桶算法：从出口处限制请求速率，请求曲线始终平滑。对请求的过滤太精确。
令牌桶算法：以固定速率向桶里边放入令牌，桶满了令牌丢掉，最后最大令牌数不会超过桶大小。请求进入时，尝试从桶里拿走令牌，空的就会被拒绝。
Guava中，限流策略的工具类RateLimiter基于令牌桶算法实现流量限制
比较：计数器适合集群使用，漏桶算法提供严格限流，令牌桶允许一定突发流量。设置流量峰值N，计数器会出现2N，漏桶始终限制N的流量，令牌桶会大于N，但是不会到达2N

3.降级

对非核心流程业务进行有策略的放弃来释放系统资源保证核心业务运行。

注意梳理核心流程，知道那些业务是可以被牺牲的
明确开启时间，在系统水位到达一定程度时开启

4.熔断

熔断保护是业务系统不被外部大流量或下游系统的异常而拖垮。
添加合理的熔断策略，防止系统不断去请求可能超时和失败的下游业务，一个设计完善的熔断策略，可以在下游服务异常时关闭调用，在恢复正常时逐步恢复流量
订单服务可以在下游评论服务异常时调节流量请求。

10%失败后，减少50%流量请求，如果出现50%异常，减少80%的流量请求
下游正常后，首先恢复30%，再50%，接下来全部

4.1 熔断策略实现

熔断器实现是数据结构有限状态机FSM的一中应用：Sentinel和Hystrix
熔断器的恢复时间：平均故障恢复时间，称为MTTR。
Closed：熔断器关闭状态，比如系统检测到下游失败到了50%的阈值，会开启熔断。
Open：熔断器打开状态，对下游的调用在内部直接返回错误，不发出请求，但在一定的时间周期以后，会进入下一个半熔断状态。
Half-Open:熔断状态，允许少量的服务请求，如果调用都成功则认为恢复了，关闭熔断器，否则回到熔断器打开状态。

5.负载均衡

如何从服务器列表中选择合适的一台，将网络请求派发到集群的一个或多个节点上处理。

硬件负载均衡：F5设备
软件负载均衡：Nginx
流程：通过心跳机制来确认服务可用性，在网络请求到达后，F5或Nginx等负载均衡设备按照不同策略，进行服务器的路由。

5.1 策略

轮询策略： 顺序从服务器列表中选择一个节点，请求均匀落在服务器上
加权轮询：对轮询策略的优化，给每个节点添加不同的权重。
随机策略：从列表随机取一个
最小响应时间：在进行路由时，会优先发送给响应时间最小的节点。
最小并发数策略:记录当前时刻每个节点正在处理的事务数在路由时选择并发的最小的节点。

5.2 实现

服务器负载均衡：请求先发送到负载均衡服务器，然后通过负载均衡算法，在众多服务器选择一个处理请求。Eureka
客户端负载均衡：客户端自己维护服务器地址列表，自己选择请求的地址，通过负载均衡算法将请求发送到服务器。Ribbon
SpringCloud中配置@LoadBalanced注解，客户端在发请求时会选择服务器，向该服务器发送请求，实现负载均衡。
Ribbon是实现Http网络客户端，内置负载均衡工具，支持多种容错。RoundRobinRule轮询策略，RandomRule随机策略，BestAvailableRule最大可用策略，WeightedResponseTimeRule带有加权的轮询策略。

6.监控

了解服务运行水平，提取发现线上问题，避免故障处理不及时

6.1 监控组件

OpenFalcon：小米开源的应用级监控组件，Falcon第一个国内大型开源监控系统
Zabbix:基于Server-Client架构，可以实现各种网络设备，服务器等状态监控，应用灵活，数据存储可以根据业务情况，使用不同实现。Zabbix的Server使用C语言实现，可视化界面基于PHP实现。
Nagios: 支持更丰富的监控设备，包括各类网络设备和服务器。对不同的操作系统进行良好兼容。对各类交换机，路由器等有很好的支持。监控网络服务如SMTP,POP3等，支持主机运行状态自定义服务检查，自定义各种插件实现定制化的功能。

CAT：Central Applicatiob Tracking ,基于Java开发，对各类分布式服务中间件，数据库代理层，缓存和消息队列都有很好的支持。可以为业务开发提供各个系统的性能指标，健康状况，并且还可以进行实时告警。

6.2 监控指标

监控对象
监控数据
报警阈值
监控指标分级

6.3 监控处理

报警处理
SOP
故障划分
处理复盘

6.4 监控处理制度

发现故障，第一时间同步到相关业务负责人，上下游链路。
第一时间恢复业务，快速进行故障止血。
事后进行故障复盘和总结，避免再次出现类似问题。
及时协调资源，避免故障升级

7.稳定性指标

服务器指标

系统运行指标

业务运行时指标
结合上下游链路和产品设计运营一起明确指标划分

基础组件指标

8.日志

8.1 命令

tail cat head
more 可以按照分页的方式实现日志内容，并且可以进行快速翻页操作

8.2 问题

分布式下，日志不方便查看，无法实现日志的快速搜索，日志的集中收集和存储困难。日志分析聚合及可视化。
使用Log4j框架在高并发的场景下写日志可能会出现日志丢失，以及线程阻塞问题，还有日志产生过快，导致磁盘空间不足报警处理

8.3 ELK

ElasticSearch内核使用Lucene实现，实现了一套用于搜索的API，可以实现各种定制化的检索功能，ES使用倒排索引实现


ES中实现索引处理：日志数据导入ES中以后，在这一步中，可以针对不同的日志的索引字段进行定制。
通过Kibana进行可视化操作，查询等：Kibana已经支持非常丰富的日志分析功能，并且可以选择应用一些机器学习插件。
用Flume进行容器内日志收集，将日志消息通过Kakfa传送给Logstash，在kibana中展示。