Zipkin

通过zipkin的表结构，理解dapper；trace把多个span进行串接； 形成依赖链路。 结构 zipkin主要包括：collector、storage、search、webui； zipkin collector会对一个到来的被trace的数据（span）进行验证、存储并设置索引。 其中storage包括：内存、mysql、es、cassandra。 数据结构 Annotation：用于定位一个request的开始和结束，cs/sr/ss/cr含有额外的信息，比如说时间点，当这个annotation被记录了，这个RPC也被认为完成了。 cs：Client Start,表示客户端发起请求 ；一个span的开始； cr：Client Received,表示客户端获取到服务端返回信息；一个span的结束 sr：Server Receive,表示服务端收到请求 ss：Server Send,表示服务端完成处理，并将结果发送给客户端 sr-cs：网络延迟 ss-sr：逻辑处理时间 cr-cs：整个流程时间 Span：一个请求（包含一组Annotation和BinaryAnnotation）；它是基本工作单元，一次链路调用(可以是RPC，DB等没有特定的限制)创建一个span，通过一个64位ID标识它。span通过还有其他的数据，例如描述信息，时间戳，key-value对的

1.1. 前言   粗略看了下spring cloud sleuth core源码，发现内容真的有点多，它支持了很多类型的链路追踪，我就找其中一个比较有代表性的深入剖析下源码结构和内容 1.2. spring-cloud-sleuth-core源码解析 1.2.1. 结构 可以看到源码中支持的追踪类型有很多，支持async，hystrix，websocket，rxjava，Spring mvc，servlet，spring restTemplate，feign，zuul等等，这里我着重探讨spring web mvc的链路追踪 打开web包，找到TraceWebAutoConfiguration，这里配置了主要的初始化类 1.2.2. 过滤器注册 当启动初始化程序时，跟踪代码如下 @Bean public FilterRegistrationBean traceWebFilter(TraceFilter traceFilter) { FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean( traceFilter); filterRegistrationBean.setDispatcherTypes(ASYNC, ERROR, FORWARD, INCLUDE, REQUEST);

当前的分布式微服务云架构平台使用Maven构建，所以common-service的通用服务按照maven构建独立的系统服务，结构如下： particle-commonservice： spring cloud 系统服务根项目，所有服务项目的根依赖。 particle-commonservice-admin： spring cloud/boot的微服务管理、监控平台（里面会集成很多的组件服务项目） particle-commonservice-apigateway：API网关通用服务项目，所有的请求首先会经过这个网关。有点类似于前端控制器模式，也有点类似于 Facade模式。由于所有的请求会先经过这个 api 网关，所以可以在这里做权 限控制，安全，负载均衡，请求分发，监控 等等。以下的一张图片是从网上找的，方便大家理解： particle-commonservice-cache：针对于分布式缓存提供服务化项目，封装分布式缓存redis等。 particle-commonservice-config： 提供独立的微服务配置管理项目项目。配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。 particle-commonservice-erueka： 提供独立的微服务服务发现、注册管理平台。云端服务发现，一个基于 REST

本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末链接。 前言 随着应用架构往云原生的方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。 下面我将会就可观察性在云原生的起源，可观察性发展动力，可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。 才疏学浅，欢迎拍砖。 为什么云原生时代需要可观察性 可观察性的由来 在云原生语境下的可观察性这个词，最早出现于2017年7月，Cindy Sridharan 在Medium 写的一篇博客， "Monitoringand Observability"[1] 谈到了可观察性与云原生监控的关系。 而在2017年10月，来自 Pivotal 公司的Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整，将 Cloud Native Architectures 定义为具有以下六个特质： 模块化 （Modularity） (通过微服务) 可观察性 （Observability） 可部署性 （Deployability） 可测试性 （Testability） 可处理性 （Disposability） 可替换性

分布式链路跟踪 Sleuth 与 Zipkin 随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。 Spring Cloud Sleuth 也为我们提供了一套完整的解决方案。在本章中，我们将详细介绍如何使用 Spring Cloud Sleuth + Zipkin 来为我们的微服务架构增加分布式服务跟踪的能力。 Spring Cloud Sleuth 一般的，一个分布式服务跟踪系统主要由三部分构成： 数据收集 数据存储 数据展示 根据系统大小不同，每一部分的结构又有一定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（Trouble Shooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（需要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展示又涉及到数据挖掘和分析。虽然每一部分都可能变得很复杂，但基本原理都类似。 服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程

1.1. 前言   粗略看了下spring cloud sleuth core源码，发现内容真的有点多，它支持了很多类型的链路追踪，我就找其中一个比较有代表性的深入剖析下源码结构和内容 1.2. spring-cloud-sleuth-core源码解析 1.2.1. 结构 可以看到源码中支持的追踪类型有很多，支持async，hystrix，websocket，rxjava，Spring mvc，servlet，spring restTemplate，feign，zuul等等，这里我着重探讨spring web mvc的链路追踪 打开web包，找到TraceWebAutoConfiguration，这里配置了主要的初始化类 1.2.2. 过滤器注册 当启动初始化程序时，跟踪代码如下 @Bean public FilterRegistrationBean traceWebFilter(TraceFilter traceFilter) { FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean( traceFilter); filterRegistrationBean.setDispatcherTypes(ASYNC, ERROR, FORWARD, INCLUDE, REQUEST);

收集器抽象 由于zipkin支持http以及kafka两种方式上报数据，所以在配置上需要做下抽象。 AbstractZipkinCollectorConfiguration 主要是针对下面两种收集方式的一些配置上的定义，最核心的是Sender接口的定义，http与kafka是两类完全不同的实现。 public abstract Sender getSender(); 其次是协助性的构造函数，主要是配合构建收集器所需要的一些参数。 zipkinUrl 如果是http收集，那么对应的是zipkin api域名，如果是kafka，对应的是kafka集群的地址 topic 仅在收集方式为kafka是有效，http时传空值即可。 public AbstractZipkinCollectorConfiguration(String serviceName,String zipkinUrl,String topic){ this.zipkinUrl=zipkinUrl; this.serviceName=serviceName; this.topic=topic; this.tracing=this.tracing(); } 配置上报方式,这里统一采用异常上传，并且配置上报的超时时间。 protected AsyncReporter<Span> spanReporter() { return

一、服务下线延迟问题 这个虽然是为了更好的高可用，但是下线服务依然存留很长一段时间（默认下最长有2分钟），不利于集群环境部署。 解决办法: 去除保护机制，修改默认的配置，使服务尽快被去除。可看这里。 二、配置中心的git账号问题 配置中心可以使用git统一管理配置，配置git账号如果填自己的就会泄露自己密码。使用密码加密也是不可行的，因为也会被解密。 解决办法： 使用ssh登陆，springcloud config server使用JGit从git获取资源，JGit支持ssh登陆。 如果生成密钥设置了passphrase，在配置加上passphrase：id_rsa的通行码即可。 三、eureka prod环境注册的权限问题 怎么对注册prod环境做限制？万一不小心启动了prod岂不是很危险。 解决办法：暂没想到~ 四、对springcloud的认识 使用起来很方便，简单的配置就可以跑起来一套微服务架构。 而且现在还处在快速更新阶段，最新的F版本全部支持sb2.0，是个更新很大的版本，以后肯定会更强大。 组件很多，一般企业分布式开发所需要的功能都可以使用springcloud实现。 如果将就，那完全使用springcloud全家桶。 如果讲究，那肯定是不行的，springcloud帮我们实现了很多，很多默认配置，拓展起来有时候很不方便。 所以，实际应该还是，视情况而定

前文搭建的Zipkin Server是没有后端存储的——数据会存储在Zipkin的内存中。这一般不适合生产，本节来探讨如何将Zipkin中的数据持久化。 Zipkin支持多种存储： 内存（默认） MySQL（数据量大时，查询较为缓慢，不建议使用） Elasticsearch Cassandra（Twitter官方使用Cassandra作为Zipkin Server的存储，但国内大规模用Cassandra的公司较少，Cassandra相关文档也不多） 综上，个人建议使用Elasticsearch作为Zipkin Server的存储。 OK，话不多说，来搭建吧。 搭建 前往 https://www.elastic.co/products/elasticsearch 下载Elasticsearch，笔者使用的版本是 elasticsearch-6.5.3 启动Elasticsearch： cd elasticsearch-6.5.3/bin ./elasticsearch # Elasticsearch集群的搭建大家自己百度一下吧，也很简单。本文主要是讲Zipkin，只用一个实例演示就可以了。 执行如下命令，启动Zipkin Server STORAGE_TYPE=elasticsearch ES_HOSTS=localhost:9200 java -jar zipkin-server

我们知道，Zipkin这个工具可以帮助我们收集分布式系统中各个系统之间的调用连关系，而且除了Servlet之外还能收集：MQ、线程池、WebSocket、Feign、Hystrix、RxJava、WebFlux等等组件之间的调用关系。本篇文章就来分析一下Zipkin是如何完成这些功能的 我们先以最常用的Servlet接受请求为例来分析 在spring-cloud-sleuth的spring.factories文件中注入的很多类中包含了一个类： TraceWebServletAutoConfiguration ，一看就知道，这是为Servlet环境量身定制的一个自动装配类 在这个类中，创建了一个Filter，这个Filter就是拦截web请求，完成Servlet请求链路的收集的利器 @Bean @ConditionalOnMissingBean public TracingFilter tracingFilter(HttpTracing tracing) { return (TracingFilter) TracingFilter.create(tracing); } 我们直接来看这个拦截器都是做了一些什么东西吧 public void doFilter(ServletRequest request, ServletResponse response, FilterChain