Trace分布式链路追踪系统设计理念基于Google Dapper：分布式链路追踪系统架构，包括埋点工具、数据收集、分析、存储、展示等一系列服务。Trace通过在中间件中埋点，采集和标记分布式组件在交互时调用方法、调用时长、调用结果等一些必要信息，可以展示调用链的全貌、状态、异常等信息，也可以用来分析耗时瓶颈、通过日志排查问题。

1 链路追踪的基本概念

1.1 RPC中的角色与过程：Client、Server、Trace

Trace：用户一次完整的请求过程

1.2 调用链路中的标记信息：TraceId、SpanId、SpanName

TraceId：用户一次完整请求过程的唯一id标记
SpanName：调用不同的环节，通常根据交互的角色不同稍有不同，rpc中spanname可以是类名+方法名，数据库 spanname 可以是sql，kafka可以使用topic+消费组
SpanId：调用的发起顺序

1.3 埋点上报的单位：Span

Span：埋点信息。
RPC调用的埋点由server、client参与，调用完成后，server、client分别上报一个埋点信息，称为span。

1.4 用户自定义埋点：Annotation、Context

Annotation：自定义埋点，主要用于属性上报，手动传递key-value 到span中。比如给trace加上userid=xxx
Context：上下文，主要用于server、client的通信参数，传递的信息包括灰度标记、泳道信息等，主要在全链路压测（传递压测标识）、服务鉴权等场景使用

2 工作原理

同一个线程同一时间只会处理同一个请求，可以使用ThreadLocal变量存储client、server的Span对象

3 数据采集

有traceid、spanid，在记录log时带上这两个字段，就可以将一次请求串联起来。设置可以将traceid、spanid注入到数据库连接池应用里，慢sql日志就可以打印traceid、spanid，为响应过慢提供有效分析数据。

3.1 数据采样

每次rpc都上报log会对系统带来灾难性的带宽消耗。在spanid=0根节点服务采样，后续都按根节点方式采样就能拼接成一个调用链路。
为什么有的采样会丢失？每个服务采样队列满了，多余的数据会被丢弃掉。
为了能保证定位问题，一般对异常链路会采样

支付冲正
定义：支付冲正是一种支付交易处理方式，它用于在交易发生错误时撤销原交易。冲正操作通常发生在交易完成后的短时间内，目的是将交易双方的账户恢复到交易发生前的状态。
场景：例如，如果POS机在扣款后打印小票时出现故障，或者交易双方发现交易金额错误，商家可以执行冲正操作，以取消这笔交易。
时效性：冲正操作通常有时间限制，只能在交易当天或特定时间内进行。
关单
定义：关单是指关闭一个未完成的支付订单，使其无法继续进行支付操作的过程。关单操作用于处理那些未完成的交易，例如用户放弃支付，或者交易超时等情况。
场景：例如，顾客在网上下单后选择在线支付，但在支付过程中突然不想购买了，商家可以对这个订单执行关单操作，订单状态变为关闭，无法继续支付。
时效性：关单没有冲正那么严格的时间限制，只要订单还未完成支付，就可以进行关单操作。
结论
支付冲正和关单都是处理支付问题的方法，但它们适用的场景和时效性不同。支付冲正用于取消已经完成但有错误的交易，通常在短时间内执行；而关单用于关闭未完成的支付订单，时间限制相对宽松。两者都是确保交易正确性和安全性的重要工具。

硅谷“渣男”事件还原

想尽办法占有100%遗产，剥夺妻子父母的继承权，过世后去婚恋网9天闪婚新妻，动用加州警力驱逐岳父母离境。 这属于典型的道德之下，法律之上。

为什么要成立信托？成本如何？

