当前位置:首页 > 公众号精选 > 架构师社区
[导读]随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务

原文:https://www.jianshu.com/p/92a12de11f18


问题背景


随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要一些可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。
全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的Google Dapper[1]。想要在这个上下文中理解分布式系统的行为,就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。
所以,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示:

一个请求完整调用链
那么在业务规模不断增大、服务不断增多以及频繁变更的情况下,面对复杂的调用链路就带来一系列问题:
  • 如何快速发现问题?

  • 如何判断故障影响范围?

  • 如何梳理服务依赖以及依赖的合理性?

  • 如何分析链路性能问题以及实时容量规划?


同时我们会关注在请求处理期间各个调用的各项性能指标,比如:吞吐量(TPS)、响应时间及错误记录等。
  • 吞吐量,根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。

  • 响应时间,包括整体调用的响应时间和各个服务的响应时间等。

  • 错误记录,根据服务返回统计单位时间异常次数。


全链路性能监控从整体维度到局部维度展示各项指标,将跨应用的所有调用链性能信息集中展现,可方便度量整体和局部性能,并且方便找到故障产生的源头,生产上可极大缩短故障排除时间。
有了全链路监控工具,我们能够达到:
  • 请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。

  • 可视化:各个阶段耗时,进行性能分析。

  • 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。

  • 数据分析,优化链路:可以得到用户的行为路径,汇总分析应用在很多业务场景。


目标要求
如上所述,那么我们选择全链路监控组件有哪些目标要求呢?Google Dapper中也提到了,总结如下:
探针的性能消耗
APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
代码的侵入性
即也作为业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。
对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
可扩展性
一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API,对于一些没有监控到的组件,应用开发者也可以自行扩展。
数据的分析
数据的分析要快,分析的维度尽可能多。跟踪系统能提供足够快的信息反馈,就可以对生产环境下的异常状况做出快速反应。分析的全面,能够避免二次开发。
功能模块
一般的全链路监控系统,大致可分为四大功能模块:
埋点与生成日志
埋点即系统在当前节点的上下文信息,可以分为客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容TraceId、SpanId、调用的开始时间,协议类型、调用方IP和端口,请求的服务名、调用耗时,调用结果,异常信息等,同时预留可扩展字段,为下一步扩展做准备。
不能造成性能负担:一个价值未被验证,却会影响性能的东西,是很难在公司推广的!
因为要写log,业务QPS越高,性能影响越重。通过采样和异步log解决。
收集和存储日志
主要支持分布式日志采集的方案,同时增加MQ作为缓冲。
  • 每个机器上有一个Deamon做日志收集,业务进程把自己的Trace发到Daemon,Daemon把收集Trace往上一级发送;

  • 多级的Collector,类似pub/sub架构,可以负载均衡;

  • 对聚合的数据进行实时分析和离线存储;

  • 离线分析,需要将同一条调用链的日志汇总在一起。


分析和统计调用链路数据,以及时效性
调用链跟踪分析:把同一TraceID的Span收集起来,按时间排序就是timeline。把ParentID串起来就是调用栈。
抛异常或者超时,在日志里打印TraceID。利用TraceID查询调用链情况,定位问题。
依赖度量:
  • 强依赖:调用失败会直接中断主流程

  • 高度依赖:一次链路中调用某个依赖的几率高

  • 频繁依赖:一次链路调用同一个依赖的次数多

  • 离线分析:按TraceID汇总,通过Span的ID和ParentID还原调用关系,分析链路形态。

  • 实时分析:对单条日志直接分析,不做汇总,重组。得到当前QPS,延迟。


展现以及决策支持
Google Dapper
Span
基本工作单元,一次链路调用(可以是RPC,DB等没有特定的限制)创建一个Span,通过一个64位ID标识它,uuid较为方便,Span中还有其他的数据,例如描述信息,时间戳,key-value对的(Annotation)tag信息,parent_id等,其中parent-id可以表示Span调用链路来源。

