超实用的大型分散式系统Pinpoint技术介绍
概述
Pinpoint是一个分析大型分散式系统的平台，提供解决方案来处理海量跟踪资料。2012年七月开始开发，2015年1月9日作为开源专案启动。今天主要介绍Pinpoint相关概念，后面再介绍具体的搭建过程。
Pinpoint特点
过去的因特网的使用者数量相对较小，而因特网服务的架构也没那么复杂。web服务通常使用两层(web 服务器和数据库)或三层（web服务器，应用服务器和数据库）架构。然而在如今，随着互联网的成长，需要支援大量的并发连线，并且需要将功能和服务有机结合，导致更加复杂的软件栈组合。更确切地说，比三层层次更多的n层架构变得更加普遍。SOA或者微服务架构成为现实。系统的复杂度因此提升。系统越复杂，越难解决问题，例如系统失败或者效能问题。在三层架构中找到解决方案还不是太难，仅仅需要分析3个元件比如web服务器，应用服务器和数据库，而服务器数量也不多。但是，如果问题发生在n层架构中，就需要调查大量的元件和服务器。另一个问题是仅仅分析单个元件很难看到大局;当发生一个低可见度的问题时，系统复杂度越高，就需要更长的时间来查询原因。最糟糕的是，某些情况下我们甚至可能无法查找出来。
这样的问题也发生在NAVER的系统中。使用了大量工具如应用效能管理(APM)但是还不足以有效处理问题。因此我们最终决定为n层架构开发新的跟踪平台，为n层架构的系统提供解决方案。
Pinpoint, 2012年七月开始开发，在2015年1月作为一个开源专案启动, 是一个为大型分散式系统服务的n层架构跟踪平台。 Pinpoint的特点如下:
分散式事务跟踪，跟踪跨分散式应用的讯息自动检测应用拓扑，帮助你搞清楚应用的架构水平扩充套件以便支援大规模服务器丛集提供程式码级别的可见性以便轻松定位失败点和瓶颈使用字节码增强技术，新增新功能而无需修改程式码
在Google Dapper中分散式事务追踪是如何工作的
pinpoint跟踪单个事务中的分散式请求，基于google Dapper。当一个讯息从Node1传送到Node2时，分散式追踪系统的核心是在分散式系统中识别在Node1中处理的讯息和在Node2中出的讯息之间的关系。
图1. 分散式系统中的讯息关系
问题在于无法在讯息之间识别关系。例如，我们无法识别从Node1传送的第N个讯息和Node2接收到的N'讯息之间的关系。换句话说，当Node1传送完第X个讯息时，是无法在Node2接收到的N的讯息里面识别出第X个讯息的。有一种方式试图在TCP或者操作系统层面追踪讯息。但是，实现很复杂而且效能低下，而且需要为每个协议单独实现。另外，很难精确追踪讯息。
不过，Google dapper实现了一个简单的解决方案来解决这个问题。这个解决方案通过在传送讯息时新增应用级别的标签作为讯息之间的关联。例如，在HTTP请求中的HTTP header中为讯息新增一个标签资讯并使用这个标签跟踪讯息。
而Pinpoint基于google dapper的跟踪技术,但是已经修改为在呼叫的header中新增应用级别标签资料以便在远端呼叫中跟踪分散式事务。标签资料由多个key组成，定义为TraceId。
Pinpoint中的资料结构
Pinpoint中，核心资料结构由Span, Trace, 和 TraceId组成。Span: RPC (远端过程呼叫/remote procedure call)跟踪的基本单元; 当一个RPC呼叫到达时指示工作已经处理完成幷包含跟踪资料。为了确保程式码级别的可见性，Span拥有带SpanEvent标签的子结构作为资料结构。每个Span包含一个TraceId。Trace: 多个Span的集合; 由关联的RPC (Spans)组成. 在同一个trace中的span共享相同的TransactionId。Trace通过SpanId和ParentSpanId整理为继承树结构.TraceId: 由 TransactionId, SpanId, 和 ParentSpanId 组成的key的集合. TransactionId 指明讯息ID，而SpanId 和 ParentSpanId 表示RPC的父-子关系。TransactionId (TxId): 在分散式系统间单个事务传送/接收的讯息的ID; 必须跨整个服务器丛集做到全域性唯一.SpanId: 当收到RPC讯息时处理的工作的ID; 在RPC请求到达节点时生成。ParentSpanId (pSpanId): 发起RPC呼叫的父span的SpanId. 如果节点是事务的起点，这里将没有父span - 对于这种情况， 使用值-1来表示这个span是事务的根span。
TraceId如何工作
下图描述TraceId的行为，在4个节点之间执行了3次的RPC呼叫：
图2： TraceId行为示例
在上图中，TransactionId (TxId) 体现了三次不同的RPC作为单个事务被相互关联。但是，TransactionId 本身不能精确描述PRC之间的关系。为了识别PRC之间的关系，需要SpanId 和 ParentSpanId (pSpanId). 假设一个节点是Tomcat，可以将SpanId想象为处理HTTP请求的执行绪，ParentSpanId代表发起这个RPC呼叫的SpanId.
使用TransactionId，Pinpoint可以发现关联的n个Span，并使用SpanId和ParentSpanId将这n个span排列为继承树结构。
SpanId 和 ParentSpanId 是 64位长度的整型。可能发生冲突，因为这个数字是任意生成的，但是考虑到值的范围可以从-9223372036854775808到9223372036854775807，不太可能发生冲突. 如果key之间出现冲突，Pinpoint和Google Dapper系统，会让开发人员知道发生了什么，而不是解决冲突。
TransactionId 由 AgentIds, JVM (java虚拟机器)启动时间, 和 SequenceNumbers/序列号组成.
AgentId: 当Jvm启动时使用者建立的ID; 必须在pinpoinit安装的全部服务器丛集中全域性唯一. 最简单的让它保持唯一的方法是使用hostname($HOSTNAME)，因为hostname一般不会重复. 如果需要在服务器丛集中执行多个JVM，请在hostname前面增加一个字首来避免重复。JVM 启动时间: 需要用来保证从0开始的SequenceNumber的唯一性. 当用户错误的建立了重复的AgentId时这个值可以用来预防ID冲突。SequenceNumber: Pinpoint agent 生成的ID, 从0开始连续自增;为每个讯息生成一个.Dapper 和 Zipkin, Twitter的一个分散式系统跟踪平台, 生成随机TraceIds (Pinpoint是TransactionIds) 并将冲突情况视为正常。然而, 在Pinpiont中想避免冲突的可能，有两种选择：一是资料量小但是冲突的可能性高，二是资料量大但是冲突的可能性低。Pinpiont选择了第二种。
字节码增强，无需程式码修改
前面我们解释了分散式事务跟踪。实现的方法之一是开发人员自己修改程式码。当发生RPC呼叫时容许开发人员新增标签资讯。但是，修改程式码会成为包袱，即使这样的功能对开发人员非常有用。Twitter的 Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分散式事务跟踪的功能。但是，它要求在需要时修改程式码。我们期望功能可以不修改程式码就工作并希望得到程式码级别的可见性。为了解决这个问题，pinpoint中使用了字节码增强技术。Pinpoint agent干预发起RPC的程式码以此来自动处理标签资讯。
克服字节码增强的缺点
字节码增强在手工方法和自动方法两者之间属于自动方法。手工方法： 开发人员使用ponpoint提供的API在关键点开发记录资料的程式码自动方法： 开发人员不需要程式码改动，因为pinpoint决定了哪些API要调节和开发下面是每个方法的优点和缺点：
Table1 每个方法的优缺点
字节码如何工作
由于字节码增强技术处理java字节码， 有增加开发风险的趋势，同时会降低效率。另外，开发人员更容易犯错。在pinpoint，通过抽象出拦截器(interceptor)来改进效率和可达性(accessibility)。pinpoint在类装载时通过介入应用程序码为分散式事务和效能资讯注入必要的跟踪程式码。这会提升效能，因为程式码注入是在应用程序码中直接实施的。
图3： 字节码增强行为
在pinpoint中，拦截器API在效能资料被记录的地方分开(separated)。为了跟踪，我们新增拦截器到目标方法使得before()方法和after()方法被呼叫，并在before()方法和after()方法中实现了部分效能资料的记录。使用字节码增强，pinpoint agent可以记录需要方法的资料，只有这样取样资料的大小才能变小。
结论
pinpoint是和应用一起执行的另外的应用。使用字节码增强使得pinpoint看上去不需要程式码修改。通常，字节码增强技术让应用容易造成风险。如果问题发生在pinpoint中，它会影响应用。后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