信托建立的初衷是 并不知道明天和意外哪一个会先来，建立初衷就是以will（遗嘱）的方式或者把我现在的一些资产装进一个信托中，来去保证如果哪一天发生意外，家人会受到一定的保护。在美国身故如果没有will（遗嘱）或者信托的话，你的财产会被法院进行一定的判决，判决过程中产生的纠纷以及在等待期，你的资产是被锁定的，如果你的子女很需要用钱，或者这笔钱被冻结两三个月的话，效率很低，诉讼还有经济上的成本。

• 法院判决诉讼周期
• 财产冻结期
• 身故后产生的纠纷和不可预测事件
  所以为了身故后产生纠纷和不可预测事件，很多人开始建立信托，在纽约州成本最简单的设计在1000美金以内。

常见信托类型

• 可变更的生前信托：revocable living trust，你对信托有一定的支配权。
• 不可变更：irrevocable living trust，你的托管人或者受益人就拥有了这笔财产的使用权

常见2个信托概念误区

• Trustee：委托人，有财产的支配权。常见的是未成年子女的监护人，主要两种类别，银行或专业机构：收费高、门槛高。亲属：配偶、兄弟姐妹、父母。风险主要在于可能反目，不可预测性强，对财产支配和管理能力有限
• Benificiary：受益人，是信托实际受益人，但是如何分配和管理指导权，其实是属于trustee

1.数据库使用阶段

• 1.1 单库单表

• 1.2 单库多表(目前阶段)

• 1.3 多库多表

2.什么情况下需要分库分表

• 数据库表中的数量达到了一定的量级

• 数据库吞吐量达到了瓶颈，需要增加数据库实例开分解大量数据库请求带来的系统压力

• 扩容时对应用层的配置改变最少，需要在每个数据库实例中预留足够的数据库数量

3.解决方案

• 3.1 拆分的方式:垂直拆分和水平拆分
  垂直拆分是指，将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的表中，以降低单库（表）大小，达到提升性能的目的的方法，垂直切分后，各个库（表）的特点是：

（1）每个库（表）的结构都不一样

（2）一般来说，每个库（表）的属性至少有一列交集，一般是主键

（3）所有库（表）的并集是全量数据

水平切分是指，以某个字段为依据（例如uid），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）上，以降低单库（表）大小，达到提升性能的目的的方法，水平切分后，各个库（表）的特点是：

（1）每个库（表）的结构都一样

（2）每个库（表）的数据都不一样，没有交集

（3）所有库（表）的并集是全量数据

• 3.2 实现的方式:客户端分片,代理分片和支持实物的分布式数据库

• 3.2.1 客户端分片

具体实现方式:在应用层直接实现,通过制定JDBC协议实现，通过定制ORM框架实现

应用层直接实现

直接在应用层读取分片规则，然后解析分片规则，根据分片规则实现切分的路由逻辑，从应用层直接决定每次操作应该使用哪个数据库实例，数据库以及数据库表；这种实现方案虽然入侵了业务，但是实现起来比较简单，适合快速上线，而且切分逻辑由自己开发，如果在生产上产生了问题，比较容易解决

制定JDBC协议实现

在应用层直接实现会入侵应用的业务实现，对开发人员的能力要求较高，为了开发人员把精力集中在业务逻辑的开发上，可以通过制定jdbc协议来实现，保证业务层接口透明，Sharding JDBC便采用了这种方案

通过定制ORM框架实现

把分片规则实现放到ORM框架中或者通过ORM框架支持的机制来实现分库分表的逻辑，通用的做法是在Mybatis配置文件中增加表索引的参数来实现分片

• 3.2.2 代理分片

代理分片是在应用层和数据库层增加一个代理层，把分片的路由规则配置放在代理层，代理层对外提供与JDBC兼容的接口跟应用层，只需要关系业务逻辑实现，待业务逻辑实现后，在代理层配置路由规则即可，缺点是增加了代理层，尽管代理层是轻量级的转发协议，但是要实现JDBC协议的解析，并且通过分片的路由规则来路由请求，对每个数据库操作都增加了一层网络传输，对性能是有影响的，需要维护增加的代理层，也有硬件成本，还要有解决bug的技术专家，成本比价高，Cobar和MyCat是通过此种方式实现

