APM(Application Performance Management)经过2-3年的发展早已经被大家所熟悉了，当Google的Dapper刚发表的时候，就有一大批的公司和组织进行了产品化，大家熟悉的淘宝的鹰眼、点评的Cat、OneAPM等都是这方面的先行者。随着SOA和微服务的普及，越来越多的公司采用了这样的分布式架构，因此对APM的需求更是越来越强烈。本篇文章首先会简单阐述下Dapper的思想，然后会简单阐述下笔者自研的Dragon和放弃它的原因，最后阐述下Pinpoint架构。这篇文章主要的目的，一是记录研发的心路历程，二是希望为那些未做但想做的同行提供一点经验教训。

最近研究避免分布式事务，有幸读到David Syer于09年发布在JavaWorld的HOW-TO
Distributed transactions in Spring, with and without XA，虽然文章和测试代码都老了点，但是思想不变。

Full XA with 2PC

如果需要近乎完美的防护，2PC绝对是不二之选，但是它的性能损耗是显而易见的，这也是为什么大家谈分布式事务而闻之色变的原因。此处我们不谈性能，只谈Spring是如何支持2PC XA的。Spring为我们提供了JtaTransactionManager和声明式事务，将复杂的同步细节进行了托管。我们只需要关注DataSource的配置，例如通过开源的JTA实现Atomikos来配置DataSource。

XA with 1PC Optimization

1PC可以看做是单一事务资源下2PC的的优化版本，许多的事务管理器通过这种模式来优化2PC的过度开销。但是并不是单一事务资源，就表示一定走的是1PC，因为XA事务管理器会根据通讯时间的长度，来判断网络通讯的危险期，即使连接一个数据库也应该使用两阶段提交，如果通讯危险期很短，多个事务资源也有可能使用一阶段提交。

最近几年层出不穷的安全漏洞，再一次要求大家提高安全意识。安全是很大的一个话题，下面是我平时工作总结出来的一些安全方面的经验。

关闭错误显示

很多网站不知道是运维人员的业余还是疏忽，网站的错误显示没有关闭。攻击者只需要通过调整参数，就可以获得错误的堆栈信息，从而推断出网站使用的相关技术栈，从而为后面的攻击大开方便之门。

2016农历新年假期前1个小时，心思已不专注，随意一写，简单回顾自己的2015！

工作

如果用一个词来形容2015的工作表现，我觉得波澜不惊应该最为合适。没有大风大浪，没有力挽狂澜，工作按照原有节奏和既定部署开展。在没有重大项目的情况下，我们将大量的精力放在了系统架构升级和业务逻辑优化上面。机票核心系统经过2年的快速迭代和人员的变更，已经有了较多的技术负债，确保系统稳定的前提下并进行技术改造是我们面临的主要课题。

2014年机票核心模块绝大部分进行了服务化，业务方面带来的好处就是业务划分的更加合理，开发人员更加专注于自己的领域，技术方面就是服务的管理、降级、流控、监控、AB Test等更加容易。14年的成功，让我们对遗留核心业务的改造充满了信心。记忆尤为深刻的是一个PNR解析程序当时7000行的代码，各种业务规则的判断，各种语法分析逻辑，我们优化到不到1000行。这在当时绝对是一件值得骄傲的事情，虽然看似简单的一个类，却承载着公司每天5千万交易量的订单生成和2年的领域知识沉淀，之前这个类是很多人都不敢碰，因为这个风险不是谁都愿意承担的。虽然主导者是我，但是操刀者却不是我，这件事情放在14年绝对不敢想象，因为这种核心的业务我是绝对不放心交给下面的小伙伴的。但事实证明只要给他们机会和时间，他们是能够成长起来的，就如当年我的领导信任我一样。在管理上更加注重小伙伴们的发展，让他们快乐的成长，因为他们唯一能够带走的就是自己的能力。当然15年在对外的业务沟通和对内的技术指导，都更加内敛不再锋芒毕露，毕竟谁会拒绝一个好沟通好相处的同事、下属或者领导呢？

由于工作的变动，16年注定是机遇和挑战并存的一年。从参加工作以来，一直在专注于技术深度的挖掘，在广度的拓展上还需要投入更多精力。16年在做好后端架构本职工作的基础上，更多的是与移动端、web端、测试、运维相互交流学习，创建良好的技术氛围提升公司的技术实力。希望通过这一年的努力，让自己成为一个能够影响他人能够带着大家往前走的人，不仅仅是技术方面。

需求

公司目前的监控粒度非常粗放，只做了些常规的监控，如：服务器的CPU/磁盘/网络，数据库，消息队列，以及一些核心业务的健康检查等。这种粒度的监控对发展初期的创业公司来说已经足够，但是对于接下来的发展便开始捉襟见肘了。个人认为监控不能浮于形式，不是采集一堆数据进行简单的罗列或者生成Dashboard，而是能够通过这些数据产生决策，告诉我们哪里出了问题，该如何解决，甚至自动解决。所以我们要能够自动采集系统中的各种metric，然后各种metric汇集到数据中心进行处理，最后便是展现、报警以及自动修复等逻辑。

分析

