自己做的狗食自己先吃_新版本的灵魂：吃我们自己的狗粮

自己做的狗食自己先吃

任何花时间在软件开发上的人都可以见证这种情况，即某些主要版本的升级已成为利益相关者的噩梦。 大型发布通常会被推迟，或者没有某些重要功能的发布； 新发布的软件经常布满错误。

在本文中，我将描述我们在Plumbr上使用的两种技术，以成功发布对Plumbr Java Performance Monitoring解决方案的主要升级，而不会被常见的火灾烧死。

成功的基础建立在两个主要Struts上：

• 持续交付：主要版本在构建它的整个月中都没有驻留在某个单独的代码分支中。 相反，我们的下一个重大更改不断合并到Mercurial默认分支中，并每天发布到生产中。
• 吃我们自己的狗粮：我们使用Plumbr来监控自己的Plumbr释放。 通过持续部署生产变更来监视我们自己的Java虚拟机，可以在整个开发周期中为我们提供快速的反馈流。

现在，我们将讨论这两个Struts。

持续交付

即使不断地在生产中部署该应用程序的新版本，也对我们的客户隐瞒了几个月。 它部署在相同的VM上，嵌入在相同的WAR文件中，并且在很大程度上甚至可以访问与面向客户的应用程序相同的数据结构。

向用户显示哪个版本的Plumbr的决定是基于对用户是否存在一个特定角色的检查。 如果存在角色，则用户可以访问新版本的Plumbr。 如果不是，则将它们定向到当时的版本。

路由用户可能是最容易实现的部分； 更加棘手的是弄清楚如何在数据结构中支持两组不同的需求。 在我们的案例中，需求的差异非常明显，足以（似乎）表明某些数据结构需要不同类型的存储。

回想起来，事实证明该问题的解决方案确实很优雅。 设计新的数据结构后，我们将现有数据迁移到新的数据结构。 迁移之后，我们代理了所有写操作，以将数据插入旧数据结构和新数据结构。 这产生了两个数据集，一个数据集支持应用程序的先前版本，另一个数据集接受来自新解决方案的读取。

接下来的事情是每个开发人员的核心，即API设计。 由于我们已经通过API在前端和后端之间达成了明确的合同，因此我们只需要提供API的版本2。 新解决方案的API与以前的版本完全脱钩，基本上提供了两种不同的数据视图。 这种方法使我们能够逐个构建新功能，同时通过即将弃用的API支持以前的版本。

从现在开始，这已经是一场艰苦的战斗。 我们需要做的就是逐一交付API的实现，并将新功能日复一日地发布到生产环境中。

该产品很快就达到了“功能完整”，在发布前一个月，我们已经可以在内部使用它，甚至可以访问一部分客户。因此，除了在技术上令人满意之外，该方法还可以对解决方案进行顺利的验证。一路上。

监控表现

成功发布的第二个Struts是通过我们称为“元解决方案”的情况得以实现的，这种情况是当您构建可用于监视自己的服务的监视解决方案时发生的一种“爱丽丝梦游仙境”悖论。

为了让您知道这对我们有何好处，让我用几句话描述我们正在构建的解决方案。 Plumbr旨在检测应用程序中缓慢且失败的用户事务，并自动将此类事务链接到源代码中的根本原因 。 构建这样的解决方案意味着将测试新代码（尤其是性能测试）的任务减少到处理由Plumbr（监视Plumbr的实例）触发的警报，并修复在开发过程中出现的根本原因。

为了让您对解决方案有所了解，以下是Plumbr生产部署中监控我们自己的服务的屏幕截图。 屏幕截图是在我们收到有关生产性能下降的警报之后拍摄的：

我们立即注意到异常高的交易数量（准确地说是1,836个）比SLA所确定的要慢。 与通常的情况（其中只有少数事务会被标记为缓慢）不同，我们面临将近1％的事务完成速度比根据SLA所允许的慢。

适应了宏观影响之后，我们需要确定应用程序中遇到的功能。 Plumbr按事务消耗的端点（称为“服务”）对事务进行分组。 例如，我们知道我们的某些应用程序事务访问URL / account / 12jk112 / services和/ account / 92as982 / services。 这些事务使用相同的功能，并在同一服务下自动分组在一起。 通过检查服务列表，我们立即发现一个事实，即1,836个慢速事务中的绝大多数都在使用单个服务：

