签发CA并使用CA签发SSL证书

1. 在 ~/ca 创建CA证书和私钥，私钥为 ca_key.pem ，公钥为 ca.pem 。 ca.pem 后续将被安装到系统并信任。
2. 在 ~/ca/certs 创建自定义SSL证书，私钥为 privkey.pem ，公钥为 cert.pem。他们将被用于启动https服务。

脚本下载：ca.sh。

RPC拓扑-流量视角（二期）

优化点

1. “流量入口“增加模糊搜索能力
2. 增加“不区分调用方”的选项
3. 增加提示：“指标数据由采样率还原得到，和实际情况可能有微小差距。采样率越高或qps越高，估算得越准。”
4. 显示级别默认为“服务级别”，且变更为下拉框选择，因为“不区分调用方”也是checkbox，三个checkbox连一起操作起来不方便
5. “调用方”、“被调用方”拆分为“调用方”、“调用方接口”、“被调用方”、“被调用方接口”，http响应中新增了对应的四个字段。“服务级别”时，不显示“调用方接口”、“被调用方接口”这两列。
6. “样本Trace”列显示的值从“详情”变更为examplar的值（就是traceId）
7. “最大耗时”列增加提示：“采样率不为百分之百时，该值更像TP值。例如1%采样率下，该值更接近TP99或TP999。因为这是1%数据中的最大耗时。采样率越大，越接近真实最大值，或者说9的位数越多。”
8. 增加“显示详情”的操作，展示类似“服务高级视角”中的抽屉，抽屉展示的信息如下：

RPC拓扑-服务高级视角

背景

当前“RPC拓扑”支持“服务视角”和“流量视角”，所谓视角即输入什么参数来查询拓扑。“服务视角”是输入服务名来查看拓扑，“流量视角”是输入入口url来查看拓扑。

trace详情搜索性能优化

现状

当前根据traceId点查trace详情的耗时很长，有两个影响：

1. 点查trace详情耗时长，用户体验差。
2. 链路的未来功能演进需要一次获取多个traceId的详情。例如：通过多个trace详情的联合分析，以智能地定位慢请求根因。

目前点查trace详情的主要耗时来源于下面的sql，用途是获取改traceId下的所有app和开始结束时间。

新traceId格式

背景

当前端上使用一个long值的16进制的字符串作为traceId。目前存在两个问题：

1. 64位随机数的碰撞概率高，目前已经出现traceId碰撞的情况

Entry级别拓扑及性能指标计算

背景

上下游拓扑及上下游调用性能指标是链路监控的重要部份。从生成过程来看，先给trace个案进行分类，然后按类汇总出同类trace的调用路径，这个调用路径通常是一个有向无环图，也就是拓扑。按照什么标准进行分类是上述过程的重点，上面所说的分类和汇总，表述成SQL大概就是聚合函数（count、avg等）和groupBy语句的结合，其中groupBy语句就是分类标准， count和avg是相关的性能指标。

Generate by ChatGPT4

W3C (World Wide Web Consortium)推出了Trace Context规范，旨在规范分布式追踪中跟踪信息的传播格式。Trace Context规范主要定义了两个HTTP头部字段：traceparent和tracestate。

今天花重金在一家蔡司专家店配了新的眼镜，来记录下过程。

我即将在这个阳光明媚的春天离开美团，草草总结下毕业后的这四年。

第一次剪一个简短的视频记录生活