Zipkin

题记 今年是我个人从事软件测试工作的第六个年头，职业生涯至今经历了功能-接口-自动化-性能测试岗位的变迁。 18年下半年开始以团队owner的角色进行工作开展，不过当时团队技术体系建设已经步入正轨，对我个人而言，并没有太多沉淀。 19年跳槽后，有幸从零开始主导我司的性能测试体系建设工作，个人之前的很多想法得以落地实现。 这也许是除了薪资之外，对我个人而言获得的最大成就感。。。 导图 演进 基础建设 1、文档建设 前段时间知乎回答了一个问题： 做技术人是不是都反感写文字类的东西，比如需求文档，需求分析等等？ 之前的博客也写过类似的内容： 性能测试从零开始实施指南——文档建设篇 。 我个人认为无论是作为个人学习笔记抑或一个Team的累积沉淀，文档建设的工作必不可少，而且是重中之重。原因如下： 1） 降低“口头说明”带来的风险； 2）文档是很重要的记录和交流介质； 3） 便于事前、事中、事后快速回溯追踪； 4） 降低工作交接、沟通的成本，提高效率； 5）文档是一次梳理思路，review的方式； 6）文档是很重要的工作产出，自我价值诉求的重要手段（KPI）； 当然，现在有很多在线协同文档工具，如confluence、语雀（参考- 工具汇总 ）。我司性能团队文档类目如下： 2、资源管理 这里的资源主要指压测资源，包含如下几项： 1）压测机 2）压测场景 3）压测脚本 4）压测数据

0. 前言 这是一个新的系列，来源于工作中的一个需求，领导准备新开一个项目线路，要求使用Java，项目符合现有主流技术，并要求对并发量有一定的承受能力 ，支持扩展。我和公司的几个小伙伴一起沟通了一下，这不就是标准的Spring Cloud微服务的系统架构吗。 之前读过小高之前发的文章的小伙伴也清楚我是C#开发，不过想当年我也系统学过Java，多年下来虽然手生，但也好歹没有落下技术。于是就揽下了这个活。毕竟学习是终身的。 不怎么简明的介绍了这个系列成立的原因，让我们言归正传，这个系列是我在搭建该项目过程的一个总结，如果后续开发中对框架有调整，也会在这个系列发布后续的更新。这也是为什么叫实战系列，而不是实战教程的原因。 那么，有兴趣的小伙伴，跟我一起来吧～ 1. 项目结构 项目采用maven作为软件包管理工具，Spring boot+Spring Cloud作为项目基础架构，设有配置中心、服务发现中心、网关中心和链路追踪中心以及服务集群，其中服务集群之间添加链路熔断和负载均衡机制。 当然，目前参照了几个系统都按照这种逻辑搭建的框架，所以我们大致上也参考了这个模型。具体如下图： 2. 主要技术组件使用 这里大概介绍一下，我在实践中选用的技术组件，选用这些技术没多少原因，很大程度上考虑到团队喜好以及后续维护的方便，还有就是官方团队的维护上考虑。 2.1 Maven Maven 翻译为"专家

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示： 　　随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下： 　　随着业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题： 如何快速发现问题？ 如何判断故障影响范围？ 如何梳理服务依赖以及依赖的合理性？ 如何分析链路性能问题以及实时容量规划？ 　　 　　而链路追踪的出现正是为了解决这种问题，它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。 　　除此之外，如果某个接口突然耗时增加，也不必再逐个服务查询耗时情况，我们可以直观地分析出服务的性能瓶颈，方便在流量激增的情况下精准合理地扩容。 　　 什么是链路追踪 　　 　　“链路追踪”一词是在 2010 年提出的，当时谷歌发布了一篇 Dapper 论文： Dapper

