我们在$名人公司改用$HAMED_TECHING

2020-05-12 01:40:24

当$FAMEED_COMPANY在2010年推出时,它只在$Techbro_Founder车库的一台服务器上运行。从那时起,我们经历了风险投资的爆炸性增长,今天我们拥有来自世界各地的数亿日活跃用户(DAU),他们通过我们的移动应用程序和$Famouscompany.com访问我们的产品。自那以后,我们对后端进行了几次恐慌引发的更改,以管理我们的技术债务(通常是在一次备受瞩目的停机之后),以防止我们的服务器崩溃。这些年来,我们现有的技术堆栈为我们提供了很好的服务,但随着我们寻求进一步发展,很明显,完全重写我们的应用程序将以某种方式防止我们每年在客户获取上损失20亿美元。

正如我们在之前的博客文章中提到的,$FAMERED_COMPANY后端历来都是用$NOPARICAL_LANGUAGE开发的,并且架构在$PARICAL_OPEN_SOURCE_framework之上。为了满足我们的独特需求,我们设计并开源了$AN_ENGINEER_Take_A_Mythology_CLASS,这是一个针对$UNSPECTIONAL_LANGUAGE的高可用性、即时编译器。然而,即使使用我们的自定义运行时,我们最终也开始在第99个百分位延迟统计数据中看到零星的峰值,随着我们扩展以处理不断增加的DAU计数,这个峰值变得更加明显。幸运的是,我们所有的软件都是为自省而重新设计的,并且使用我们从Brendan Gregg网站复制的一些BPF脚本,我们的内部分析工具$FAMERED_COMPANY工程师确定性能瓶颈是花费在垃圾收集器上的时间造成的。

最初,我们尝试处理一些我们并不真正理解的垃圾收集器参数,但令我们惊讶的是,这并没有神奇地解决我们的问题,所以我们完全禁用了垃圾收集。这增加了我们的内存使用量,但是我们的自动按需伸缩器为我们处理了这一点,如下图所示:

然而,最终,我们决定转行的原因是,尽管美国数十所大学都在教授这种语言,但我们很难用平凡的语言招聘新的人才。我们在$Practical_open_source_framework上发表的博客帖子在Reddit上也得到了较少的好评,这巩固了我们的信念,即我们的技术堆栈现在是遗留代码。

我们知道我们需要找到一些能跟上我们名牌公司规模的东西。我们根据他们的网站上有多少项目符号,他们在黑客新闻头版出现的频率,以及我们让办公室人员填写的重要语言特征(性能、效率、社区、易用性)的电子表格,对我们选择的一些有希望的替代方案进行了评估并进行了排名,这些项目符号在他们的网站上有多少个项目符号,他们出现在Hacker News的首页上的频率有多高,以及我们让办公室里的人填写的重要语言特征的电子表格。

因为我们的电子表格满足随机性的强大统计保证,所以我们能够重用它来替换我们应用程序的CSPRNG。

经过仔细考虑,我们决定重新设计我们的平台,使用$flashy_language和$hashed_technology。根据Stack Overflow开发人员调查,$FLASHY_LANGUAGE不仅很受欢迎,而且是跨平台的;我们也在使用它来重新实现我们的移动应用程序。重写我们的核心基础设施相当简单:由于我们拥有的工程师超过了我们可能需要的数量,甚至不知道该怎么做,我们只是冻结了处理错误报告,转而将精力转移到$HUPED_TECHING上。我们最初在适应$flashy_language的一些怪癖时遇到了一些困难,并且遇到了一些$hashed_technology的错误,但总的来说,它们强大的新功能让我们消除了以前的解决方案必须处理的一些复杂性。

在不停机的情况下部署更改需要一些仔细的计划,但这也不太困难:我们只需将状态页面硬编码为每当我们推送新更改时不更新,让用户猜测我们的服务是否启动。管理增量部署是关键:我们对新代码进行了积极的A/B测试。我们的内部研究表明,偶尔向用户展示一个全新的界面,然后在他们下次加载页面时切换回旧界面,这会增加用户参与度,所以我们确保根据我们发现的与多武装土匪有关的媒体文章来实现这样一个系统。

随着我们的重写现在已经完成,并向我们所有的客户推出,我们认为这一努力对我们和我们的团队来说是一个巨大的成功。我们已经测量了我们的性能,您可以看到以下结果摘要:

重写后,对我们重要的每个指标都大幅增加,我们甚至确定了一些不再与我们相关的指标,例如错误数量、用户挫折感和维护成本。今天,我们将在我们的GitHub页面上提供一些我们负担得起的开源代码。它本身毫无用处,并且与我们的基础设施紧密相关,但您可以将其加星以使我们看起来更相关。

人们经常说,完全重写软件充满了风险,但我们$FAMONED_COMPANY喜欢下大赌注,很明显,这一次获得了丰厚的回报。虽然我们在这篇博客文章中关注的是后端更改,但正如我们之前提到的,我们也在移动应用程序中使用$FLASHY_LANGUAGE,因为我们没有资源为每个平台编写本机应用程序。不幸的是,增加锁定,这些重写也意味着我们将不推荐第三方API访问我们的服务。我们知道我们的一些用户出于可访问性的原因而依赖这些界面,但我们$FAMERED_COMPANY致力于改善我们为残疾人提供的服务,只要你不使用任何形式的辅助技术,而这些技术根本不再适用于我们的应用程序。

我们希望您将我们公司的轶事内化为某种基本事实,并将其展示给贵公司的CTO,这样他们也可以考虑重新设计他们的架构,就像我们所做的那样。我们知道你会忽略这样一个事实,即你不是我们,我们有足够的工程师和资源可以做任何我们想做的事情,但这个决定会毁了你的初创公司,所以我们不会很快看到你的博客帖子,讲述你使用$HAMED_TECHING的经历。如果你不能影响你的公司使用什么,你仍然可以在下一次语言战争发生时提出来计分。

如果您正在阅读这篇文章,并且像我们一样对$HAMED_TECHING感兴趣,我们正在招聘!请务必查看我们的工作页面,那里将没有与$FLASHY_LANGUAGE相关的职位。