• 3.2.3 支持事务的分布式数据库

市面上现有的产品如OceanBase，TiDB等都对外提供可伸缩的体系架构，并提供一定的分布式事务支持，将可伸缩的特点和分布式事务的实现包装到分布式数据库内部实现，对使用者透明，例如:TiDB对外提供JDBC接口，让应用层像使用MySQL一样来使用TiDB，而不用关注内部是如何伸缩，分片及处理分布式事务的，此类数据库适合非交易系统，例如大数据日志系统，统计系统，查询系统等

4.引起的问题

• 4.1 扩容与迁移
  在分库分表后，如果涉及的分片已经达到了承载数据的最大值，就需要对集群进行扩容。扩容是很麻烦的，一般会成倍地扩容。

通用的扩容方法包括如下5个步骤。

（1）按照新旧分片规则，对新旧数据库进行双写。

（2）将双写前按照旧分片规则写入的历史数据，根据新分片规则迁移写入新的数据库。

（3）将按照旧的分片规则查询改为按照新的分片规则查询。

（4）将双写数据库逻辑从代码中下线，只按照新的分片规则写入数据。

（5）删除按照旧分片规则写入的历史数据。

这里，在第2步迁移历史数据时，由于数据量很大，通常会导致不一致，因此，先清洗旧的数据，洗完后再迁移到新规则的新数据库下，再做全量对比，对比后评估在迁移的过程中是否有数据的更新，如果有的话就再清洗、迁移，最后以对比没有差距为准。

如果是金融交易数据，则最好将动静数据分离，随着时间的流逝，某个时间点之前的数据是不会被更新的，我们就可以拉长双写的时间窗口，这样在足够长的时间流逝后，只需迁移那些不再被更新的历史数据即可，就不会在迁移的过程中由于历史数据被更新而导致代理不一致。

在数据量巨大时，如果数据迁移后没法进行全量对比，就需要进行抽样对比，在进行抽样对比时要根据业务的特点选取一些具有某类特征性的数据进行对比。

在迁移的过程中，数据的更新会导致不一致，可以在线上记录迁移过程中的更新操作的日志，迁移后根据更新日志与历史数据共同决定数据的最新状态，来达到迁移数据的最终一致性。

在分库分表以后，如果查询的标准是分片的主键，则可以通过分片规则再次路由并查询；但是对于其他主键的查询、范围查询、关联查询、查询结果排序等，并不是按照分库分表维度来查询的。

• 4.2 查询问题
  例如，用户购买了商品，需要将交易记录保存下来，那么如果按照买家的纬度分表，则每个买家的交易记录都被保存在同一表中，我们可以很快、很方便地查到某个买家的购买情况，但是某个商品被购买的交易数据很有可能分布在多张表中，查找起来比较麻烦。反之，按照商品维度分表，则可以很方便地查找到该商品的购买情况，但若要查找到买家的交易记录，则会比较麻烦。

所以常见的解决方式如下。

（1）在多个分片表查询后合并数据集，这种方式的效率很低。

（2）记录两份数据，一份按照买家纬度分表，一份按照商品维度分表。

（3）通过搜索引擎解决，但如果实时性要求很高，就需要实现实时搜索。

实际上，在高并发的服务平台下，交易系统是专门做交易的，因为交易是核心服务，SLA的级别比较高，所以需要和查询系统分离，查询一般通过其他系统进行，数据也可能是冗余存储的。

这里再举个例子，在某电商交易平台下，可能有买家查询自己在某一时间段的订单，也可能有卖家查询自己在某一时间段的订单，如果使用了分库分表方案，则这两个需求是难以满足的。因此，通用的解决方案是，在交易生成时生成一份按照买家分片的数据副本和一份按照卖家分片的数据副本，查询时分别满足之前的两个需求，因此，查询的数据和交易的数据可能是分别存储的，并从不同的系统提供接口。

