CNCF案例研究：Linkerd是Apester的“安全网”，可以防止遗忘超时导致的级联故障

MTTR缩短2倍

• 6个月没有超时
• 每月超过200亿的请求流量

行业：软件

地点：美国

云类型：公有

挑战：自动化、可用性

产品类型：托管

使用的CNCF项目包括：gRPC、Kubernetes、Linkerd、Prometheus

挑战

Apester是一个微服务体系结构的交互式内容平台，当开发者忘记对服务到服务的请求设置超时，Apester经历了几次中断，导致整个平台出现级联故障。“在服务级别作为配置而不是代码启用超时是非常重要的。”Apester SRE Or Elimelech说。

解决方案

Elimelech实现了Linkerd服务配置文件用于设置低超时。Elimelech说：“我们可以通过Linkerd强制超时，即使你忘记了。”

影响

Elimelech报告MTTR缩短了2倍：“开发者能够自己发现网格中的坏服务，”Elimelech说：“更容易发现延迟激增的糟糕部署，比如内存泄漏，如果没有Linkerd，我们就看不到这些泄漏。”

下次你在《每日电讯报》或《时代》等媒体网站上进行问答或投票时，你可以感谢Apester的拖放互动内容平台 - 以及它使用Linkerd等云原生技术。

当Site Reliability Engineer Or Elimelech在两年半前来到Apester时，他重建了基础设施来启用DevOps。该公司迁移到GKE，并采用了云原生技术，包括Kubernetes和Prometheus。“我认为大多数采用Prometheus和白盒监控的组织都需要积极推动开发者了解Prometheus，并了解Prometheus的客户端，”他说：“我们使用了几种编程语言，所以我需要可视化和通用的度量系统，可以在生产中使用它们。”

为了寻找一个服务网格，Elimelech首先试验了在alpha阶段的Conduit（“我每周都尝试新的edge版本软件，而不是在我的生产环境中使用的稳定软件！”），当它并入CNCF托管的Linkerd时，他将其用于Apester。他说：“一开始我只是需要指标，现在我很享受其它所有部分。”

其它部分包括解决该公司一直面临的一个重大痛点。使用其微服务体系结构，当开发者忘记设置服务到服务请求的超时，Apester经历了一些中断。Elimelech说：“超时默认为60秒，如果一个服务宕机，当所有依赖于该服务的服务都因为超时而卡住时，将导致整个基础设施的级联故障。”

对于Apester和他们的客户来说 — 更不用说每个人都无法在测验中找到自己的分数 — 这是一场灾难。“我们获得出版商所有的流量，因为我们嵌入到他们的网站，”他说，这个数字是巨大的：每月超过200亿的请求：“对我们来说，在服务级别作为配置而不是代码启用超时是非常重要的。”

在之前工作的公司，Elimelech编写了一个类似于Finagle RPC框架使用的库，Linkerd 1.x就是基于这个框架建立。“所有开发者都可以导入和使用它，所以它是透明的，”他说：“它为你提供服务发现、超时和重试，而不是破坏所有的东西。当你达到一定的规模时，你必须采用这样的方法，因为人们会一遍又一遍地忘记添加这些东西。它是乏味的。我们相信自动化。”

“Linkerd正在把开发者的注意力转移到业务逻辑上，而不是一些技术上。它让部署和开发变得更容易、更快，而且你有一张安全网。” - Or Elimelech，Apester SRE

因此，为了解决Apester的问题，Elimelech实现了Linkerd服务配置文件来设置较低的超时。“现在，新的开发者只需要添加API调用，而不需要为重试和超时添加逻辑，”他说：“我们可以通过Linkerd强制超时，即使你忘记了它。不需要部署新版本，只需更改配置文件并应用它，就可以立即获得它，而无需部署，也无需更改代码。”

Linkerd在多个方面都节省了时间。

服务网格“帮助你分离网络逻辑，因此有更短的迭代，开发者可以专注于功能本身，”Elimelech说：“这让开发者的注意力转向了业务逻辑，而不是一些技术细节。它让部署和开发变得更容易、更快，而且你有一张安全网。”

因为Linkerd与语言无关，“你不需要为Java堆栈和Node以及Go和Python提供相同的库，”他补充说：“你只有一个边车（sidecar）容器，它接管了所有的网络，并且以一种透明的方式运行，而不用用许多语言反复编写相同的库。”

另外，MTTR短了2倍。“开发者能够自己发现网格中的不良服务，”Elimelech说：“更容易发现延迟激增的糟糕部署，比如内存泄漏，如果没有Linkerd，我们就看不到这些泄漏。”

“我们可以通过Linkerd强制超时。即使你忘记了它，你也可以立即获得它，无需部署，无需更改代码。” - Or Elimelech，Apester SRE

接下来，Elimelech开始使用Linkerd和Kubernetes操作器Flagger实现灰度（canary）部署。他表示：“他们将非常有助于部署新软件，并利用生产流量对其进行测试，而无需为每个人都开启新的部署。”

当被问及是否有什么最佳实践可以分享时，Elimelech简单地说：“这是一个非常容易使用的产品。搬到Linkerd，你会很高兴的。”

Apester的确是这样。每月数十亿通过Linkerd的请求，他说：“我们已经六个月没有超时。”