【翻译】在动态基础上构建容错的应用堆栈

作者：马克-斯瓦布里克 2022年1月6日

作者：Bink公司基础设施主管Mark Swarbrick的特邀文章

通过Linkerd为英国一些最大的银行的数字忠诚度交易提供动力

Bink是一家位于英国的金融科技公司，他们的使命是重新想象忠诚度计划。由于少了很多麻烦，奖励对每个人来说都应该更容易--银行、商店和喜欢购物的顾客。这就是为什么我们建立了一个工具，在人们每次购物时识别忠诚度积分，通过简单的点击将购物与奖励计划联系起来。

为了实现这一目标，我们需要建立一个可扩展的平台，让银行从安全和责任的角度接受。在绿地上，我们利用多个CNCF项目，包括Kubernetes、Linkerd、Fluentd、Prometheus和Flux，建立了一个高性能、可扩展、可靠和安全的技术栈，同时减少了由瞬时网络问题引起的应用问题。在这篇博文中，我想分享一下Bink是如何实现的。

Bink的背景故事

Bink的每个人都有多年的银行、零售和忠诚度计划方面的第一手经验。我们了解银行业的机会，特别是在改造忠诚度计划的同时确保其对零售业产生积极影响。

2019年，巴克莱银行认识到我们产品的巨大潜力，并承诺对我们的业务进行大量投资。由于这种伙伴关系，Bink现在可以为英国数百万巴克莱银行的客户提供服务

像大多数初创公司一样，基础设施主要由一个人建立。预算很紧张，但我们知道我们必须建立一个可以与公司一起成长的东西。三年过去了，一个由三人组成的团队正在支持我们的内部构建的平台，能够每天处理数百万的交易--这是云原生生态系统的惊人技术的真正证明

Bink团队、基础设施和平台

我与Chris Pressland和Nathan Read一起在平台团队。今天，我们运营六个Kubernetes集群。其中两个是专门用于生产的多集群设置，每个集群承载着大约57个不同的内部构建的微服务。所有操作都在微软Azure中运行，有多个生产和测试环境。

最初，Bink有三台裸机Ubuntu 14.04实例上的网络服务器，在NGINX实例后面运行少量的uWSGI应用程序的负载平衡 - 没有任何形式的自动化。

2016年，Chris受雇开始将Bink的应用程序转换为Docker容器，并摆脱现有的将代码SFTP到生产服务器和重新启动uWSGI池的方法。为了实现这一点，我们在Chef中建立了一个容器协调工具，动态地将主机端口分配给容器，并更新NGINX的proxy_pass块以通过流量。这工作做得很好，直到我们意识到Docker在我们老化的Ubuntu 14.04基础设施上引起了许多内核恐慌和其他问题。

大约在同一时间，我们得到了正式批准，评估从我们的数据中心迁移到云端--我们的需求已经远远超过了数据中心所能提供的。作为微软365的客户，我们决定使用微软Azure。我们也很快得出结论，从长远来看，维护我们自己的容器编排器是不可持续的，并决定转移到Kubernetes。当时，微软没有一个符合我们要求的Kubernetes产品，所以我们又拿起了Chef，编写了自己的产品。

转移到Kubernetes并寻找一个服务网状结构

至少可以说，我们在内部运行Kubernetes发行版的前几年是痛苦的。这主要是由于微软在当时不稳定的网络基础设施。随着时间的推移，情况大大好转，但在最初几年，我们看到大量的随机TCP断开，UDP连接丢失，以及其他随机故障。

2017年左右，我们开始研究服务网格，希望它能帮助解决，或至少减轻一些问题。当时，Monzo工程师在KubeCon上发表了关于他们最近经历的故障和Linkerd所扮演的角色的演讲。不是每个人都对这些事情透明，我真的很感谢他们分享所发生的事情，这样社区就可以从他们的失败中学习--对Monzo团队这样做大加赞赏!就在那时，我们开始研究Linkerd。维护者即将发布一个新的Kubernetes原生版本，叫做Conduit，很快就会改名为Linkerd2。

我们也曾短暂地考虑过Istio，因为业界大部分人似乎都倾向于基于Envoy的服务网格。然而，在相当短的实验之后，我们发现Linkerd真的很容易实现。不需要写应用程序代码来处理瞬时的网络故障，而且延迟非常小，值得在堆栈中增加一跳--它给我们带来的可追溯性也是非常有价值的。简而言之，Linkerd完美地适合我们的使用情况。

看吧，当我们开始在非生产集群中试验Linkerd时，由Azure基础不稳定性引起的网络故障明显减少。这给了我们信心，将Linkerd添加到我们的生产工作负载中，我们看到了类似的结果。

Linkerd的服务网差异

将我们的软件堆栈迁移到云端原生平台上是一个简单的问题。然而，架构的某些部分并不像我们所希望的那样具有性能或稳定性。Linkerd使我们能够在堆栈的正确层面上实现连接和重试逻辑，给我们提供所需的依赖性和可靠性。突然间，关于我们是否能在云中使用我们的软件堆栈而不需要大幅提升的问题已经消失了。Linkerd表明，将逻辑放在连接层是正确的方法，使我们能够专注于产品创新，而不必担心网络或连接不稳定。这确实有助于降低运营开发成本，缩短上市时间。

最终，Linkerd从技术和业务的角度大大改善了事情。我们刚刚开始与巴克莱银行进行对话，并需要证明我们能够扩大规模以满足他们的需求。Linkerd给了我们信心，使我们能够采用可扩展的基于云的基础设施，因为我们知道它是可靠的--任何网络的不稳定性现在都由Linkerd来处理。这反过来又让我们同意了一个基于延迟和成功率的服务协议。Linkerd是我们监测内部SLO和跟踪我们软件栈性能的正确位置。

我们不想增加一个内部基础设施，也不想重构我们的代码来部署重试逻辑。Linkerd提供了所需的指标来快速实现这一目标，同时帮助我们在云原生环境中追踪平台瓶颈。

云原生的力量

从整个堆栈来看，云原生技术--尤其是CNCF项目--使我们能够建立一个与云无关的平台，可以根据我们的需要进行扩展，同时密切关注性能和稳定性。我们已经对我们的平台进行了负载测试，可以在15分钟内进行全面的灾难恢复，从短暂的网络问题中轻松恢复，并且能够快速有效地进行问题的根本原因分析。

准备撼动英国银行和忠诚度计划

在Bink，我们必须迅速发展和成熟我们的基础设施，以满足银行安全、稳定和吞吐量的要求。云原生技术使我们能够自信地支持和监测合同的SLA和内部SLO要求。这使Bink能够很好地利用零售空间的重新开放，并帮助零售商与英国银行业的一些大公司合作，实现支付链接的忠诚度。