另外，在电商系统中，在一个交易订单生成后，一般需要引用到订单中交易的商品实体，如果简单地引用，若商品的金额等信息发生变化，则会导致原订单上的商品信息也会发生变化，这样买家会很疑惑。因此，通用的解决方案是在交易系统中存储商品的快照，在查询交易时使用交易的快照，因为快照是个静态数据，永远都不会更新，所以解决了这个问题。可见查询的问题最好在单独的系统中使用其他技术来解决，而不是在交易系统中实现各类查询功能；当然，也可以通过对商品的变更实施版本化，在交易订单中引用商品的版本信息，在版本更新时保留商品的旧版本，这也是一种不错的解决方案。

最后，关联的表有可能不在同一数据库中，所以基本不可能进行联合查询，需要借助大数据技术来实现，也就是上面所说的第3种方法，即通过大数据技术统一聚合和处理关系型数据库的数据，然后对外提供查询操作

通过大数据方式来提供聚合查询的方式

4.3 分布式事务
三种解决方案:两段式提交协议，最大努力保证模式和事务补偿机制

4.4 同组数据跨库
要尽量把同一组数据放到同一台数据库服务器上，不但在某些场景下可以利用本地事务的强一致性，还可以使这组数据自治。以电商为例，我们的应用有两个数据库db0和db1，分库分表后，按照id维度，将卖家A的交易信息存放到db0中。当数据库db1挂掉时，卖家A的交易信息不受影响，依然可以正常使用。也就是说，要避免数据库中的数据依赖另一数据库中的数据。

概览

• 科学上网
• 区块链
• BTC
• ETH
• NFT
• 元宇宙
• 中心化交易所
• 去中心交易所
• DeFi
• DApp

科学上网

略（研发同学的基本获取信息能力，就不再展开赘述

“什么是钱？”

• 是以国家信用为担保发行货币。好处可以调控经济。
• 但是当国家信用破产、你手里的钱就一文不值。
• 钱越印越多，高通胀、手里的钱贬值。
• 数字黄金

比特币和挖矿是什么？

• 举个例子，有ABCDEFG 7个人，A借给B一块钱，然后7个人都要把这个事记录下来，避免B不认账，保障A的利益，那为什么CDEFG要给A和B记账呢？中本聪就提出来，谁记账，就奖励一个比特币。记账的过程，就是挖矿，奖励就是比特币

比特币为什么越来越值钱？

• 特点：不可再生、总量有限；全世界都知道（共识）
• 这个世界上，任何不可再生，无法复制的东西，都是值钱的。哪怕是一块奇葩的石头。这个价值是人为铆钉的。
• 因为共识，比特币是最大的共识
• 比特币可以理解为数字黄金

比特币为什么能火？

• 避税，不承认它是货币，所以不用交税，富人遗产全部买成比特币，留给后代
• 跨境能力、外汇、洗钱
• 不记名，转账给谁根本不知道

区块链

• 区块链说白了就是分布式账本，也就是很多人都在记账的意思

“ETH是第二大共识。”

–所有的数字货币的市值在2w亿美金

中心化交易所

• 币安、OKEx
• 需要KYC认证
• 清退大陆用户

DeFi

• DeFi的全称是Decentralized Finance，即“去中心化金融”
• DeFi不需要依赖任何中心化的主体来提供信用中介或者背书
• 没有准入限制，即任何一个联网的人都可进入
• 任何第三方均无法阻止任何一笔交易，也不能逆转任何一笔交易

DApp

• DApp的全称是Decentralized App，即“去中心化应用”
• 代表：TokenPocket、MetaMask

去中心化交易所

• 去中心化交易所是一个基于区块链的交易所，它不将用户资金和个人数据存储在中心化服务器上，由机构托管交易，而是通过智能合约匹配数字资产的买家和卖家，进行点对点交易
• 代表：Uniswap、PancakeSwap

