Sleuth+Zipkin链路追踪和OAuth2统一认证相关知识
Sleuth+Zipkin链路追踪
Trace：服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程。
Trace ID：实现请求跟踪，⼀个Trace由⼀个或者多个Span组成，每⼀个Span都有⼀个SpanId，Span中会记录 TraceId，同时还有⼀个叫做ParentId，指向了另外⼀个Span的SpanId，表明父子关系，其实本质表达了依赖关系。
Span ID：统计各处理单元的时间延迟，除了时间戳记录之外，它还可以包含⼀些其他元数据，比如时间名称、请求信息等。每⼀个Span都会有⼀个唯⼀跟踪标识 Span ID,若干个有序的 span 就组成了⼀个trace。
分析方式：
耗时分析：通过 Sleuth 了解采样请求的耗时，分析服务性能问题（哪些服务调用比较耗时）。
链路优化：发现频繁调⽤的服务，针对性优化等，Sleuth就是通过记录日志的方式来记录踪迹数据的。
Spring Cloud Sleuth 和 Zipkin ⼀起使用，把 Sleuth 的数据信息发送给 Zipkin 进行聚合，利用 Zipkin 存储并展示数据。
OAuth2统一认证
认证：验证用户的合法身份，比如输⼊用户名和密码，系统会在后台验证用户名和密码是否合法，合法的前提下，才能够进行后续的操作，访问受保护的资源，微服务下解决多个服务之间单点登录问题。
微服务架构下统⼀认证思路
1）基于Session的认证方式：在分布式的环境下，基于session的认证会出现⼀个问题，每个应用服务都需要 在session中存储用户身份信息，通过负载均衡将本地的请求分配到另⼀个应用服务需要将session信息带过去，否则会重新认证。我们可以使用Session共享、Session黏贴等⽅案。 Session方案也有缺点，比如基于cookie，移动端不能有效使用等
2）基于token的认证方式：基于token的认证方式，服务端不用存储认证数据，易维护扩展性强，客户端可以把token存在任意地方，并且可以实现web和app统⼀认证机制。其缺点也很明显，token由于自包含信息，因此⼀般数据量较⼤，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。
OAuth2开放授权协议
允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容，比如通过QQ登录其他平台。
OAuth2的颁发Token授权方式
1）授权码（authorization-code）
2）密码式（password）提供用户名+密码换取token令牌
3）隐藏式（implicit）
4）客户端凭证（client credentials
使用OAuth2解决问题的本质是，引入了⼀个认证授权层，认证授权层连接了资源的拥有者，在授权层里面，资源的拥有者可以给第三方应用授权去访问我们的某些受保护资源。统⼀认证的场景中，Resource Server其实就是我们的各种受保护的微服务，微服务中的各种API访问接口就是资源，发起http请求的浏览器就是Client 客户端。
微信打赏