在这段期间内，Plumbr监控的182项服务中， ServiceController.getAccountServices（）是导致93％的慢速交易的服务。 在1,836笔慢速交易中，有1,710笔正好在使用此服务，提供了上面屏幕中显示的列表内容。 因此，这里有一个示例，它说明了软件监视自身并检测自身中的错误的情况……

但是，最甜蜜的地方仍然是点击几下。 当我们打开服务详细信息视图时，再次显而易见的是，由于Plumbr监视并公开了一个昂贵的JDBC操作，所有这1,710个事务都很缓慢：

从上面我们可以看到，由于特定的JDBC查询的构造不正确，特定的服务确实速度太慢了1,710倍。 从这一点开始，这很容易-既让问题查询又在源代码中构造了查询的行，我们立即修复了该问题。

通过我们的发行积压工作，我目前可以算出不少于57张票（总共480张票），这是由于使用Plumbr监视Plumbr而创建和解决的。 我们的软件监视JVM的各种性能问题，我们发现了几乎所有东西，包括许多昂贵的JDBC操作，少数锁争用问题以及处理不当的异常和GC暂停的负载。 我们甚至遇到一次OutOfMemoryError。

除了消除错误之外，在三个月内吃掉我们自己的狗食还会导致产品反馈环路极为紧张，进而对产品本身进行了几项重大改进。 例如，一项新的Plumbr功能提供了为上面准备的JDBC语句配备精确的查询参数的能力，从而导致性能下降。 如果您检查数字，则使用该服务的交易中95.2％的交易仍然表现良好，这意味着根本原因只有在满足某些条件时才会暴露出来。

一切都很慢

我们以令人难以置信的速度前进。 这太好了，难以置信，确实有一个问题在路上，只是在等我们的脖子。 如果您还记得，对新版本的要求似乎表明需要一种完全不同的存储类型。 对于我们的技术人员来说，这真是个了不起的消息，因为我们必须使用闪亮的新事物。

这次闪亮的新事物是特定的NoSQL数据库。 在对新数据结构进行几周的代理写入后，生产应用程序的性能开始下降。 尽管我们不断进行优化尝试，但每天情况都在不断恶化。

发布前七个星期，很明显继续使用该技术将使整个版本面临风险，因此我们成立了SWAT团队来构建另一个后端，这次使用的是老式的关系存储解决方案。 这意味着在代理后面添加另一种存储技术，然后将写操作定向到最终用户使用的当前存储，我们仍在尝试优化的NoSQL存储以及SWAT团队正在快速构建的后备解决方案。

经过一个日历周之后，我们站在了一个决策点：NoSQL还是关系式在比较经过几个月构建和优化的noSQL解决方案与快速而肮脏的关系后端的性能时，很明显，即使在其过早和未优化的状态下，关系存储仍然存在

再过一个日历周，我们对NoSQL的努力的最后余留就从代码库中移走了，该项目又回到了正轨。

感觉很好

这两种方法的结合导致了我在软件行业15年的职业生涯中从未遇到过的情况。 在我生命中最大的释放前整整十个小时，我盯着JIRA积压的订单，不相信自己的眼睛。 积压工作中剩余的唯一任务称为“发布”。

没有错误，没有任何待处理的功能，没有开发人员渴望在办公室里睡一会儿，只有我坐在那里刷新积压的订单，仍然不相信我的眼睛。

显然，这种情况非常罕见，以至于我们保留积压工作的JIRA决定输入“嘿，该用户必须是新手，因为他的积压只剩一张票了”模式，并开始为我提供各种额外的工具提示和帮助标语：

你们中许多构建较少元解决方案的人可能无法完全按照我们的相同方式来实践您的讲道。 但是我确实相信，不断发布解决方案以生产以及从这些生产版本中吃自己的狗粮的这两个概念可以使您的压力减轻很多。

翻译自: https://www.infoq.com/articles/The-Soul-of-a-New-Release-Plumbr-Eats-Our-Own-Dog-Food/opicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

自己做的狗食自己先吃

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览33847 人正在系统学习中 相关资源：锁屏 自动锁屏 定时锁屏 注销软件

来源：cunfu6353