锐客网

  1. 首页 > 睿知 > >

avg变量的定义 avg什么意思

生活知识睿知

分布式架构正在颠覆企业信息化建设的IT架构 。无论是早期的SOA系统，还是现在流程的微服务化和容器化，都是从分布式架构的角度来提高整个系统的吞吐量和容错能力 。另一方面，分布式架构的发展也使得监控更加困难 。过去传统的基于日志和性能指标的监控系统已经很难跟上系统的快速发展 。
因此，在谈到微服务的基础组件时，将会强调调用链跟踪和监控组件 。目前常见的调用链组件有Skywalking、Zipkin、Cat、Pinpoint等 。
呼叫链跟踪系统的发展历史分布式服务跟踪是在整个分布式系统中跟踪用户请求的过程，包括相关数据的收集、传输、存储、分析和可视化 。捕捉到跟踪这部分后，开发和运维可以在用户交互过程中构建整个请求调用链的可视化视图，是调试和监控微服务的核心工具 。2010年，谷歌发表了一篇关于其内部分布式跟踪系统Dapper的论文(http://static . Google user content . com/media/research . Google . com/zh-cn/archive/papers/Dapper-2010-1 . pdf，地址:http://big bully . github . io/Dapper-translation/)，讲述了Dapper在谷歌两年的演进、设计、运营和维护经历 。借助Dapper概念，开发者只需将Trace组件嵌入到基本的通用库中即可正常运行，而应用层开发者无需关心Trace组件的具体实现和集成，从而达到在应用层将Trace组件以透明的方式嵌入到各个模块中的目的 。
呼叫链产品的发展历史
目前流行的开源调用链系统有两个来源:易贝和Google 。Cat起源于易贝的CAL，其他几个系统起源于2010年的google Dapper paper，包括Twitter的开源产品Zipkin，携程的CTrace，南韩的Naver Pinpoint，UBer的Jaeger，华为的Skywalking等等另外，淘宝的鹰眼，京东 。COM的九头蛇，新浪的守望先锋都是不错的链接跟踪监控系统，但都不是开源的 。
呼叫链跟踪系统(一):Zipkin简介开头介绍的是Zipkin，因为现在的Spring Cloud Sleth和Zipkin结合的非常好，所以安装应用非常方便，甚至不需要单独安装 。当Spring Cloud是Finchley版本时，如果只需要默认实现，不需要自己搭建Zipkin服务器，下载jar即可 。目前很多公司都在选择使用Zipkin 。
来自Zipkin网站的跟踪视图截图
来自Zipkin网站的依赖图截图
Zipkin是Twitter开发的开源分布式追踪系统 。每个服务向zipkin上报计时数据，Zipkin会根据调用关系通过Zipkin UI生成依赖图 。
架构概述
跟踪器驻留在应用程序中，记录操作的时间和元数据 。这些通常被组装在库上，所以它们对用户是透明的 。例如，一个已经组装好的Web服务器将在接收请求和发送响应时进行记录 。收集的跟踪数据称为跨度 。
生产环境中的汇编程序应该是安全和低负载的 。因此，带内仅发送ID，并告知接收器仍有一个跟踪正在处理中 。完成的跨度在带外报告给Zipkin，就像应用程序异步报告指示器一样 。
例如，当跟踪一个操作时，该操作发送一个HTTP请求，因此将添加一些额外的头信息来传输ID 。标题信息不用于发送详细信息，如操作说明 。
程序集中用来向Zipkin发送数据的组件叫做Reporter 。Reporter通过传输将跟踪数据发送到Zipkin的收集器，收集器将数据持久化到存储中 。之后，API将查询的数据从存储器提供给UI 。
Zipkin流程架构
Zipkin框架
要理解这幅图，你需要知道Zipkin的一些核心概念:
Reporter
插入应用程序中向Zipkin发送数据的组件称为Report，其目的是跟踪数据收集 。
Span
在微服务中调用一个组件时，从请求到响应的过程会持续一段时间，称为Span 。跨度是工作的基本单位 。例如，在新建的span中发送RPC相当于向RPC发送响应请求 。span由一个64位ID唯一标识，trace由另一个64位ID表示 。span还有其他数据信息，如摘要、时间戳事件、标记、Span ID和进度ID(通常是IP地址) 。
Span不断地启动和停止，同时记录时间信息 。创建span后，必须在将来的某个时间停止 。
Trace
由一系列跨度组成的树形结构 。如果您正在执行分布式大数据项目，您可能需要创建跟踪 。从客户端的请求到请求处理，中间会有一个调用链，叫做Trace 。一个轨迹可以包含多个跨度，而每个跨度都有一个上级轨迹 。
Transport
一种数据传输方法，其中组装库发送的span必须从组装的服务传输到收集器 。主要有三种传输类型:HTTP、Scribe和Kafka 。
Zipkin由以下四个部分组成:
collectorstoragesearchweb UI
Zipkin收集器
一旦跟踪数据到达Zipkin Collector守护进程，Zipkin Collector将对其进行检查、存储和索引以供查询 。
仓库
Zipkin最初是为了在Cassandra中存储数据而构建的，因为Cassandra易于跨站点，支持灵活的模式，并且在Twitter内部被广泛使用 。在Cassandra之外，原生支持ElasticSearch和MySQL 。它可以作为第三方扩展提供给其他后端 。
Zipkin查询服务
一旦数据被存储和索引，就需要一种方法来提取它 。查询守护进程提供了一个简单的JSON API方法来查询和获取跟踪数据 。API的主要消费者是Web UI 。
软件工程师
创建了一个用户图形界面，为跟踪数据提供了一个漂亮的视图 。web提供了一种基于服务、时间和注释查看跟踪数据的方法 。注意:UI没有内置认证功能 。
Spring cloud提供spring-cloud-sleuth-zipkin，方便zipkin实现的集成(指的是zipkin客户端，不是Zipkin服务器) 。这个jar包可以通过spring-cloud-starter-zipkin依赖关系引入 。
根据传输方式，springcloud官方分为三种启动服务器的方式:Sleuth与Zipkin通过HTTP，Sleuth与Zipkin通过Spring Cloud Stream，Spring Cloud Sleuth Stream Zipkin Collector 。
由于HTTP传输的以下缺点:第一，每次传输都涉及到连接和传输的过程；第二，当Zipkin服务器关闭或重启时，客户端收集的信息会被http丢失 。在这里，可以通过使用socket或其他更高效的通信方式，以及使用信息的异步传输在Zipkin客户端和服务器之间添加MQ来解决 。
在信息传输中添加MQ
要将http模式改为MQ通信，需要将原来依赖的io.zipkin.java:zipkin-server改为spring-cloud-sled-zipkin-stream和spring-cloud-starter-stream-rabbit 。
呼叫链跟踪系统(二):Cat简介(1)概述
CAT(Central Application Tracking)是基于Java的实时应用监控平台，为美团点评提供全面的实时监控和报警服务 。CAT的原型和概念来自易贝的CAL系统，该系统最初是由吴琦民在大众点评工作期间设计和开发的 。此前，CAT不仅增强了CAL系统的核心模型，还增加了更丰富的报告 。CAT提供Java、C/C、Node.js、Python、Go等多语言客户端 。，广泛应用于中间件框架(MVC、RPC、数据库、缓存等 。)，并提供系统性能指标、健康状态、监控和报警等 。针对美团点评各业务线 。自2014年开源以来，除了美团点评，CAT已经应用在携程、陆金所、猎聘、Hiring.com、寻找Steel.com等多家互联网公司的制作环境中 。该项目的开源地址是https://github.com/dianping/cat/.
CAT的一大优势在于它是一个实时系统 。大多数CAT系统都是分钟级的统计，但是从数据产生到服务器处理结束都是秒级的 。秒级的定义是48分40秒 。基本上可以看到48分38秒的数据，整体报表的统计粒度是分钟级的 。第二个好处是监测数据全统计，客户端预计算；对链路数据进行采样和计算 。卡特彼勒产品价值
减少故障发现时间降低故障定位成本辅助应用程序优化
卡特彼勒优势
实时处理：信息的价值会随时间锐减，尤其是事故处理过程中全量数据：全量采集指标数据，便于深度分析故障案例高可用：故障的还原与问题定位，需要高可用监控来支撑故障容忍：故障不影响业务正常运转、对业务透明高吞吐：海量监控数据的收集，需要高吞吐能力做保证可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统
(2)卡特彼勒的总体设计
主要分为三个模块:猫-客户端、猫-消费者、猫-家 。
Cat-client 提供给业务以及中间层埋点的底层SDK 。Cat-consumer 用于实时分析从客户端提供的数据 。Cat-home 作为用户给用户提供展示的控制端 。
在实际的开发部署中，CAT-consumer和Cat-home部署在一个JVM内部，每个CAT服务器既可以作为消费者，也可以作为家，这样不仅可以减少整个层次结构，还可以增加系统的稳定性 。
在实际的开发部署中，cat-consumer和cat-home部署在一个jvm内部，每个cat服务器既可以作为消费者，也可以作为家，这样不仅可以减少整个cat的层次结构，还可以增加整个系统的稳定性 。
上图是猫目前多机房的整体结构:
路由中心是根据应用所在机房信息来决定客户端上报的CAT服务端地址每个机房内部都有的独立的原始信息存储集群HDFScat-home可以部署在一个机房也可以部署在多个机房，在做报表展示的时候，cat-home会从cat-consumer中进行跨机房的调用，将所有的数据合并展示给用户实际过程中，cat-consumer、cat-home以及路由中心都是部署在一起，每个服务端节点都可以充当任何一个角色
(3)卡特彼勒客户端的设计
客户端设计是CAT系统设计中最重要的环节 。客户端的要求是API简单可靠，客户端在任何场景下都不能影响每个业务服务的性能(监控只是公司核心业务流程的一个旁路环节) 。下面的客户端设计和细节以java客户端为例 。
设计框架
客户端是java，客户端使用ThreadLocal来收集数据，这是一个线程本地变量，也可以称为线程本地存储 。其实ThreadLocal的作用很简单，就是为每个使用该变量的线程提供一份变量值的副本 。它是Java中一种特殊的线程绑定机制，每个线程都可以独立地改变自己的副本，而不会与其他线程的副本发生冲突 。
在监控场景下，提供给用户的服务都是web容器，如Tomcat或Jetty，后端rpc服务器如dubbo或pigeon，一个自研的点评服务框架，都是基于线程池实现的 。在处理业务逻辑时，业务端基本调用后端服务、数据库、缓存等 。在一个线程中，并将这些数据返回进行业务逻辑封装，最后将结果显示给用户 。因此，将所有监控请求作为监控上下文存储在线程变量中是非常合适的 。
当上述业务执行业务逻辑时，这个请求对应的监控会存储在线程上下文中，这实际上是一个监控树结构 。在业务线程执行结束时，被监视的对象存储在异步内存队列中，CAT中的一个消费者线程将队列中的数据异步发送到CAT服务器 。
API设计
当设计者对监控和性能分析有了深入的理解，他就可以定义监控API了 。监控和性能分析有以下几种情况 。
一段代码的执行时间，一段代码可以是URL执行耗时，也可以是SQL的执行耗时一段代码的执行次数，比如程序抛出异常记录次数，或者一段逻辑的执行次数定期执行某段代码，比如定期上报一些核心指标，jvm内存、gc等指标关键的业务监控指标，比如监控订单数、交易额、支付成功率等
在上述领域模型的基础上，CAT设计了几个自己的核心、事务、事件、心跳和度量的监控对象 。
分段监控API的代码示例如下
序列化和通信
序列化和通信是包括服务器在内的整个客户端性能的关键环节 。
CAT序列化协议是自定义序列化协议，自定义序列化协议相比通用序列化协议要高效很多，这个在大规模数据实时处理场景下还是非常有必要的 。CAT通信是基于Netty来实现的NIO的数据传输，Netty是一个非常好的NIO开发框架，在这边就不详细介绍 。
客户埋藏点
日志掩埋是监测活动中最重要的环节之一，日志的质量决定了监测的质量和效率 。CAT的埋目标是以问题为中心的，比如程序抛出的异常就是典型的问题 。我个人对问题的定义是，不符合预期的才算是问题 。比如请求没有完成，响应时间有快有慢，TPS请求数量过多过少，时间分布不均匀 。
在互联网环境下，典型的突出问题易发场景包括跨模块调用、跨公司调用等 。例如
HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL;搜索/查询引擎、业务应用、外包系统、遗留系统;第三方网关/银行, 合作伙伴/供应商之间；各类业务指标，如用户登录、订单数、支付状态、销售额 。
(4)服务器的设计
服务器端的主要问题是大数据的实时处理 。截至2017年6月，后端猫的计算集群约有100台物理机，存储集群约有50台物理机，每天处理约200TB的数据 。以下是卡特彼勒服务器的一些设计细节:
结构化
单服务器cat-consumer的总体架构如下:
如上图所示，CAT服务器在整个实时处理中基本实现了全异步处理 。
消息接收是基于Netty的NIO实现消息接收到服务端就存放内存队列，然后程序开启一个线程会消费这个消息做消息分发每个消息都会有一批线程并发消费各自队列的数据，以做到消息处理的隔离消息存储是先存入本地磁盘，然后异步上传到hdfs文件，这也避免了强依赖hdfs
当报表处理器来不及处理时，例如，事务报表处理速度很慢，可以通过配置支持启动多个事务处理线程，并且可以并发使用消息 。
实时分析
分析实时猫服务器实时报表分析是整个监控系统的核心 。在CAT中，客户端收集原始的Logview，目前每天大概有3000亿条消息，需要基于这些消息实现丰富的报表，以支持业务问题和性能分析的需求 。
根据CAT日志消息的特点(如只读特性)和问题场景，量身定制 。CAT会根据消息的创建时间，在一个小时内对所有报告进行切片，然后每小时生成一个报告 。当前每小时报告的所有计算都基于内存，每次用户请求即时报告时，都会获得最新的实时结果 。对于历史报表来说，因为是常量，所以实时与否并不重要 。
基本上，CAT的所有报表模型都可以进行增量计算 。可以分为计数、计时、关系处理三种 。计数可分为算术计数和集合计数两类 。典型的算术计数有:总数(count)、总和(sum)、平均值(avg)、最大值/最小值(max/min)、吞吐量(tps)和标准差(std)等 。其他的比较直观，标准差稍微复杂一点 。你可以自己推导出如何做增量计算 。然后集合操作，比如95行(代表95%请求的完成时间)和999行(代表99.9%请求的完成时间)，稍微复杂一点，系统开销也大一点 。
报表建模
每个CAT报告通常有多个维度 。以交易报告为例 。它有五个维度，即应用、机器、类型、名称和分钟级分布 。如果全维建模灵活，成本会很高 。选择卡特彼勒固定维度建模可以理解为将这五个维度组织成深度为5的树 。访问总是从根开始，一层一层往下 。
卡特彼勒服务器为每个报告分别分配一个线程，因此不会出现锁问题 。所有报表模型都是非线程安全的，并且它们的数据是可变的 。这具有简单和低成本的优点 。
利用自主开发的maven插件自动生成CAT报表建模 。所有报告都可以合并和裁剪，两个或更多的报告可以很容易地合并成一个报告 。在报告处理代码中，CAT大量使用了访问者模式 。
性能分析报告
故障发现报告
实时业务指标监控 ：核心业务都会定义自己的业务指标，这不需要太多，主要用于24小时值班监控，实时发现业务指标问题，图中一个是当前的实际值，一个是基准值，基准值是根据历史趋势计算的预测值 。如下图就是当时出故障，直观看到支付业务出问题的故障 。
系统报错大盘实时数据库大盘、服务大盘、缓存大盘等
存储设计
卡特彼勒系统中有两个主要的存储部分 。
CAT的报表的存储CAT原始logview的存储
报告是根据logview实时计算的用于业务分析的报告 。默认报告为小时模式、天模式、周模式和月模式 。卡特彼勒实时处理报告都生成每小时统计数据，每小时报告将包含最小分钟粒度的统计数据 。日、周、月和其他报告是每小时合并报告的结果 。
原始日志视图每天存储大约300TB的数据 。由于数据量大，存储必须压缩，需要根据messageId读取原始logview 。在这种情况下，存储的总体要求是批量压缩和随机读取 。当时还没有成熟的系统来支持这样的特性，所以我们开发了一个基于文件的存储来支持CAT，这一直是存储中最难的问题，我们也一直在不断的改进和优化 。
消息ID的设计
每个CAT消息都有一个惟一的ID，这个ID是在客户端生成的，后续的CAT通过这个ID搜索消息内容 。例如，在分布式调用中，RPC消息需要串在一起 。例如，当A调用B时，A端会生成一个MessageId 。在A呼叫B的过程中，MessageId作为一个调用传递到B端 。在B执行过程中，B使用context传递的MessageId作为当前监控消息的MessageId 。
猫报文的MessageId格式为ShopWeb-0a010680-375030-2，猫报文分为四段 。
第一段是应用名shop-web第二段是当前这台机器的ip的16进制格式，01010680表示10.1.6.108第三段的375030，是系统当前时间除以小时得到的整点数第四段的2，是表示当前这个客户端在当前小时的顺序递增号
存储数据的设计
存储消息是CAT最具挑战性的部分 。关键是消息数量多且大 。目前美团点评每天处理约3000亿条消息，大小约300TB，单个物理机每秒要处理约200MB流量 。CAT server根据这个流量进行实时计算，也需要对这些数据进行压缩并写入磁盘 。
整体存储结构如下
CAT数据文件分为两种，一种是索引文件，一种是数据文件 。
data文件是分段GZIP压缩，每个分段大小小于64K，这样可以用16bits可以表示一个最大分段地址一个MessageId都用需要48bits的空间大小来存索引，索引根据MessageId的第四段来确定索引的位置，比如消息MessageId为ShopWeb-0a010680-375030-2，这条消息ID对应的索引位置为2*48bits的位置48bits前面32bits存数据文件的块偏移地址，后面16bits存数据文件解压之后的块内地址偏移CAT读取消息的时候，首先根据MessageId的前面三段确定唯一的索引文件，在根据MessageId第四段确定此MessageId索引位置，根据索引文件的48bits读取数据文件的内容，然后将数据文件进行GZIP解压，在根据块内偏移地址读取出真正的消息内容 。
服务器设计总结
就卡特彼勒分布式实时而言，主要归结于以下因素:
去中心化，数据分区处理基于日志只读特性，以一个小时为时间窗口，实时报表基于内存建模和分析，历史报表通过聚合完成基于内存队列，全面异步化，单线程化，无锁设计全局消息ID，数据本地化生产，集中式存储组件化、服务化理念
以上内容主要来源于猫网站，详情可在网站上查询 。
呼叫链跟踪系统(3):空中漫步介绍Skywalking是国内开源爱好者吴声(前OneAPM工程师，目前在华为)开的，提交给Apache孵化器的产品 。还吸收了Zipkin/Pinpoint/CAT的设计思想，支持无创埋葬 。这是一个基于分布式跟踪的应用程序性能监控系统 。此外，社区还开发了一个名为OpenTracing的组织，旨在推广一些呼叫链监控的规范和标准 。
天行健项目的建立和发展在初期具有很大的偶然性 。天巡3.2之前的版本和后来的5.x、6.x版本在技术栈和设计上有巨大的差异，这就是原因 。2015年成立并开源的时候，SkyWalking是一个分布式系统的培训系统，用来辅助公司新员工学习分布式系统的复杂性，以及如何搭建监控系统 。天巡3.2.x是第一个里程碑版本，确立了以轻量级架构为核心的设计理念，彻底抛弃了HBase等大数据存储技术 。SkyWalking多语言探针协议1.0也是在那个时候建立的，并且一直得到SkyWalking的支持 。
2017年12月，SkyWalking成为中国首个入驻Apache孵化器的个人项目，充分体现了Apache对项目社区和项目未来的认可 。
2018年是项目快速发展的一年 。2018年，项目组发布了SkyWalking5，得到了华为、阿里巴巴等大厂的支持，初步开始大规模应用 。2018年底，天行社区迎来了第一个生态子项目——天行的 。NETCore Probe，标志着正式接受SkyWalkingTracing和Header协议，围绕这一协议开始了社区生态建设 。
2019年，为了迎合下一代分布式网络架构ServiceMesh，SkyWalking项目发布了新一代内核，版本升级为SkyWalking6 。SkyWalking6总结了前三年开源社区发展的经验、需求和未来规划 。通过大量的顶层设计，它以面向协议、轻量级和模块化为核心思想，为传统的探针监控和ServiceMesh提供了一致的解决方案 。
2020年，延续了SkyWalking6的大量特性和设计，社区推出了SkyWalking7，在某个特定的技术方向上进一步加强 。
SkyWalking是一个高度组件化的APM项目，用于微服务、集装箱化和分布式系统 。早在SOA开始兴起的2010年，应用系统开发者就注意到系统的调试过程变得越来越复杂 。当在线运行的程序出现故障时，使用传统日志进行故障排除很难找到它们所面临的问题 。之后，随着微服务的兴起，IOE和分布式架构的广泛采用，程序性能的监控和问题定位变得越来越迫切 。这就是天行项目诞生的起点 。受GoogleDapper论文的启发，SkyWalking整合了多位初创成员在APM和互联网公司的工作经验，建立了一套基于分布式跟踪的应用性能监控解决方案 。同时，根据中国大业务流和系统R&D团队的特点，天巡首次提出支持生产流环境下100%跟踪采样 。SkyWalking也是唯一提出这种支持的APM系统 。
(1)1)人行天桥的适用场景
天行者不是一个简单的跟踪系统 。
天巡首先是一个应用性能监控工具，它的目标是应用性能 。很多人将SkyWalking、Zipkin和Jaeger视为开源世界的竞争对手，但事实上，这三个社区的核心成员并不这么看 。SkyWalking具有在语言探测场景中自动化分布式跟踪的能力，但是这种能力服务于应用程序性能监控 。它提供了高性能的自动探测解决方案，并支持轻量级拓扑分析和性能指标应用等功能 。Zipkin和Jaeger都专注于追踪自己，获得尽可能详细的呼叫链，并建议在高流量时开始采样 。深入使用后，你会发现两个系统提供的跟踪结构差别很大 。
天巡不是基于大数据的APM系统 。
说到APM，就不得不推进APM项目Pinpoint，这个项目是韩国Naver公司在2012年开设的 。Pinpoint曾经是GitHubstar数量最多的APM项目，直到2019年被SkyWalking超越 。乍一看大家会觉得针尖和天行功能差不多 。毕竟都是在APM领域，但是两者采用的技术栈体现了本质的区别:Pinpoint基于HBase；SkyWalking使用包括Elasticsearch在内的多种存储，但不支持任何大数据技术 。
天巡在3版之后的版本中彻底抛弃了大数据技术栈 。根本原因在于，作为Ops的核心系统之一，轻便和灵活被放在了第一位 。天行是基于监控数千亿的流量 。而是不能成为整个大型分布式系统部署和运维的难点 。但是大数据技术适得其反，会大大增加运维和部署的难度 。
同时，SkyWalking在5000TPS以上下的超优秀表现也是和Pinpoint的一大区别 。无论是官方测试还是大量的网上性能对比，都能反映出巨大的差异 。在设计之初，SkyWalking还旨在确保探针能够在单进程10,000 TPS系统中提供稳定的100%采样和合理的性能消耗(增加不到10%) 。高起点也要求天巡能够完全掌控自己的技术栈和计算模型，这样才能完全满足APM计算的要求 。
除了类似的项目对比，还有一些核心应用场景可以帮助你理解天行 。
天行不是一个方法诊断系统 。
首先，从技术角度来说，方法级跟踪是天巡技术栈可以实现的技术，但政府并不推荐，尤其是在生产环境中 。方法级别
当然，SkyWalking考虑了不同团队的使用场景，在可选插件中提供了Spring托管类的方法级跟踪 。作为APM系统，SkyWalking不推荐使用新的span方法进行常规诊断，而是为生产环境的性能诊断提供了一种更高效、更合理的方式——性能分析 。
天行道可以跟踪方法参数 。
参数跟踪类似于方法跟踪 。甚至对于HTTP请求的方法参数追踪也会给应用系统和APM带来很大的压力 。目前天巡的部分插件(如MySQL)虽然支持用户手动开启参数跟踪，但还是提醒注意性能消耗 。此外，SkyWalking7还引入了新的性能诊断功能，方法参数将被自动捕获 。
(2)人行天桥建筑设计
天行官方架构图对天行的整体架构做了非常直观的描述 。天行道由以下四个核心部分组成 。
探针 。探针（对应图1-1中Tracing和Mestrics部分）可以是语言探针，也可以是其他项目的协议 。OAP平台（ObservabilityAnalysisPlatform），或称OAPServer 。它是一个高度组件化的轻量级分析程序，由兼容各种探针的Receiver、流式分析内核和查询内核三部分构成 。存储实现（StorageImplementors） 。SkyWalking的OAPServer支持多种存储实现，并且提供了标准接口，可以实现其他存储 。UI模块（SkyWalking） 。通过标准的GraphQL协议进行统计数据查询和展现 。
从设计的角度来看，天桥一般遵循以下三个设计原则:
面向协议设计模块化设计轻量化设计
高空漫步的优点
天行的优势在于紧跟当前技术发展趋势，确保同一个APM系统同时适用于传统架构和云原生架构 。此外，在技术设计理念上，天巡提供了更大的包容性和扩展性，适用于不同的用户场景和定制需求 。
传统架构和原生云之间的一致性支持
随着最近十年服务和微服务的进程，RPC和HTTP服务是通信技术的核心，registry是服务注册和服务发现的框架，已经成为国内成熟的微服务“传统”框架 。主流技术有SpringCloud、ApacheDubbo等 。SkyWalking自2015年项目诞生以来，就以这种传统的分布式架构和自动探头为核心功能 。天巡可以无缝支持稳定的分布式服务架构，在不增加运维团队和开发团队工作量的情况下，方便替代传统的监控方式 。
与此同时，自2018年以来，由谷歌、Lyft和CNCF的Istio和Envoy组成的ServiceMesh开始流行，在Kubernetes上提供创新的分布式服务管理、监控和安全管理能力 。SkyWalking项目组一直紧跟这一趋势，在Istio1.0.4的同时发布了SkyWalking6的测试版，三个月后开始发布SkyWalking6的稳定版 。在6.x版本中，SkyWalking为Istio和Envoy组成的ServiceMesh方案提供了核心适应性 。用户可以认为ServiceMesh构成了一种新的独立于语言的探测形式SkyWalking 。借助后端OAP平台和SkyWalking的UI，可以为ServiceMesh管理中的服务提供相同的依赖拓扑、服务性能指标、告警等能力 。90%以上的配置与使用其他语言的探针(如Java探针)时完全相同 。这也是第一个在开源软件中实现语言探针和ServiceMesh一致性解决方案的项目 。为不同公司的技术栈提供统一的监控能力，更有利于在未来的系统架构升级中保持监控系统的一致性 。
这种一致性不仅仅指天巡的使用，还包括用户在天巡中构建的生态系统的一致性，如报警平台、AIOps、指标基线计算系统、弹性计算等 。
易于维护
天巡始终坚持以易维护为核心需求，不引入过多的技术栈，以免成为过于复杂的监控系统 。这其中的深层逻辑在于，监控系统作为二线甚至三线系统，要利用有限的环境资源，提供尽可能多的监控价值，同时尽量降低对运维的要求 。在SkyWalking集群模式下，大量公司每天需要收集超过100亿级别的监控数据和细节 。天行不需要使用复杂的大数据平台，降低入门难度和维护负担 。同时，SkyWalking的集群架构相对简单 。用户只要具备根据自身数据量，针对不同存储平台(如MySQL、TiDB或Elasticsearch)的基本集群运维能力，就可以轻松监控数百亿流量系统 。
高性能的
SkyWalking并没有因为简单易维护而降低其性能要求 。SkyWalking内置了一个专门为分布式监控设计的可扩展流计算框架 。这个计算框架专门设计了监控数据的具体流程，并通过使用字节码技术，兼顾了可扩展性和系统性能 。
呼叫链跟踪系统比较分布式呼叫链跟踪系统通常有以下五个目标:
低消耗（low-overhead）调用链追踪埋点不能占用链路上太长的时间，也不应消耗太多的机器资源 。低侵入（low-invasiveness）作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，减少开发人员的负担和接入门槛 。可扩展（scalability）整个调用链追踪通路都应该可扩展，以应对不断接入的服务和公司未来的发展 。时效性（time-efficient）从追踪数据采集，分析处理，查询，展示的整个通路都要尽量快速 。决策支持（decision-support）需要为业务定位问题，分析服务，提供丰富清晰的报表 。
三种产品的对比如下表所示:
【avg变量的定义 avg什么意思】从上表可以看出，这三款产品都是优秀的呼叫链跟踪系统 。综合各方面考虑，比如公司和项目组开始选择一款产品作为通话链跟踪监控系统，Skywalking是一个不错的选择 。

    推荐阅读


    上一篇：37岁左右是男性最快乐时光 37岁男人应有的状态

    下一篇：自测是否脾虚 自测是否脾虚怎么测