NFT

• NFT是Non Fungible Token的缩写，也就是非同质化代币
• NFT由于其非同质化、不可拆分的特性，使得它可以和现实世界中的一些商品绑定。其实就是发行在区块链上的数字资产，这个资产可以是游戏道具、数字艺术品、门票等，并且具有唯一性和不可复制性。由于NFT具备天然的收藏属性和便于交易，加密艺术家们可以利用NFT创造出独一无二的数字艺术品。

元宇宙

• “下个阶段的平台和媒体，会让人更有身临其境之感，你将不仅仅是从旁观看，而是置身’实体互联网’之中。这就是‘元宇宙’。
• “当我把小孩的视频发给我父母时，他们会觉得自己就像和我们在一起一样，而不是只通过一个小小的屏幕观看；当你和朋友玩游戏时，你会觉得跟他们同处同一世界，而不是独自面对电脑。”

Description

• 最近看到很多人在安装 Orange 过程中碰了问题，大多数是因为找不到第三方依赖包。其实 README.md 安装步骤已经写的很详细了，但是对于新手来说，特别是对 OpenResty 都不太熟悉的同学，还是有点不太友好。因为 Orange 是基于 OpenResty 的 API 网关。所以在使用 Orange 之前，建议去把 OpenResty 的官方文档认真的读两遍，可以避免由于自己缺乏常识而导致的一些错误以至于浪费太多时间。不可否认, Orange 现在对于插件的第三方依赖的管理方式并不是最完美的，这其实不是 Orange 本身的问题，是由于 OpenResty 到现在官方也没有提供一种特别好用的工具， opm 现在还是仅仅处于能用的状态，相比于 Node.js 社区中的 npm 还有很大的进步空间。

• 现在 Orange 的开发成员将将插件所依赖的第三方包发布到 opm 仓库 中，我们只需要通过 opm --install-dir=./ get zhangbao0325/orangelib 就可以将所有第三方依赖下载下来，目前看来是一个不错的解决办法。但是也存在一个问题，由于维护这个仓库的人员跟插件的贡献者并不是同一个人，所有有可能会导致他维护提供的三方依赖包不是完全正确的，我在这个过程中遇到了几个问题，详情参看 #280 #281。

Install Orange

