调用链追踪系统在伴鱼：理论篇.docxVIP

调用链追踪系统在伴鱼：理论篇 Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin E. Conway 假如有一门学科叫软件社会学，那么康威定律 (Conway’s law) 必定是其中的基本定律之一。假如把互联网公司内部的全体信息系统看作是一整个系统，那么这个系统模块结构会向公司的组织架构收敛。从组织架构层面看，公司结构从扁平向多层级演化，信息传递的环节添加，沟通效率随之下降，进而影响公司的举动效率。不论从组员之间的生疏程度还是从部门目标全都性来看，部门内部的沟通效率要远远高于部门间的沟通效率。因而，假如系统模块结构与组织架构约趋近，公司的沟通效率就能接近极大值。团队的分化通常伴随着服务的拆分，这也是很多公司业务增长以后进行微服务化的动机。微服务化后，公司信息系统就被迫成为了分布式系统。虽然分布式系统带来了种种好处，如持续集成、增量部署、横向扩展、毛病隔离，但系统可观测性比起单机系统下降了很多，甚至几乎没有人能够对公司信息系统有全局性的了解。 任意一个分布式系统的终极抱负是：“给开发者以分布式的力量，单机的感受”。而调用链追踪系统就是实现终极抱负不行或缺的一部分。调用链追踪系统通过收集调用链数据，挂念开发者在观测分布式系统行为时，从以机器为中心 (machine-centric) 走向以恳求为中心 (workflow-centric)。调用链 (traces)、日志 (logs)、监控目标 (metrics)，三者合称 Telemetry，有了它们，微服务开发者既能通盘考虑，又能深化局部分析，在系统规模扩大的同时仍旧能够掌控全局。 使用场景 当系统的调用链信息被串联起来以后，开发者就能基于此开放各种方式的系统行为分析。常见的使用场景可以分为以下几类： 特别检测 特别检测指的是定位和排查一些引发系统特别行为的恳求，通常这些恳求的消灭频率很低。虽然特别大事被采样的概率很低，但它的信息熵大，能给到开发者更多细节信息。这些细节可能体现在：慢恳求、慢查询、循环调用未设上限、存在错误级别日志、未掩盖测试的问题规律分支等等。假如调用链追踪系统能自动为开发者发觉特别问题，将使得风险隐患提前暴露，并被扼宰在摇篮中。 稳态分析 稳态分析指的是分析微服务在正常流量下的各方面形态，分析粒度可能包括单个接口、单个服务、多个服务等等；分析范围可能是单个恳求或多个恳求；分析角度可能包括埋点目标、依靠关系、流量大小等等。稳态分析通常反映的是系统次要流程的健康形态，一些配置的改动，如存储节点修改、客户端日志上报频率，都可能反馈到系统稳态。稳态分析还可以有很多细分场景，如： 稳态功能分析：定位和排查系统稳态中的功能问题，这些问题的起因通常与特别检测类似，只是其影响尚不足以触发报警。 服务依靠分析：构建接口级别的依靠关系图，节点通常为接口或服务，边通常为接口或服务的调用关系，边的权重则为流量。构建方式可以分为离线构建和在线构建，对应的就是静态关系图和动态关系图。这些信息可以以基础 API 的方式供应应上游应用使用，如 APM。 分布式侧写 (profiling) 很多编程言语都供应侧写工具，如 go tool pprof，能通过采集不同资源的使用负载，如 CPU、内存、协程等，分析进程内部不同模块的资源使用模式，最终通过调用树或火焰图等可视化方式呈现给开发者。分布式侧写就是这类侧写工具的分布式版本，开发者通过打开侧写开关，采样分析一段时间，得到微服务之间的资源占用比例，如时延，然后通过类似单机的数据可视化方式分析接口或服务全体的功能瓶颈。 资源归因 资源归因解答的次要问题是：“谁该为我的服务成本买单？” 它需要将资源消耗或占用与恳求方关联，资源归因也是成本分析的基础。 负载建模 负载建模次要指分析和推想系统的行为表现，该场景解答的问题通常可以表述为 “假如消灭 XX 变化，系统全体或关键链路形态会发生什么转变？” 常见应用如容量预估、全链路压测、混沌测试等等。 基本实现方案 如何追踪调用链 在微服务架构下，每个调用链的信息散落在恳求经过的各个微服务中，这些信息需要通过某种技术手段收集并串联起来，重建出完整调用链。存在两种基本思路来处理问题，一种是无代码入侵的黑盒法 (blackbox)；另一种是有代码入侵的元数据传播法 (metadata propagation)。 黑盒法 黑盒法，顾名思义，就是将整个微服务集合看作一个黑盒，把特定格式的日志收集到存储中心后，利用统计方法推断、重建调用链： 这种方式