Sleuth+Zipkin用来实现分布式系统的链路追踪。 Sleuth组件用于日志埋点、记录链路数据，Zipkin组件用于展示链路数据。 Sleuth的使用 （1）创建消费者、提供者时勾选Spring Cloud Tracing -> Sleuth 也可以手动添加依赖： < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-sleuth </ artifactId > </ dependency > （2）在消费者、提供者处理业务的类中添加成员变量 //使用的是 slf4j的日志，不要导错了 private final Logger logger = LoggerFactory.getLogger( this .getClass()); 在处理业务的方法中（消费者调用提供者、提供者处理业务的方法中），输出日志 logger.info("正在执行user-service的findOrdersByUserId方法，调用服务order-service"); 内容根据需要修改。 Sleuth输出的日志往往是空的，只输出服务名：[order-service,,,] 第（2）步是为了解决此问题，使Sleuth输出的日志有内容。 [order

作者 | 王夕宁 阿里云高级技术专家 参与阿里巴巴云原生公众号文末留言互动，即有机会获得赠书福利！ **导读：**本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，在展望服务网格未来的同时，讲述了如何使用 Istio 进行多集群部署管理，来阐述服务网格对多云环境、多集群即混合部署的支持能力。 你只需开心参与阿里巴巴云原生公众号文末互动，我们负责买单！技术人必备书籍《Istio 服务网格技术解析与实践》免费领~ 服务网格作为一个改善服务到服务通信的专用基础设施层，是云原生范畴中最热门的话题。随着容器愈加流行，服务拓扑也频繁变动，这就需要更好的网络性能。服务网格能够通过服务发现、路由、负载均衡、心跳检测和支持可观测性，帮助我们管理网络流量。服务网格试图为无规则的复杂的容器问题提供规范化的解决方案。 服务网格也可以用于混沌工程 —— “一门在分布式系统上进行实验的学科，目的是构建能够应对极端条件的可靠系统”。服务网格能够将延迟和错误注入到环境中，而不需要在每个主机上安装一个守护进程。 容器是云原生应用的基石，通过应用容器化，使得应用开发部署更加敏捷、迁移更加灵活，并且这些实现都是基于标准化的。而容器编排则是更近一步，能够更加有效地编排资源、更加高效地调度利用这些资源。而到了云原生时代，在 Kubernetes 基础架构之上，结合 Istio 服务网格

前言 在spring cloud分布式架构中，系统被拆分成了许多个服务单元，业务复杂性提高。如果出现了异常情况，很难定位到错误位置，所以需要实现分布式链路追踪，跟进一个请求有哪些服务参与，参与的顺序如何，从而去明确一个问题。 spring cloud sleuth 通常来说，一个分布式服务跟踪系统主要由三部分：数据收集、数据存储和数据展示。 对于大规模的分布式系统来说，数据存储可分为实时数据和全量数据两部分。实时数据用来排查故障，全量数据用于系统优化；数据展示涉及数据挖掘和分析。 名词解释 服务追踪的追踪单元是从客户端发起请求抵达被追踪的系统边界开始，到被追踪的边界开始，到被追踪的紫铜向客户返回响应为止的过程，称呼为一个 "trace"。每个 trace 中会调用若干个服务，为了记录调用了哪些服务，以及每次调用的响应时间等信息，在调用每个服务时，都会迈入一个调用记录，成为一个 "span"。如此，若干个 有序的 span 就组成了一个 trace 。 在系统向外界提供服务的过程中，会不断地有请求和响应发生，也就会不断生成 trace ，把这些带有 span 的 trace 记录下来，就可以描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间，以及请求成功与否等信息，就可以在发生问题的时候，找到异常的服务；根据历史数据，还可以从系统整体层面分析出哪里性能差，定位性能优化的目标。

一、前言 Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案 ,并且兼容了zipkin，提供了REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序 。 Sleuth 是个组件，没有提供我们可视化的界面，和一些相信的api信息，而zipkin 是个系统，他有可视化的界面，和对应接口调用详细的信息情况。 二、为什么要使用链路追踪 微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。 ，对调用链的分析会越来越复杂。如果那里出现了错误，我们是很排查的。所以我们引入了链路追踪，使用可视化的界面我们可以很容易的找到那一块耗时多，等等。 Sleuth 的使用： 　　1.在项目中加入依赖： <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> 2.然后在你想打印日志的地方输入 控制台会出现下面这个 （现在看起来是不是感觉使用起来也不怎方便，下面我会讲zipkin

