最近在做性能优化项目时，发现 RPC 框架调用极个别请求在路由过程非常耗时。对于这种极个别的问题要定位起来还是比较棘手的，如果性能问题可以稳定复现的还可以一步步打点缩小范围，但我这个是千分之一的出现概率，需要大规模日志打点才能够准确找到耗时的地方。如何搞呢，只能网上找找有没有更好的办法了，在网上看资料时，突然看到毕玄的文章提到可以用 btrace 定位这样的问题，现学现卖了一把。

2015 年过去了，去年状态如上图所示，朋友看图后均说去年是拉风的一年。但如果仔细看过这个场景的人会发现，谈吉他的人是一个没有双眼的奴隶，被绳索绑在战车前，当听到战鼓响起时，便如打了鸡血般跳起来，姿态夸张的谈着那喷火的吉他。如他一样，今年的我并不拉风，倒是如瞎了一般感觉到了迷茫。

1. 原理

1.1 SSH 原理

1. 远程主机收到用户的登录请求，把自己的公钥发给用户
2. 用户使用这个公钥，将登录密码加密后，发送回来
3. 远程主机用自己的私钥，解密登录密码。如果密码正确，就同意用户登录

Docker 插件是什么

docker 插件是 docker 提供出来的扩展机制，目前 docker 支持 volume 和 network 两种插件，由于 network 插件比较复杂而且没有好的开源项目，这里主要介绍 volume 插件。

插件是一个独立的进程和 docker daemon 运行在同一台 host 上，通过 Plugin Discovery 的机制进行插件发现，插件有几个要求：

• 插件名要求是小写
• 插件可以运行在容器内也可以运行在容器外，不过现阶段建议运行在容器外

1. 通信层

• 直接使用最成熟的网络框架，如 Netty
• 单连接 & 连接复用 & 长连接
  • 建议提前设计心跳机制
  • 集群较小，长连接无需开启心跳
  • 如果网络情况比较复杂，建议开启心跳。如有防火墙，会将连接清掉且不会向客户端发送 RST 信令，导致长连接变成一个脏连接

1. 原则

原则1：了解使用

仔细查看使用文档和说明，写较为详细的 demo 程序。

原则2：了解全局

了解该产品解决了哪些问题，并了解其周边产品及优缺点。

原则3：了解原理

查看其内部架构文档，如果有了周边产品的了解，可以从周边产品推算出其实现基本原理。不过当对其它产品了解比较深刻的时候，这个原则很容易就可以达到了。