一、服务熔断
1、什么是服务熔断
熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游 服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
这种牺牲局部，保全整体的措施就叫做熔断。 如果不采取熔断措施，我们的系统会怎样呢？
举例说明: 当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游. 它们的调用链如下：
一旦下游服务C因某些原因变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源 逐渐耗尽，使得服务B也变得不可用。紧接着，服务 A也变为不可用，整个调用链路被拖垮。
像这种调用链路的连锁故障，叫做雪崩。
2、熔断机制
在这种时候，就需要我们的熔断机制来挽救整个系统。
这里需要解释两点：
1. 开启熔断 在固定时间窗口内，接口调用超时比率达到一个阈值，会开启熔断。 进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降 级的效果。
2. 熔断恢复 熔断不可能是永久的。当经过了规定时间之后，服务将从熔断状态恢复过来，再次接受调用方的远程 调用。
3、熔断机制实现
1. Spring Cloud Hystrix
Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现，该框架实现了服务熔断、线程隔离等 一系列服务保护功能。
对于熔断机制的实现，Hystrix设计了三种状态：
熔断关闭状态（Closed）
服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
熔断开启状态（Open）
在固定时间内（Hystrix默认是10秒），接口调用出错比率达到一个阈值（Hystrix默认为 50%），会进入熔断开启状态。进入熔断状态后， 后续对该服务接口的调用不再经过网络， 直接执行本地的fallback方法。
半熔断状态（Half-Open）
在进入熔断开启状态一段时间之后（Hystrix默认是5秒），熔断器会进入半熔断状态。所谓半 熔断就是尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达 到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断开启 状态。
三个状态的转化关系如下图：
2. Sentinel
Sentinel 和 Hystrix 的原则是一致的: 当调用链路中某个资源出现不稳定，例如，表现为
timeout，异常比例升高的时候，则对这个资源的调用进行限制，并让请求快速失败，防止避免影响到其它的资源，最终产生雪崩的效果。
Sentinel 熔断手段:
- 通过并发线程数进行限制
- 通过响应时间对资源进行降级
- 系统负载保护
二、服务链路追踪
1、什么是服务链路追踪
分布式微服务架构上通过业务来划分服务的，通过REST调用对外暴露的一个接口，可能需要很多个 服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口 调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。
随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：
分布式链路追踪（Distributed Tracing），也叫 分布式链路跟踪，分布式跟踪，分布式追踪 等等. 其 实就是将一次分布式请求还原成调用链路。显示的在后端查看一次分布式请求的调用情况，比如各个节 点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求状态等等。
2、链路跟踪具备的功能
1. 故障快速定位
通过调用链跟踪，一次请求的逻辑轨迹可以用完整清晰的展示出来。开发中可以在业务日志中添 加调用链ID，可以通过调用链结合业务日志快速定位错误信息。
2. 各个调用环节的性能分析
在调用链的各个环节分别添加调用时延，可以分析系统的性能瓶颈，可以进行针对性的优化。通 过分析各个环节的平均时延，QPS等信息，可以找到系统的薄弱环节，对一些模块做调整。
3. 数据分析
调用链绑定业务后查看具体每条业务数据对应的链路问题，可以得到用户的行为路径，经过了哪些 服务器上的哪个服务，汇总分析应用在很多业务场景。
4. 生成服务调用拓扑图
通过可视化分布式系统的模块和他们之间的相互联系来理解系统拓扑。点击某个节点会展示这个 模块的详情，比如它当前的状态和请求数量。
3、链路跟踪设计原则
1. 设计目标
- 低侵入性，应用透明
- 低损耗
- 大范围部署，扩展性
2. 埋点和生成日志
埋点即系统在当前节点的上下文信息，可以分为客户端埋点、服务端埋点，以及客户端和服务 端双向型埋点。埋点日志通常要包含以下内容：
TraceId、RPCId、调用的开始时间，调用类型，协议类型，调用方ip和端口，请求的服务名等 信息；调用耗时，调用结果，异常信息，消息报文等
3. 抓取和存储日志
日志的采集和存储有许多开源的工具可以选择，一般来说，会使用离线+实时的方式去存储日 志，主要是分布式日志采集的方式。典型的解决方案如Flume结合Kafka。
4. 分析和统计调用链数据
一条调用链的日志散落在调用经过的各个服务器上，首先需要按 TraceId 汇总日志，然后按照 RpcId 对调用链进行顺序整理。调用链数据不要求百分之百准确，可以允许中间的部分日志丢失。
5. 计算和展示
汇总得到各个应用节点的调用链日志后，可以针对性的对各个业务线进行分析。需要对具体日志 进行整理，进一步储存在HBase或者关系型数据库中，可以进行可视化的查询。
4、链路跟踪Trace模型
Trace调用模型，主要有以下概念：
Client && Server：对于跨服务的一次调用，请求发起方为client，服务提供方为Server各术语在一次 分布式调用中，关系如下图所示
链路跟踪系统实现:
大的互联网公司都有自己的分布式跟踪系统，比如Google的Dapper，Twitter的zipkin，淘宝的鹰 眼，新浪的Watchman，京东的Hydra等等。