数字银行N26在拓展地理区域上的挑战和教训

N26 是一家数字银行，为了在美国、巴西等全球区域上拓展银行平台，N26 在架构中引入了针对地理区域配置的新层，支持产品开发团队在该层上添加应用特定需求。 在 FlowCon 法国大会上，Kat Liu 介绍了 N26 在引入该层的考虑和做法、所带来的好处，以及其中的经验教训。

Liu 指出，为构建适用于欧盟和美国的银行产品，需顾及大量的法律法规。例如，美国的数据必须存储在物理上位于美国的数据中心，并且必须与欧盟的数据完全隔离。这通常需要在每个区域全新构建一个功能完备的区域数据中心，部署共享服务，并将服务请求路由到正确的数据中心。

考虑到新区域部署类似于新环境构建，N26 重点关注如何尽可能实现配置对应用的非透明，以及如何从共同的 SRE 团队中剥离某些应用特定配置。由此，N26 提出了一种新的解决方案，就是在传统的“应用层”和“基础架构层”之间额外创建一个新的层。

Liu 在演讲中提到，N26 实现在新层中添加数据库主机、AWS 资源、AWS 权限等所有配置，这为产品开发团队添加自己的应用需求提供了更多自由。她说，该层负责获取区域和环境，选择正确的配置，并将其提供给上一层。

在 Liu 看来，虽然新层对于配置应用存在一定的学习曲线，但它最终可为开发团队提供更大的自治权，使他们无需协调 SRE 就可更改应用配置，这样 SRE 可以更专注于整体环境的稳定性。Liu 说，这一改进实质上已涵盖任何需要服务与外部系统的交互，包括对新的 S3 存储桶添加权限、在流上创建新主题等，

不应将基础架构和配置管理视为仅应由 SRE 负责的工作。对此，Liu 给出了如下阐释：

开发人员和SRE间的接口在应用中所处的层中，会低于我们的通常的设想。一旦接受这一事实，团队就有很有机会去提高生产力。在我看来，这就是人们常说的“DevOps”的核心所在。该理念就是确保系统顺利运行时每个人的工作职责所在。开发人员不会因应用所依赖的问题卡在那里，而会深入探查其中原因，授权去解决问题。

Kat Liu是 N26 认证团队的高级软件工程师，她在FlowCon 2019法国大会做演讲，介绍了 N26 的架构、为美国区域提供的服务中所面对的挑战、如何实现适合 N26 业务发展的新层，以及如何实现代码与配置的分离。InfoQ 此后专访了 Liu。

InfoQ：您能介绍一下 N26 所采用的架构吗？

Kat Liu：作为一家相对年轻的公司，N26得以利用现代技术栈。我们在生产系统中运行了100多个采用各种语言和框架的微服务，其中以Kotlin、Java和Spring Boot为主。每个微服务通过HashiCorp Nomad实现容器化和管理。主要采用连续部署方式，每次归并都会在部署前通过严格的自动化测试。

InfoQ：为美国区域提供产品和服务，N26 面对着什么挑战？

Liu：我们面对的更改对应用配置有着巨大的影响，并且由于它正位于开发和DevOps团队之间，所以非常难以界定两个团队间的职责。

开发团队需要SRE团队将其所有应用依赖项全部迁移到新区域，包括数据库、队列、s3存储桶等。但这只是产品启动和运行所需的部分工作。

SRE团队是作为一个独立团队运行的，有自己的待办事项，对后端团队的全部应用特定需求了解不多。这样在新区域中运行后端服务时，SRE团队会成为一个严重瓶颈。

InfoQ：N26 的规模正在快速增长。增长对于扩展新领域有何影响？

Liu：我们提出的解决方案非常适合N26现有的规模扩展。在发展早期，我们的团队和服务相对较少，因此尽可能将所有应用配置工作交给SRE团队。一旦我们意识到在新区域的服务部署速度上存在瓶颈，我们就着手实施该额外层，实现新服务的迭代部署。

InfoQ：您在演讲中提及，新区域只会影响配置，而不会影响代码。对此您能详细解释一下吗？

Liu：在部署各个环境时代码不会发生更改，或者至少是不应该发生更改。更改的只是配置变量，例如数据库主机URL、需与第三方环境通信的API密钥等。

最佳实践是分组一并更改的逻辑，共置一处，并将这些更改与在相同情况下不会发生更改的其它逻辑组做相互隔离。 否则，我们可能会无意中影响到本不应该发生更改的内容，反之亦然。而且当这种情况发生时，我们会看到应用的配置矩阵规模激增。因为应用需要获取所有环境参数，并自主决定要选择哪种配置。

这也使得一切变得难以管理和组织。我们并不会将袜子和内裤放在叉子和刀子应该在的位置，难道不是吗？相同的原则，同样适用于软件开发。

InfoQ：额外针对区域新建层，对你们的部署过程有什么影响？

Liu：如果没有此层，开发人员将不得不等待SRE团队数日，甚至长达几周的时间，以协调新数据库、流主题或任何外部服务提供新的基础架构或权限。由于新层为团队提供了自主配置管理更改的技能，我们已看到反馈周期显著缩短。团队拥有更多的流程，因此能够更快地采取行动。

原文链接：

Scaling Infrastructure as Code at Challenger Bank N26