关于监控，业界成熟的方案数不胜数，如何从中选择适合自己的解决方案便是其中的难点。确定方案之前，我们首先需要对自己的系统架构进行梳理，确定我们所选方案兼容目前架构。由于我们的系统基本全部都构建在一系列的Java技术栈之上，Zabbix已经广泛应用在各个系统之中，所以我们做了如下的几点约定：

1. Metric的获取只能用Java实现
2. 服务器以及一些中间件的常规监控延续使用Zabbix
3. 报警逻辑使用Zabbix实现
4. 数据能够实现多个维度的自由组合叠加以及横向对比
5. Metric获取的侵入性要非常小

前前后后做的IM和推送系统已经有好几个了，一直都想好好总结下，因此就有了这篇文章。在我刚学编程的那会儿，觉得网络通信是一个很牛逼和门槛很高的一门技术，但是随着开源技术的发展和互联网知识的共享，现在要写出高质量的网络通信程序已经变得容易多了。

只要谈通讯肯定绕不开协议，鉴于本人经验下面只谈本人撸过的三种协议：

1. XMPP
2. MQTT
3. 私有协议

最近对Java的Profiling和Debugging非常感兴趣，特别是对线上问题的定位方案进行了较深的调研和分析。因为在SOA架构体系中线上问题经常在测试环境不能复现，所以问题的定位具有非常大的挑战。我将业界定位问题的工具和方案都大概的研究了一遍，不论是JProfiler、YourKit、BTrace，还是更底层的Serviceability技术……都广泛用到了Agent技术。

问题现象

最近由于业务需求，重写了一套访问中航信IBE+的代理层。由于机票业务分为国内和国际两部分，这两部分都需要访问IBE+，之前是各自为战，各自都有一套访问逻辑。这样做的后果就是在流控(IBE+对QPS有一定的限制)和接口管理方面得不到很好的控制，因此才写了这样的一个代理层。这样的设计其实没有任何问题，在微服务和SOA大行其道的今天这都是主流设计思路。该系统很快便上线了，但是很快我就发现IBE+的服务访问都非常慢，因为之前我没有涉及到这块，我就问了下之前负责这块的同事，他们说的确比较慢，我也就没有太上心。突然有天我打开生产环境的监控，我便发现了问题，大概30秒左右便有一次非常慢的操作。关于30秒的问题，之前我通过tcpdump抓包分析过，以为是Http Basic鉴权导致的，在新写的代理层中已经对此处进行了优化，但是结果看来不是很理想，然后便有了这个Case。

生产环境调试难题

当我们的代码运行在生产环境时，各种千奇百怪的事情都有可能发生，而此时我们已经离开了舒服的开发环境，不能使用自己习惯的IDE来单步调试。当我们生产环境出现问题时，我们需要第一时间知道问题出在哪里。因此我们需要未雨绸缪做好准备，否者等问题发生时才通过漫无目的的查找日志，不但时间成本太高，并且不见得有效。

SOA，分布式，微服务….虽然带来了高可用和可扩展，但是同时也将系统架构的复杂度提升了好几个等级。经常我们会发现一个服务的不可用，是由于例外一个它依赖的服务导致的。持续交付和代码的不断更改，生产环境错误被找到的速度越来越快。然而如今，我们面对更大的困难是当错误发生时，我们如何提取错误的状态，比如变量值，错误，甚至逻辑代码块。

目前主流的解决方案有如下几种:

1. 分布式日志
2. 高级的jstack
3. Btrack
4. 定制的JVM代理

BTrace作为线上问题定位神器，它在侵入、安全、资源占用等方面表现的都非常出色。本文记录了作者平时工作中使用Btrace的场景，以供大家参考。

BTrace限制

关于BTrace的安装配置使用，网络上有太多的教程了，本文就不再重复造轮子了，但是还是非常有必要再次重申BTrace的限制。因为不正当的使用Btrace可能根本拿不到自己想要的结果，甚至导致JVM崩溃，建议脚本使用之前先经过验证，然后再使用到线上环境。

使用Btrace时，需要确保追踪的行动是只读的（即：追踪行动不能修改程序的状态）和有限的（即：追踪行动需要在有限的时间内终止），一个追踪行为需要满足如下的限制：

• 不能创建新的对象
• 不能创建新的数组
• 不能抛出异常
• 不能捕获异常
• 不能对实例和静态方法随意调用，只有com.sun.btrace.BTraceUtils中的public static方法或者当前脚本中申明的方法，可以被BTrace程序调用。
• (1.2之前)不能存在实例字段和方法。BTrace类只允许静态公共void返回方法，并且所有字段必须是静态的。
• 不能将目标程序中的类和对象中的静态或者实例字段指派给BTrace程序。但是，可以将BTrace类自己的静态字段（“trace state”是可以改变的）指派给自己。因为引用的传递可能导致目标程序别修改，而BTrace自身的跟踪字段只有BTrace自己在使用，所以不怕修改。
• 不能有外部，内部，嵌套或者本地的类。
• 不能有synchronized块和方法。
• 不能有循环（for，while，do…..while）。
• 不能继承抽象类（父类只能为java.lang.Object）。
• 不能实现接口。
• 不能有断言语句。
• 不能使用class保留字。