SpringCloud第十一章，升级篇，分布式链路跟踪Sleuth 一、分布式链路概述 1、为什么 随着分布式系统越来越复杂，你的一个请求发过发过去，各个微服务之间的跳转，有可能某个请求某一天压力太大了， 一个请求过去没响应，一个请求下去依赖了三四个服务，但是你去不知道哪一个服务出来问题， 这时候我是不是需要对微服务进行追踪呀？监控一个请求的发起，从服务之间传递之间的过程， 我最好记录一下，记录每一个的耗时多久，一旦出了问题，我们就可以针对性的进行优化， 是要增加节点，减轻压力，还是服务继续拆分，让逻辑更加简单点呢？ 这时候springcloud-sleuth集成zipkin能帮我们解决这些服务追踪问题。 2、是什么 SpringCloud Sleuth提供了一套完整的服务跟踪的解决方案，在分布式系统中提供追踪解决方案并且兼容支持了zipkin. SpringCloud从F版起已不需要自己构建Zipkin server了，只需要调用jar包即可 3、相关概念 1、Span： 基本工作单元.例如,在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC,span通过一个64位ID唯一标识, span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID. span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，

前言 最新一直在忙着项目上的事情，很久没有写博客了，在这里对关注我的粉丝们说声抱歉，后面我可能更多的分享我们在微服务落地的过程中的一些经验。那么今天给大家讲一下在 .NET Core 2 中引入的全新 DiagnosticSource 事件机制，为什么说是全新呢？ 在以前的 .NET Framework 有心的同学应该知道也有 Diagnostics，那么新的 .NET Core 中有什么变化呢？ 让我们一起来看看吧。 Diagnostics Diagnostics 一直是一个被大多数开发者忽视的东西，我猜测很多同学看到这里的时候可能还是第一次听说 Diagnostics 这个东西，为什么会被忽视呢？ 我们等会说，我们先来看一下 Diagnostics 是用来做什么的。 Diagnostics 是什么呢？ 让我们把时间往前拉回到 2013 年 8 月，微软在 NuGet 发布了一个新的关于 Diagnostics 的包叫做 Microsoft.Diagnostics.Tracing.TraceEvent ，这个包用来为 Windows 事件追踪（ETW）提供一个强大的支持，使用这个包可以很容易的为我们在云环境和生产环境来提供端到端的监控日志事件记录，它轻量级，高效，并且可以和系统日志进行交互。 PS：通过这个包我们可以获取到 CLR 运行的一些细节信息，由于本篇主题

总目录索引： istio从入门到放弃系列 1、jaeger 介绍 jaeger 官网： https://www.jaegertracing.io/ jaeger 是 Uber 开源的分布式跟踪系统，用于微服务的监控和全链路跟踪，其设计思想来自于 Dapper 和 zipkin。jaeger 特征包括： 分布式上下文传播 分布式事务监控 Root 原因分析 服务依赖性分析 性能/延迟优化 2、jaeger 安装 如果你使用 istioctl profile demo 安装 istio 的话，jaeger 默认就是安装好的 为了可以将 jaeger 暴露在 k8s 集群外访问，需要将 jaeger-query 的 ClusterIP 服务类型更改为 NodePort。执行语句如下 kubectl patch svc -n istio-system jaeger-query -p '{"spec":{"type": "NodePort"}}' 3、kiali 关联 jaeger kiali 是可视化服务网格组件，截图如下： 点击上面箭头 Distributed Tracing 链接可以打开 jaeger。如果访问不到，说明你本地的浏览器并不能直接访问到 kiali 设置的 jaeger 外部链接。 4、设置 kiali jaeger 外部链接地址 编辑 kiali configmap：