性能VS可靠性：为什么Java程序像F1赛车

原作者：Steve Burton - April 20, 2016
原文链接
译者：Lulu_zhu-April 28, 2016

思考应用性能和可靠性是相同的吗？三思。

性能和可靠性是相关的吗？还是说这两者是相互对立的呢？我认为是后者。然而当下的现实情况是，IT从业者把应用性能和可靠性视为同一件事，这差事实十万八千里。

让我们来看下方程式赛车团队是如何处理性能和可靠性的吧。

上个赛季，迈凯伦-本田车队表现得既慢而不可靠。而法拉利在这个赛季的排位赛变快了，但在比赛中仍是不可靠的。而在另一方面，梅赛德斯在过去两年中依靠着速度越来越快和越来越可靠的性能，秒杀群雄。

性能

一辆F1赛车的性能显著得受三方面影响-发动机组，引擎和空气阻力/下压力。

发动机控制参数图可以显示发动机组消耗的可用资源（包括进气量，油耗和电耗。通过管理赛车周围的气流可以描述空气阻力/下压力。

更强大的动力和小阻力意味着更少的阻力，更快的加速度和更高的最快时速。

更强的下压力意味着赛车随之在弯道会有更强抓地力和更快的速度。对于F1赛车来说，性能就是赛车能以多快的速度绕一圈赛道。F1团队可能会在特定的周末对赛车的设置做上百种调整，希望赛车每十分之一秒开启超性能，跑赢其他竞争者。

类似的，程序性能显著得受三方面影响：JVM runtime，应用程序逻辑和业务流程。

应用程序逻辑消耗JVM runtime中的资源（包括线程，CPU，内存等），业务流程图展示了每个业务流程和基础构件或者第三方web services的交互。

性能是关于终端用户请求（页面/会话）的时机和应用逻辑和业务流之间的端对端的延时协议。开发者就像F1引擎，为了优化终端用户的体验以及商业效益，会做出上百种变化。

描述性能的首要单位是反应时间，同样地，当需要管理反应时间的时候，像AppDynamics，New Relic和Dynatrace应用性能监视器方案就是老大哥了。

可靠性

一辆F1赛车显然是受工程部件质量，电子控制单元和传感器上百万临时输入，参数和方法的影响。

遇到一些意想不到的因素，赛车会立即停止。去年Nico Rosberg就发生过两次，他的方向盘和电动转向在赛事中锁死，然而仍以些许优势成为最快的赛车。

诊断一辆F1赛车的性能是不同于诊断其的可靠性，它们是稍微不同的用例，需要不同的遥测，工具和角度。

相对于为什么跑得慢，可靠性帮助理解为什么会坏了。

对于应用程序则是同样的，当且仅当程序奔溃的时候，这是因为程序在某处出错了，产生了一个错误或者一个可抛的异常。这和程序运行缓慢是十分不同的。

应用程序获取输入数据，处理数据然后产生某些输出数据。像F1赛车，应用有成百上千的零件（方法），上百万行的代码，每一行在同一时间内处理一些参数（对象和变量）。性能和可靠性是相关的。日志文件里面包含了错误和异常信息。

Q：航班的缓慢搜索或多或少比航班预定失败重要吗？

A：它们都会让你丧失生意，所以需要把它们都解决。

欢迎来到垃圾数据的世界

假设那些APM解决方案很高效的管理好了性能。我们的行业仍然相信，日志文件（或者某些供应商称之为大数据）可以用来研究应用程序崩溃的原因。实际上，我认为这一方法更像垃圾数据。

对于想要找到程序崩溃的根本原因，日志文件缺少深度，上下文语境和说服力。当然，有日志文件总比没有好。让我们来看下，对于一个想要持续找到根本原因的开发者来说，需要什么数据：

程序堆栈轨迹-表明程序奔溃的部分（类/方法）
程序源码-表明哪一行代码导致了奔溃。
程序状态-表明被组件和源码处理的程序参数（对象，变量和值）

现如今的大部分日志文件包含了上百万行的程序堆栈轨迹。这也就是为什么Splunk 值6百万美刀的原因，因为每一个复制的堆栈需要花费$$$去解析，索引，存储和搜索。

是的，开发者们可以定制自己想要的程序日志。坏消息是，因为系统开销和创建有意义的日志通常需要了解在程序中奔溃的地方，所以开发者们不可能记录下所有信息。

不通过预测是不太可能生成有效高效的日志文件的-所以开发团队仍然花费大量时间大海捞针。没有程序源码或者程序状态意味着操作和开发就得靠猜了。这是很糟糕的。

不幸的是，光有堆栈轨迹并不足够。这就像在F1中，Mercedes修理加油站的伙计高速他们的工程师“我们的遥测刚确认Nico的方向盘坏了，我们只能确认这个-请你们弄清楚是为什么，然后尽快修理好”

你能想象工程师会怎么想吗？不幸的是，这也是大部分开发者们现如今遇到程序奔溃时的想法。

好消息是，现在已经可以在生产中弄清楚程序在什么时候和因为什么原因奔溃了。欢迎了解Takipi。

不可能现如今已经成为可能，日志文件已经穷途末路了。

Steve