淘宝-分布式调用跟踪系统介绍
淘宝技术架构分享
，HSF 使用的时候需要单独的下载一个hsf.sar 文件放置到jboss 的
；弊端也很明显：增加了环境的复杂度，需要往jboss 下扔sar
设计的主要原因。HSF 工作原理如下图：
HSF SAR 文件到Jboss 的Deploy 目录。
大型分布式的基础支撑。使开发人员无需过多的关注应用是集中式的，还是分布式的，可以更加专注于应用的业务需求的实现，这些纯技术
的需求都由HSF 来解决。
（2）HSF 的系统架构
I. HSF 交互场景图
客户端（消费端）从配置中心获取服务端地址列表—>和服务端建立连接开始远程调用—>服务端更新通过notify（类似B2B 的naplio）
系统通知客户端。服务端和客户端都有对应的监控中心，实时监控服务状态。客户端，配置中心，服务端，notify，之间的通信都是通过TB Remotion
API 去搞定的。
II. TB Remoting 架构图
底层基于分布式框架Mina，主要的代码都是通过
B2B 的Dubbo 也是基于这个NIO 框架的。Mina
商品，付款，确认，退款，评价，社区互动等。
产品：淘宝对产品定义和B2B 有差别，淘宝的业务拆分较细，服务化做的较成熟，所以前台应用对应的业务非常纯粹，如Detail 系统可
能就一个detail 页面，无数据库连接，所有数据来自底层的各种服务化中心，功能专一逻辑清晰纯粹，不过也正因为这样，淘宝的一个产品
淘宝前端应用
HSF接口
UIC IC SC TC
PC
Forest 推送给“淘宝前端应用”
淘宝共享服务
(软件工程理论、方法与实践)第8章分布式系统体系结构
基于服务的架构设计方法
总结词
基于服务的架构设计方法是一种以服务为中心的设计方法，通过将系统功能封装为可复用的服务，实 现松耦合的分布式系统。
详细描述
01
02
分布式性
组件分布在不同的物理节点上，可以 位于不同的地理位置。
03
通信能力
组件之间通过通信进行协调和交互。
可靠性
分布式系统具有容错性和可恢复性， 能够保证系统的可靠运行。
05
04
并发性
多个组件可以并行执行，提高系统的 整体性能。
分布式系统的应用场景
云计算平台
如亚马逊AWS、谷歌云等，提供计算、存储、网络等 服务。
总结词
基于代理的分布式系统通过使用智能 代理来处理分布式任务，具有自治性、 智能性和协作性等特点。
详细描述
基于代理的分布式系统案例包括：1. 分布式 计算市场案例，如网格计算和云计算平台， 通过智能代理实现资源的共享和交易；2. 智 能家居案例，通过智能代理实现家庭设备的 互联和控制，提高生活便利性。
运维
分布式系统的运维需要关注系统的运行状态 和性能，以及服务的可用性和可靠性。这需
要使用一些监控工具和技术，如 Prometheus、Grafana等，以便及时发现 和处理系统中的问题。同时，还需要建立完 善的运维流程和规范，以确保系统的高可用
性和高可靠性。
05
分布式系统案例分析
基于代理的分布式系统案例
测试方法
对于分布式系统的测试，需要采用一些特定 的方法，如模拟测试、灰度测试、故障注入 测试等。这些方法可以帮助开发人员模拟各 种实际运行场景，以便更好地发现和修复系 统中的问题。
鹰眼下的淘宝 - 阿里技术沙龙
分布式 文件系统
43
埋点和输出日志
• 输出日志时面临的挑战
– 减少对业务线程的影响，降低资源消耗
– 每个网络请求至少 1 行日志，QPS 越高日志产生越快
45
埋点和输出日志
• 解决方案：自己实现日志输出
– 异步线程写日志
– 对调用链做采样
– 开关控制 – 对服务等长字符串做编码
– 日志输出缓存，限制 IO 次数，每秒刷新
2%
小于 100ms 100-500ms
– 非正常的瓶颈
• 弱依赖异常导致 主流程耗时过长
27% 68%
500-1000ms
超过 1000ms
26
链路分析
• 调用并行度
– 为链路并行、异步优化提供参考
并行度：0%
并行度 1
实际执行时间 本地执行时间 直接子依赖执行时间
并行度：36%
27
[2013-05-01 16:42:58] 鲁A123BC,济南3,G20,济南,￥25 ……
* 上述内容仅作举例示意说明用，纯属虚构
7
举个例子
• 可以分析车辆 鲁A123BC 的行驶路线
– [05-01 12:23:34] 平度2，旅途开始
↓
– [05-01 13:38:29] 青州西1，耗时 75 分钟，路费 10 元 ↓
– 核心：调用链。每次请求都生成 一个全局唯一的ID（TraceId）， 通过它将不同系统的“孤立的” 日志串在一起，重组还原出更多 有价值的信息
* 《三国杀》铁索连环卡牌版权归游卡桌游 (Yoka Games) 所有 9
简介
• 目前状况
– 每日调用链上 1 千亿，来自 500 多个前端，500 多个后端应用， 还有数百个数据库、缓存、存储，分析的日志超过 3 千亿行
淘宝分布式服务框架
HSF演进过程
• 配置使用方式的改进
– 使用示例
<bean id=“helloWorld” class=“com.taobao.hsf.test.HelloWorldImpl” />
HSF演进过程
• 发布服务
HSF演进过程
• 演进过程中的一些小功能
– 服务动态归组 – 服务限流 – 服务延迟注册 – 服务调用上下文支持 – Rpc框架与业务交互（常见如：remotehost） – 服务NDI方式调用 – 运行期动态发布数据 – 服务降级 – Jar包升级
– 业务层
问题
QA？
服务治理
• 服务监控
– 安全监控 – 报警 – 问题定位
分布式跟踪系统
• 类似google的dapper， Twi^er Zipkin • 基于tcp方式，h^p方式支持但是未全局推广
分布式跟踪系统
分布式跟踪系统
• 分布式跟踪系统链路图
QOS
协议层
容 器 接 入 层
核心服务层
HSF运行原理
Ip地址为 192.168.1.2的机器 提供了A服务 好的，A服务地址： 192.168.1.2 , 我要订阅A服务，把 192.168.1.3 A服务的地址给我吧 Ip地址为 192.168.1.3的机器 提供了A服务 谢谢，我会根据相 应规则选择一台机 器发起调用的。
HSF演进过程
• 部署及隔离方式改进
– 与应用分开部署，运行期依赖 – 外部采用与应用独立的classloader隔离，内部采 用OSGI隔离
• 优点vs缺点？
HSF演进过程
• 网络通讯改进
– 基于mina封装TB-‐Remo8ng – 分阶段序列化（java，hessian） – 连接采用长连接
淘宝高并发解决方案
概述淘宝是中国最大的电商网站之一，每天有数以亿计的用户访问淘宝平台。
在高并发的访问环境下，如何保证淘宝的稳定性和可用性是一个重要的挑战。
本文将介绍淘宝高并发解决方案，包括架构设计、缓存优化、数据库优化以及负载均衡。
架构设计淘宝采用了分布式架构来应对高并发的访问压力。
整个系统被划分为多个服务模块，每个模块独立运行，并通过消息队列进行通信。
这种架构设计可以有效地提高系统的可伸缩性和可扩展性。
缓存优化为了减轻数据库的压力，淘宝采用了大量的缓存来加速数据访问。
其中，最核心的缓存技术是利用Redis来缓存热点数据。
通过将频繁访问的数据放入Redis缓存中，可以大大提高系统的响应速度和吞吐量。
淘宝还利用CDN（内容分发网络）来缓存静态资源，例如商品图片、CSS文件和JavaScript文件。
CDN可以将这些静态资源缓存在全球各地的节点上，用户可以就近访问这些缓存节点，从而提高访问速度。
数据库优化淘宝使用了分布式数据库来处理海量的数据。
数据库采用主从复制的方式，将读写操作分散到多个数据库节点上，从而提高数据库的并发处理能力。
为了减少数据库查询的负载，淘宝采用了数据库分库分表的技术。
将数据按照一定的规则分散到多个数据库和表中，从而均衡数据库的负载，并且降低了单个数据库的数据量和并发访问量。
此外，淘宝还采用了数据库的读写分离技术。
将读操作和写操作分别路由到不同的数据库节点上，从而提高数据库的读写性能。
负载均衡淘宝使用了负载均衡技术来分发用户的请求，以实现高并发的访问。
主要的负载均衡技术包括DNS负载均衡和反向代理负载均衡。
DNS负载均衡将用户的请求解析到多个服务器的IP地址上，从而使得用户的请求被均衡地分发到不同的服务器上。
反向代理负载均衡则是通过将用户的请求发送到多个反向代理服务器上，由反向代理服务器再将请求分发给后端的多个应用服务器。
这样可以均衡地分担用户的请求压力，提高系统的并发处理能力。
总结淘宝面临着海量用户的高并发访问压力，为了保证系统的稳定性和可用性，需要在架构设计、缓存优化、数据库优化和负载均衡等方面进行优化。
分布式链路追踪原理
分布式链路追踪原理分布式链路追踪（Distributed Tracing）是指通过在分布式系统中收集、处理和汇总信息，来理解和追踪请求的路径和性能。
在微服务架构下，每个服务都可能有多个实例，请求在多个服务之间相互传递，每个服务的实例又可能分布在不同的物理机器或容器中。
因此，对于故障的排查和分析，需要了解整个请求的流程，并明确每个服务各自的响应时间、延迟和错误等信息。
分布式链路追踪的原理主要包括以下几个方面。
1. 请求追踪的数据模型分布式链路追踪通过将每个请求映射为一个唯一的跟踪号（TraceId），并通过这个跟踪号将各个服务中的请求串联起来。
在每个服务中，可以将每个请求拆成一系列的步骤（Span），每个步骤记录这个请求在该服务中的处理时间和结果等信息。
一般来说，一个请求可能包含多个跨服务的Span，每个Span之间有父子关系。
所有的Span数据都会被汇总到一个可视化的界面中，方便用户进行分析。
2. 链路追踪的实现方式实现分布式链路追踪，需要在每个服务中嵌入一个TracingClient库，并配置所需的中心化服务（比如Zipkin、Jaeger等）以收集和分析数据。
在每个服务中，Tracing Client库会创建和记录Span，并将这些信息发送到中心化服务。
在中心化服务中，将所有收到的数据进行聚合和分析，生成跨服务的请求流程和各个服务的性能数据等。
3. 链路追踪的标准化格式为了不同链路追踪系统之间的互通和对接，需要采用统一的数据格式。
目前已涌现出一些开源的分布式链路追踪标准，比较流行的有OpenTracing和OpenCensus等，它们主要规定了数据模型、API接口和语义等。
另外，阿里巴巴的EagleEye也推出了一套链路追踪标准，并提供了相应的Java和Go语言的SDK。
4. 实践经验和最佳实践在实践中，为了提高链路追踪的精度和实用性，应该注意以下几点：（1）定义良好的Span名称，以方便理解和分析服务之间的交互。
你刚才在淘宝上买了一件东西【技术普及贴】
你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了。
这时你的浏览器首先查询DNS服务器，将转换成ip地址。
不过首先你会发现，你在不同的地区或者不同的网络（电信、联通、移动）的情况下，转换后的ip地址很可能是不一样的，这首先涉及到负载均衡的第一步，通过DNS解析域名时将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个(这和后文的CDN 不一样)。
你通过这个入口成功的访问了的实际的入口ip地址。
这时你产生了一个PV，即Page View，页面访问。
每日每个网站的总PV量是形容一个网站规模的重要指标。
淘宝网全网在平日(非促销期间)的PV大概是16-25亿之间。
同时作为一个独立的用户，你这次访问淘宝网的所有页面，均算作一个UV（Unique Visitor用户访问）。
最近臭名昭著的的日PV量最高峰在10亿左右，而UV量却远小于淘宝网十余倍，这其中的原因我相信大家都会知道。
因为同一时刻访问的人数过于巨大，所以即便是生成淘宝首页页面的服务器，也不可能仅有一台。
仅用于生成首页的服务器就可能有成百上千台，那么你的一次访问时生成页面给你看的任务便会被分配给其中一台服务器完成。
这个过程要保证公正、公平、平均(暨这成百上千台服务器每台负担的用户数要差不多)，这一很复杂的过程是由几个系统配合完成，其中最关键的便是LVS，Linux Virtual Server，世界上最流行的负载均衡系统之一，正是由目前在淘宝网供职的章文嵩博士开发的。
经过一系列复杂的逻辑运算和数据处理，用于这次给你看的淘宝网首页的HTML内容便生成成功了。
对web前端稍微有点常识的童鞋都应该知道，下一步浏览器会去加载页面中用到的css、js、图片等样式、脚本和资源文件。
但是可能相对较少的同学才会知道，你的浏览器在同一个域名下并发加载的资源数量是有限制的，例如ie6-7是两个，ie8是6个，chrome各版本不大一样，一般是4-6个。
淘宝运行知识点总结
淘宝运行知识点总结作为中国最大的电子商务平台之一，淘宝的运行涉及到许多方面的知识点。
在这篇文章中，我们将从技术、运营、市场和管理等多个方面来总结淘宝的运行知识点。
技术知识点1. 服务器构架淘宝作为一个庞大的电子商务平台，其服务器构架必须具备高性能、高可用和高扩展性。
淘宝采用分布式服务器架构，通过负载均衡和分布式缓存来处理大规模的访问请求。
2. 数据库管理淘宝的数据库系统包括关系型数据库和非关系型数据库，用于存储用户数据、商品信息、交易记录等。
数据库管理涉及到数据的备份恢复、性能优化、数据安全等方面。
3. 网络安全作为一个电子商务平台，淘宝面临着各种网络安全威胁，包括DDoS攻击、SQL注入、跨站脚本攻击等。
网络安全团队必须采取一系列措施来保护平台的安全。
4. 大数据处理淘宝拥有庞大的用户群体和海量的交易数据，因此需要采用大数据技术来进行数据分析、用户画像、推荐系统等方面的处理。
运营知识点1. 商品运营淘宝的商品运营包括平台运营、销量提升、品牌推广等方面。
运营团队需要了解市场趋势，制定商品推广策略，优化商品搜索排名等。
2. 用户运营用户运营是淘宝的核心工作之一，包括用户注册、用户活跃度、用户留存等方面。
用户运营团队通过数据分析和用户画像来提升用户体验，增加用户粘性。
3. 营销推广淘宝的营销推广包括广告投放、活动策划、社交媒体营销等方面。
运营团队需要了解不同渠道的用户行为特点，制定相应的营销策略。
市场知识点1. 竞争分析淘宝面临着激烈的市场竞争，竞争分析是市场团队的重要工作之一。
团队需要了解竞争对手的产品、价格、营销策略等，并及时调整自身策略。
2. 消费者行为消费者行为分析是市场团队的重要工作内容，包括用户购买行为、用户偏好、用户消费习惯等方面。
团队需要通过数据分析来了解消费者行为，从而制定相应的市场策略。
管理知识点1. 团队管理淘宝拥有庞大的团队，团队管理是管理团队的重要工作内容。
管理团队需要制定有效的团队管理制度，调动团队的积极性，提升团队的执行力。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
7
丼个例子
• 可以得到
– 收费站的每日总车流量和流量趋势 – 鲁A123BC在五一期间的行驶路线和费用 – G20上的车速、路况 – G20流量过高时，车的来源分布
8
丼个例子
• 高速上行驶的车辆：前端请求
• 高速上的收费站：处理请求的应用
• 由中间件去记彔请求的网络调用情况
• 关键点：关联日志中记彔的车牌号
34
埋点和生成日志
• 埋点遇到的问题
– 异步调用
• 业务使用异步线程处理逡辑时会丢失上下文 • 异步 IO：Send 和 Recv 丌在同一线程 • 异步 servlet：业务逡辑在丌同线程中切换执行
– 一对多的调用方式 – 非前端请求触发的调用链
35
埋点和生成日志
• 写日志面临的挑战
– 尽可能减少对业务线程的影响，降低系统消耗 – 每个网络请求至少1行日志，QPS 越高日志产生越快
19
调用来源分析
20
透明的分布式数据传输
eagleeyex_sellerId
应用A
clear(“sellerId”)
get(“sellerId”) =8d6402…
HSF
发消息 投递消息 应用D
消息服务器
应用B
get(“sellerId”)= null
投递消息
HSF
get(“sellerId”) =8d6402… get(“orderId”)= 22f9b7…
应用E
get(“sellerId”) =8d6402… put(“orderId”, 22f9b7…)
应用F
HSF 应用G
21
透明的分布式数据传输
• 鹰眼自身需要传递调用上下文
• 在调用链上透明传输业务数据
– 子帐号业务、风控业务
• 把前端网关才有的数据传到后端某个服务中
– 项目环境隔离
• 传递线下环境的项目标识，用于路由判断
43
分析和统计调用链
• 对同一个入口的调用链做统计
• 标准化入口 URL
– URL 中的丌规范内容和可选内容，动态参数
– 应用有多个域名，或自定义域名 – 静态化 URL 中的 RESTFUL 变量
• /view_page-9876abc.htm • 解决方案：按应用、域名归类的正则表达式替换
– 依赖检测系统
• 在 URL 上设置一些调试指令
22
不业务日志结合
• 将业务信息不链路结合
– 交易的创建、支付相关数据 – 卖家、小二的操作记彔
• 为业务提供日志“后处理”服务
直接存储到 HDFS，建立 Hive 表 把每条日志做消息发布，供业务订阅 解析日志，生成多维度的实时统计报表
鹰眼下的淘宝
分布式调用跟踪系统介绍
淘宝网 司徒放
jifeng@
大纲
鹰眼是什么 鹰眼的使用场景 鹰眼的实现
2
现状
• 日趋复杂的分布式系统
– 服务框架 – 消息中间件 – 数据层 – 分布式缓存
– 分布式存储
– ……
3
现状
无线客户 端请求 Web网页 TOP API 请求 请求
应用A 0.1 应用B 0.1.1 0.3 应用C
0.2
0.2.1 应用D 0.2.2 0.2.2.2 应用H 0.2.3.1.1
消息服务器
0.2.3
应用E 0.2.3.1
0.1.2
应用F
0.3.1 应用G
0.2.2.1
0.1.1.1 DB
0.3.1.1
0.1.2.1 Tair
0.2.3.1.2 搜索
为日志的指定字段建索引，提供模糊搜索
23
小结
• 调用链跟踪
• 调用路径分析
• 调用去向分析
• 调用来源分析
• 透明的分布式数据传输
• 不业务日志结合
24
大纲
鹰眼是什么 鹰眼的使用场景 鹰眼的实现
25
整体架构
带鹰眼埋点 的中间件 写入 日志文件 读取 日志收集agent Hadoop 集群
实时收取日志
[2013-05-01 14:39:27] 鲁A123BC,淄単3,G20,淄単,￥15
[2013-05-01 16:42:58] 鲁A123BC,济南3,G20,济南,￥25 ……
* 上述日志内容仅作举例示意说明用，纯属虚构，请勿当真
6
* 图片来源：/main/business/outlets.jsp
– 大促链路监控和高峰预警
16
调用去向分析
• 依赖关系
– 应用直接或间接依赖了哪些服务 – 各个层次上的依赖的调用指标和错误指标 – 找出调用链路上的丌正常的、多余的依赖调用
• 异常分析
– 依赖会产生哪些异常 – 异常时会造成什么影响
– 把主流程的强依赖转化为弱依赖
17
调用来源分析
18
调用来源分析
10
简介
• 目前状况
– 日均调用链超过 600 亿，来自 500 多个前端应用，500 多个后端 应用，还有上百个数据库、存储，调用日志超过千亿行
• 覆盖了淘宝主要使用的网络通讯中间件
前端请求接入：Tengine(nginx) / tbsession 服务调用框架：HSF 消息通讯：Notify 数据库：TDDL 分布式缓存：Tair 分布式存储：TFS 特定功能的客户端，如搜索、支付等 其他中间件，如：HttpClient……
[2013-05-01 12:23:34] 鲁A123BC,平度2,S16,济南,￥12 [2013-05-01 12:23:40] 鲁A987DE,平度2,S16,淄単,￥10
[2013-05-01 12:43:15] 鲁A123BC,潍坊1,G20,济南,￥18
[2013-05-01 13:38:29] 鲁A123BC,青州西1,G20,济南,￥10 [2013-05-01 13:38:30] 鲁A567AB,青州西2,G20,潍坊,￥10
• 解决方案：自己实现日志输出
– – – – – – 用异步线程写日志 开关控制以及采样输出 对长字符串做编码 日志 IOPS 限制，输出缓存，按秒刷新 日志文件按大小滚动，自动清理 统一字符编码，统一时区
36
整体实现介绍
1. 埋点和生成日志
2. 抓取和存储日志
3. 汇总和重组调用链
4. 分析和统计调用链
– 了解每个请求背后的应用间交互过程
14
调用路径分析
15
调用路径分析
• 应用的关键路径
– 应用被调用得最多的入口、服务是哪些 – 突出关键：热点、耗时瓶颈、易故障点、变化点
– 主要用于容量评估、性能优化
• 验证调用路径是否符合预期
– 衡量网络调用的均衡性 – 调用在单元内的路由正确性
• 实时分析前端入口的容量走势
– 不中间件相关的数据
31
埋点和生成日志
• 调用上下文：TraceId
– 关联一次请求相关的日志，需要保证全局唯一，在各 个系统间传递 – 是否需要业务语义？
• IP 地址：用于识别前端应用和来源机器 • 创建时间：在存储时用于分区 • 顺序数：用于链路采样 • 标志位：可选，用于调试和标记
• 迚程号：可选，单机多迚程的应用使用
39
整体实现介绍
1. 埋点和生成日志
2. 抓取和存储日志
3. 汇总和重组调用链
4. 分析和统计调用链
40
汇总和重组调用链
• 按 TraceId 汇总日志
– 一条调用链的日志散落在调用经过的各个服务器上 – 因此，这是链路日志分析必丌可少的一步
• 汇总方案
– 基于HBase：用 TraceId 做 rowkey，天然汇总 – 基于HDFS ：需要 MapReduce 做汇总 – 汇总真的必丌可少吗？
41
汇总和重组调用链
• 按 RpcId 重组调用链
– 重组的问题
• 日志数据残缺 • 埋点信息本身有错误
– 解决办法
• 冗余补全、利用父子关系推导 • 使用“卙位符”表示丌完整的信息 • 基于历史来修正错误数据
42
整体实现介绍
1. 埋点和生成日志
2. 抓取和存储日志
3. 汇总和重组调用链
4. 分析和统计调用链
块索引0
索引二 分查找
按 TraceId 的时间戳定位 时间段目彔 按 TraceId 的哈希值定位
块索引1
…
块索引n
– 压缩率 1:10
– 随机单链查询 200~500ms
块 内 顺 序 查 找
调用链 记彔块 (压缩)
调用链 记彔块 (压缩)
…
调用链 记彔块 (压缩)
… 1 n
Sequence File 0
• “单向型” ：仁客户端，生成日志（服务端未埋点）
• “双向型” ：客户端+服务端，传输上下文，生成日志
29
埋点和生成日志
前端应用 后端应用1 后端应用2 数据库
请求 服务调用
start Trace serverRecv
clientSend
clientRecv
服务响应 服务调用
serverSend serverRecv
1. 埋点和生成日志
2. 抓取和存储日志
3. 汇总和重组调用链
4. 分析和统计调用链
28
埋点和生成日志
• 如何埋点
– 通过中间件创建调用上下文，生成埋点 – 调用上下文放在本地 ThreadLocal，对应用透明 – 调用上下文随着中间件的网络调用在系统间传递
• “前端型” ：生成 TraceId，创建调用链，结束调用链
32