Span
上图说明了Span在一次大的跟踪过程中是什么样的。Dapper记录了Span名称,以及每个Span的ID和父ID,以重建在一次追踪过程中不同Span之间的关系。如果一个Span没有父ID被称为root span。所有Span都挂在一个特定的跟踪上,也共用一个跟踪ID。
Span数据结构:
			
			

type Span struct {     TraceID    int64 // 用于标示一次完整的请求ID     Name       string     ID         int64 // 当前这次调用span_id     ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null     Annotation []Annotation // 用于标记的时间戳     Debug      bool } Trace 类似于树结构的Span集合,表示一次完整的跟踪,从请求到服务器开始,服务器返回response结束,跟踪每次RPC调用的耗时,存在唯一标识trace_id。比如:你运行的分布式大数据存储一次Trace就由你的一次请求组成。

Trace
每种颜色的note标注了一个Span,一条链路通过TraceId唯一标识,Span标识发起的请求信息。树节点是整个架构的基本单元,而每一个节点又是对Span的引用。节点之间的连线表示的Span和它的父Span直接的关系。虽然Span在日志文件中只是简单的代表Span的开始和结束时间,他们在整个树形结构中却是相对独立的。
Annotation
注解,用来记录请求特定事件相关信息(例如时间),一个Span中会有多个annotation注解描述。通常包含四个注解信息:
  • cs:Client Start,表示客户端发起请求

  • sr:Server Receive,表示服务端收到请求

  • ss:Server Send,表示服务端完成处理,并将结果发送给客户端

  • cr:Client Received,表示客户端获取到服务端返回信息


Annotation数据结构:
   type Annotation struct {
    
    Timestamp int64
    
    Value     string
    
    Host      Endpoint
    
    Duration  int32
    
} 调用示例 请求调用示例: 
  • 当用户发起一个请求时,首先到达前端A服务,然后分别对B服务和C服务进行RPC调用;

  • B服务处理完给A做出响应,但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务,最后由A服务来响应用户的请求。


请求调用示例
调用过程追踪:
  • 请求到来生成一个全局TraceID,通过TraceID可以串联起整个调用链,一个TraceID代表一次请求。

  • 除了TraceID外,还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id,通过他们可以组织一次完整调用链的父子关系。

  • 一个没有parent id的span成为root span,可以看成调用链入口。

  • 所有这些ID可用全局唯一的64位整数表示。

  • 整个调用过程中每个请求都要透传TraceID和SpanID。

  • 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下,并且将自己生成的SpanID也记录下。

  • 要查看某次完整的调用则只要根据TraceID查出所有调用记录,然后通过parent id和span id组织起整个调用父子关系。


整个调用过程追踪
调用链核心工作:
  • 调用链数据生成,对整个调用过程的所有应用进行埋点并输出日志。

  • 调用链数据采集,对各个应用中的日志数据进行采集。

  • 调用链数据存储及查询,对采集到的数据进行存储,由于日志数据量一般都很大,不仅要能对其存储,还需要能提供快速查询。

  • 指标运算、存储及查询,对采集到的日志数据进行各种指标运算,将运算结果保存起来。

  • 告警功能,提供各种阀值警告功能。


整体部署架构:

整体部署架构
  • 通过Agent生成调用链日志。

  • 通过Logstash采集日志到Kafka。

  • Kafka负责提供数据给下游消费。

  • storm计算汇聚指标结果并落到ES。

  • storm抽取trace数据并落到ES,这是为了提供比较复杂的查询。比如通过时间维度查询调用链,可以很快查询出所有符合的traceID,根据这些traceID再去Hbase查数据就快了。

  • Logstash将Kafka原始数据拉取到HBase中。HBase的rowkey为traceID,根据traceID查询是很快的。


Agent无侵入部署:
通过Agent代理无侵入式部署,将性能测量与业务逻辑完全分离,可以测量任意类的任意方法的执行时间,这种方式大大提高了采集效率,并且减少运维成本。根据服务跨度主要分为两大类AGENT:
  • 服务内Agent,这种方式是通过Java的Agent机制,对服务内部的方法调用层次信息进行数据收集,如方法调用耗时、入参、出参等信息。

  • 跨服务Agent,这种情况需要对主流RPC框架以插件形式提供无缝支持。并通过提供标准数据规范以适应自定义RPC框架:

    • Dubbo支持;

    • Rest支持;

    • 自定义RPC支持。


调用链监控好处:
  • 准确掌握生产一线应用部署情况;

  • 从调用链全流程性能角度,识别对关键调用链,并进行优化;

  • 提供可追溯的性能数据,量化IT运维部门业务价值;

  • 快速定位代码性能问题,协助开发人员持续性的优化代码;

  • 协助开发人员进行白盒测试,缩短系统上线稳定期。


方案比较
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文,本文重点关注以下三种APM组件:
  • Zipkin:由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:数据的收集、存储、查找和展现。

  • Pinpoint:一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪组件。

  • Skywalking:国产的优秀APM组件,是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。


以上三种全链路监控方案需要对比的项提炼出来:
  • 探针的性能,主要是Agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。

  • Collector的可扩展性,能够水平扩展以便支持大规模服务器集群。

  • 全面的调用链路数据分析,提供代码级别的可见性以便轻松定位失败点和瓶颈。

  • 对于开发透明,容易开关,添加新功能而无需修改代码,容易启用或者禁用。

  • 完整的调用链应用拓扑,自动检测应用拓扑,帮助你搞清楚应用的架构。


探针的性能
比较关注探针的性能,毕竟APM定位还是工具,如果启用了链路监控组建后,直接导致吞吐量降低过半,那也是不能接受的。对Skywalking、Zipkin、Pinpoint进行了压测,并与基线(未使用探针)的情况进行了对比。
选用了一个常见的基于Spring的应用程序,他包含Spring Boot,Spring MVC,Redis客户端,MySQL。监控这个应用程序,每个Trace,探针会抓取5个Span(1 Tomcat,1 Spring MVC,2 Jedis,1 MySQL)。这边基本和SkywalkingTest的测试应用差不多。
模拟了三种并发用户:500,750,1000。使用JMeter测试,每个线程发送30个请求,设置思考时间为10ms。使用的采样率为1,即100%,这边与生产可能有差别。Pinpoint默认的采样率为20,即5%,通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来,一共有12种。下面看下汇总表:

探针性能对比
从上表可以看出,在三种链路监控组件中,Skywalking的探针对吞吐量的影响最小,Zipkin的吞吐量居中。Pinpoint的探针对吞吐量的影响较为明显,在500并发用户时,测试服务的吞吐量从1385降低到774,影响很大。然后再看下CPU和memory的影响,在内部服务器进行的压测,对CPU和memory的影响都差不多在10%之内。
Collector的可扩展性
Collector的可扩展性,使得能够水平扩展以便支持大规模服务器集群。
Zipkin:
开发zipkin-Server(其实就是提供的开箱即用包),zipkin-agent与zipkin-Server通过http或者MQ进行通信,http通信会对正常的访问造成影响,所以还是推荐基于mq异步方式通信,zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的,多个zipkin-Server实例进行异步消费MQ中的监控信息。

Zipkin
Skywalking:
Skywalking的Collector支持两种部署方式:单机和集群模式。Collector与Agent之间的通信使用了gRPC。
Pinpoint:
同样,Pinpoint也是支持集群和单机部署的。pinpoint agent通过Thrift通信框架,发送链路信息到Collector。
全面的调用链路数据分析
全面的调用链路数据分析,提供代码级别的可见性以便轻松定位失败点和瓶颈。
Zipkin:

Zipkin链路调用分析
Zipkin的链路监控粒度相对没有那么细,从上图可以看到调用链中具体到接口级别,再进一步的调用信息并未涉及。
Skywalking:

Skywalking链路调用分析
Skywalking 还支持20+的中间件、框架、类库,比如:主流的Dubbo、Okhttp,还有DB和消息中间件。上图Skywalking链路调用分析截取的比较简单,网关调用user服务,由于支持众多的中间件,所以Skywalking链路调用分析比Zipkin完备些。
Pinpoint:

Pinpoint链路调用分析
Pinpoint应该是这三种APM组件中,数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈,上图可以看到对于执行的SQL语句,都进行了记录。还可以配置报警规则等,设置每个应用对应的负责人,根据配置的规则报警,支持的中间件和框架也比较完备。
对于开发透明,容易开关
对于开发透明,容易开关,添加新功能而无需修改代码,容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。
对于这一点,Zipkin使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是,它要求在需要时修改代码。Skywalking和Pinpoint都是基于字节码增强的方式,开发人员不需要修改代码,并且可以收集到更多精确的数据因为有字节码中的更多信息。
完整的调用链应用拓扑
自动检测应用拓扑,帮助你搞清楚应用的架构。

Pinpoint链路拓扑

Skywalking链路拓扑

Zipkin链路拓扑
上面三幅图,分别展示了APM组件各自的调用拓扑,都能实现完整的调用链应用拓扑。相对来说,Pinpoint界面显示的更加丰富,具体到调用的DB名,Zipkin的拓扑局限于服务于服务之间。
Pinpoint与Zipkin细化比较
Pinpoint与Zipkin差异性:
  • Pinpoint是一个完整的性能监控解决方案:有从探针、收集器、存储到Web界面等全套体系;而Zipkin只侧重收集器和存储服务,虽然也有用户界面,但其功能与Pinpoint不可同日而语。反而Zipkin提供有Query接口,更强大的用户界面和系统集成能力,可以基于该接口二次开发实现。

  • Zipkin官方提供有基于Finagle框架(Scala语言)的接口,而其他框架的接口由社区贡献,目前可以支持Java、Scala、Node、Go、Python、Ruby和C#等主流开发语言和框架;但是Pinpoint目前只有官方提供的Java Agent探针,其他的都在请求社区支援中(请参见#1759[2]和#1760[3])。

  • Pinpoint提供有Java Agent探针,通过字节码注入的方式实现调用拦截和数据收集,可以做到真正的代码无侵入,只需要在启动服务器的时候添加一些参数,就可以完成探针的部署;而Zipkin的Java接口实现Brave,只提供了基本的操作API,如果需要与框架或者项目集成的话,就需要手动添加配置文件或增加代码。

  • Pinpoint的后端存储基于HBase,而Zipkin基于Cassandra。


Pinpoint与Zipkin相似性:
Pinpoint与Zipkin都是基于Google Dapper的那篇论文,因此理论基础大致相同。两者都是将服务调用拆分成若干有级联关系的Span,通过SpanId和ParentSpanId来进行调用关系的级联;最后再将整个调用链流经的所有的Span汇聚成一个Trace,报告给服务端的Collector进行收集和存储。
即便在这一点上,Pinpoint所采用的概念也不完全与那篇论文一致。比如他采用TransactionId来取代TraceId,而真正的TraceId是一个结构,里面包含了TransactionId,SpanId和ParentSpanId。而且Pinpoint在Span下面又增加了一个SpanEvent结构,用来记录一个Span内部的调用细节(比如具体的方法调用等等),因此Pinpoint默认会比Zipkin记录更多的跟踪数据。但是理论上并没有限定Span的粒度大小,所以一个服务调用可以是一个Span,那么每个服务中的方法调用也可以是个Span,这样的话,其实Brave也可以跟踪到方法调用级别,只是具体实现并没有这样做而已。
字节码注入vs API调用:
Pinpoint实现了基于字节码注入的Java Agent探针,而Zipkin的Brave框架仅仅提供了应用层面的API,但是细想问题远不那么简单。字节码注入是一种简单粗暴的解决方案,理论上来说无论任何方法调用,都可以通过注入代码的方式实现拦截,也就是说没有实现不了的,只有不会实现的。但Brave则不同,其提供的应用层面的API还需要框架底层驱动的支持,才能实现拦截。比如,MySQL的JDBC驱动,就提供有注入interceptor的方法,因此只需要实现StatementInterceptor接口,并在Connection String中进行配置,就可以很简单的实现相关拦截;而与此相对的,低版本的MongoDB的驱动或者是Spring Data MongoDB的实现就没有如此接口,想要实现拦截查询语句的功能,就比较困难。
因此在这一点上,Brave是硬伤,无论使用字节码注入多么困难,但至少也是可以实现的,但是Brave却有无从下手的可能,而且是否可以注入,能够多大程度上注入,更多的取决于框架的API而不是自身的能力。
难度及成本:
经过简单阅读Pinpoint和Brave插件的代码,可以发现两者的实现难度有天壤之别。在都没有任何开发文档支撑的前提下,Brave比Pinpoint更容易上手。Brave的代码量很少,核心功能都集中在brave-core这个模块下,一个中等水平的开发人员,可以在一天之内读懂其内容,并且能对API的结构有非常清晰的认识。
Pinpoint的代码封装也是非常好的,尤其是针对字节码注入的上层API的封装非常出色,但是这依然要求阅读人员对字节码注入多少有一些了解,虽然其用于注入代码的核心API并不多,但要想了解透彻,恐怕还得深入Agent的相关代码,比如很难一目了然的理解addInterceptor和addScopedInterceptor的区别,而这两个方法就是位于Agent的有关类型中。
因为Brave的注入需要依赖底层框架提供相关接口,因此并不需要对框架有一个全面的了解,只需要知道能在什么地方注入,能够在注入的时候取得什么数据就可以了。就像上面的例子,我们根本不需要知道MySQL的JDBC Driver是如何实现的也可以做到拦截SQL的能力。但是Pinpoint就不然,因为Pinpoint几乎可以在任何地方注入任何代码,这需要开发人员对所需注入的库的代码实现有非常深入的了解,通过查看其MySQL和Http Client插件的实现就可以洞察这一点,当然这也从另外一个层面说明Pinpoint的能力确实可以非常强大,而且其默认实现的很多插件已经做到了非常细粒度的拦截。
针对底层框架没有公开API的时候,其实Brave也并不完全无计可施,我们可以采取AOP的方式,一样能够将相关拦截注入到指定的代码中,而且显然AOP的应用要比字节码注入简单很多。
以上这些直接关系到实现一个监控的成本,在Pinpoint的官方技术文档中,给出了一个参考数据。如果对一个系统集成的话,那么用于开发Pinpoint插件的成本是100,将此插件集成入系统的成本是0;但对于Brave,插件开发的成本只有20,而集成成本是10。从这一点上可以看出官方给出的成本参考数据是5:1。但是官方又强调了,如果有10个系统需要集成的话,那么总成本就是10 * 10 + 20 = 120,就超出了Pinpoint的开发成本100,而且需要集成的服务越多,这个差距就越大。
通用性和扩展性:
很显然,这一点上Pinpoint完全处于劣势,从社区所开发出来的集成接口就可见一斑。
Pinpoint的数据接口缺乏文档,而且也不太标准(参考论坛讨论帖),需要阅读很多代码才可能实现一个自己的探针(比如Node的或者PHP的)。而且团队为了性能考虑使用了Thrift作为数据传输协议标准,比起HTTP和JSON而言难度增加了不少。
社区支持:
这一点也不必多说,Zipkin由Twitter开发,可以算得上是明星团队,而Naver的团队只是一个默默无闻的小团队(从#1759[2]的讨论中可以看出)。虽然说这个项目在短期内不太可能消失或停止更新,但毕竟不如前者用起来更加放心。而且没有更多社区开发出来的插件,让Pinpoint只依靠团队自身的力量完成诸多框架的集成实属困难,而且他们目前的工作重点依然是在提升性能和稳定性上。
其他:
Pinpoint在实现之初就考虑到了性能问题,www.naver.com网站的后端某些服务每天要处理超过200亿次的请求,因此他们会选择Thrift的二进制变长编码格式、而且使用UDP作为传输链路,同时在传递常量的时候也尽量使用数据参考字典,传递一个数字而不是直接传递字符串等等。这些优化也增加了系统的复杂度:包括使用Thrift接口的难度、UDP数据传输的问题、以及数据常量字典的注册问题等等。
相比之下,Zipkin使用熟悉的Restful接口加JSON,几乎没有任何学习成本和集成难度,只要知道数据传输结构,就可以轻易的为一个新的框架开发出相应的接口。
另外Pinpoint缺乏针对请求的采样能力,显然在大流量的生产环境下,不太可能将所有的请求全部记录,这就要求对请求进行采样,以决定什么样的请求是我需要记录的。Pinpoint和Brave都支持采样百分比,也就是百分之多少的请求会被记录下来。但是,除此之外Brave还提供了Sampler接口,可以自定义采样策略,尤其是当进行A/B测试的时候,这样的功能就非常有意义了。
总结:
从短期目标来看,Pinpoint确实具有压倒性的优势:无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的Java框架支持。但是长远来看,学习Pinpoint的开发接口,以及未来为不同的框架实现接口的成本都还是个未知数。相反,掌握Brave就相对容易,而且Zipkin的社区更加强大,更有可能在未来开发出更多的接口。在最坏的情况下,我们也可以自己通过AOP的方式添加适合于我们自己的监控代码,而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候,Pinpoint官方提供的报表是否能满足要求也不好说,增加新的报表也会带来不可以预测的工作难度和工作量。
Tracing和Monitor区别



Monitor可分为系统监控和应用监控。系统监控比如CPU,内存,网络,磁盘等等整体的系统负载的数据,细化可具体到各进程的相关数据。这一类信息是直接可以从系统中得到的。应用监控需要应用提供支持,暴露了相应的数据。比如应用内部请求的QPS,请求处理的延时,请求处理的error数,消息队列的队列长度,崩溃情况,进程垃圾回收信息等等。Monitor主要目标是发现异常,及时报警。
Tracing的基础和核心都是调用链。相关的Metric大多都是围绕调用链分析得到的。Tracing主要目标是系统分析。提前找到问题比出现问题后再去解决更好。Tracing和应用级的Monitor技术栈上有很多共同点。都有数据的采集,分析,存储和展式。只是具体收集的数据维度不同,分析过程不一样。

免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
换一批
延伸阅读

非地面网络(NTN)是 3GPP Rel-17 的一项功能,支持通过卫星实现蜂窝通信,为全球偏远地区提供安全、可靠的大带宽网络覆盖。NTN 最早支持的技术是窄带物联网(NB-IoT),它实现了很多新的使用场景,例如资产跟...

关键字: 物联网 非地面网络 链路

千兆多媒体串行链路™ (GMSL™)和千兆以太网(GigE)是相机应用中两种流行的链路技术,常见于不同的终端市场。本文对两种技术的系统架构、关键特性和局限性进行了比较分析。这将有助于解释这两种技术的基本原理,并深入了解为...

关键字: 以太网 链路

摘要:工业APP对工业知识经验的软件化和复用,对工业的数字化、智能化转型起到关键作用。现分析总结了工业APP集成的四类场景,基于四类场景的特点提出了相应的工业APP集成架构,为平台、服务商、企业等各类主体开展工业APP汇...

关键字: 集成 资源汇聚 微服务

链路是指网络中链接两个节点的线路或信道。链路协议是指通过链路传送数据的一套规则,其中包括建立、维持和断开链路的规则,还包括在链路上传送数据的控制信息格式,以及对控制信息进行解释的规则。

关键字: 链路 差错控制 链路协议

互联网系统为大量的C端用户提供服务,如果隔三差五的出问题宕机,会严重影响用户体验,甚至导致用户流失。

关键字: 微服务 互联网 系统稳定性

使用微服务网关作为微服务面向客户端的单一入口,是目前普遍采用的微服务架构模式。

关键字: 微服务 网关 Nginx

本文主要为大家介绍微服务测试:基于服务契约信息,降低云上微服务测试成本。

关键字: 微服务 微服务测试 EDAS

HTTP service:HTTP服务提供商,本文中简称"服务提供商"。

关键字: 微服务 安全认证 企业级

作为微服务架构的忠心拥趸,虽然有时也会对其感到不爽。

关键字: 微服务 心得体会 架构师

当企业应用系统逐渐增多后,每个系统单独管理各自的用户数据容易形成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进。

关键字: 微服务 安全认证 实践
关闭
关闭