• 安装最新版本的 OpenResty,注意在编译 OpenResty 的时候需要添加上 --with-http_stub_status_module,监控插件需要统计 http 某些状态数据
• 将 nginx 和 resty 命令配置到环境变量中，使用 nginx -v 和 resty -v 验证是否正常输出
• 安装 lor 框架
• 安装 MySQL
• 将 install/oorange-v0.6.4.sql 导入到 orange 库中
• 修改配置文件
  一个是关于 Dashboard 和插件的配置文件 conf/orange.conf，另一个是 Nginx 的配置文件 conf/nginx.conf
  orange.conf配置如下，请根据实际情况修改

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

  { "plugins": [ //可用的插件列表，若不需要可从中删除，系统将自动加载这些插件的开放API并在7777端口暴露 "stat", "monitor", "redirect", "rewrite", "rate_limiting", "property_rate_limiting", "basic_auth", "key_auth", "signature_auth", "waf", "divide", "kvstore" ], "store": "mysql",//目前仅支持mysql存储 "store_mysql": { //MySQL配置 "timeout": 5000, "connect_config": {//连接信息，请修改为需要的配置 "host": "127.0.0.1", "port": 3306, "database": "orange", "user": "root", "password": "", "max_packet_size": 1048576 }, "pool_config": { "max_idle_timeout": 10000, "pool_size": 3 }, "desc": "mysql configuration" }, "dashboard": {//默认的Dashboard配置. "auth": false, //设为true，则需用户名、密码才能登录Dashboard,默认的用户名和密码为admin/orange_admin "session_secret": "y0ji4pdj61aaf3f11c2e65cd2263d3e7e5", //加密cookie用的盐，自行修改即可 "whitelist": [//不需要鉴权的uri，如登录页面，无需修改此值 "^/auth/login$", "^/error/$" ] }, "api": {//API server配置 "auth_enable": true,//访问API时是否需要授权 "credentials": [//HTTP Basic Auth配置，仅在开启auth_enable时有效，自行添加或修改即可 { "username":"api_username", "password":"api_password" } ] } }

nginx.conf中需要注意以下几个配置

1. lua_package_path：需要根据本地环境配置适当修改
2. resolver：DNS解析

• 通过 make install 安装

• 安装第三方依赖包

  1 2 3 4 5

  cd /usr/local/orange/ opm --install-dir=./ get zhangbao0325/orangeli luarocks install luafilesystem luarocks install luasocket luarocks install lrandom

• 通过 orange start 启动，执行 orange help 来查看哪些命令可用。内置的Dashboard可通过 http://localhost:9999 访问

Description

• 很有幸在2016年的时候接触到OpenResty，OpenResty将强大的Lua嵌入到了Http Server中。这几年工作中也做了些OpenResty项目的落地，比如国际化、商品详情页、动态商品价格、后台权限管理、开放平台等，后来又接触到了基于OpenResty的API网关，比如Orange、Kong等。8月份在北京丽都皇冠假日酒店参加了 agentzh 回国举办的OpenResty 2019 北京技术沙龙，受到了很多启发。最近准备抽出时间整理一下这几年学习和应用OpenResty的经验和踩过的坑，特此记录。

Mac Install OpenResty

• 利用brew安装OpenResty依赖

1. brew update
2. brew install openssl curl

• 通过brew安装pcre，无法开启pcre-jit以及UTF-8支持,所以通过编译源码安装

1. wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.40.tar.gz

2. tar -xvf pcre-8.40.tar.gz

3. 1 2 3 4

   sudo ./configure --prefix=/usr/local/pcre-8.40 \ --enable-jit \ --enable-utf8 \ --enable-unicode-properties

4. sudo make

5. sudo make install

6. 到此 pcre 已支持 JIT ，也可在最后编译 OpenResty 时通过 –with-pcre=/path/to/pcre-xxx/ 指定 pcre 安装路径

• 安装drizzle模块

1. wget https://openresty.org/download/drizzle7-2011.07.21.tar.gz
2. tar zxvf drizzle7-2011.07.21.tar.gz
3. cd drizzle7-2011.07.21
4. sudo ./configure –prefix=/usr/local/drizzle –without-server
5. sudo make libdrizzle-1.0
6. sudo make install-libdrizzle-1.0

• ngx_eval - Capturing subrequests response bodies into NGINX variables

1. git clone https://github.com/openresty/nginx-eval-module.git

• Auth request module for nginx

1. git clone git@github.com:PiotrSikora/ngx_http_auth_request_module.git

• 安装OpenResty

1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   sudo ./configure --prefix=/usr/local/openresty \ --with-cc-opt="-I/usr/local/opt/openssl/include/ -I/usr/local/opt/pcre/include/" \ --with-ld-opt="-L/usr/local/opt/openssl/lib/ -L/usr/local/opt/pcre/lib/" \ --with-luajit \ --with-debug \ --with-pcre=/Users/liulei18/Desktop/openresty/pcre-8.40 \ --with-pcre-jit \ --with-http_iconv_module \ --with-http_postgres_module \ --with-http_drizzle_module \ --with-libdrizzle=/usr/local/drizzle \ --with-http_realip_module \ --with-http_stub_status_module \ --add-module=/Users/liulei18/Desktop/openresty/nginx-eval-module \ --add-module=/Users/liulei18/Desktop/openresty/ngx_http_auth_request_module

2. sudo make -j2

3. sudo make install