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

2020 年 2 月 11 日

数字银行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


2020 年 2 月 11 日 09:00658

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

Flutter开发环境配置

玉龙BB

flutter android vscode

数据产品经理实战-数据门户搭建(上)

第519区

数据中台 开发数据

线程池续:你必须要知道的线程池submit()实现原理之FutureTask!

一枝花算不算浪漫

源码分析 并发编程

MySQL 可重复读,差点就我背上了一个 P0 事故!

楼下小黑哥

Java MySQL

【Java 25周年有奖征文获奖名单公布!!!】关于Java,你最想赞扬、吐槽、期待的变化是什么?

InfoQ写作平台

写作平台 Java25周年 活动专区

ARTS-01

NIMO

ARTS 打卡计划 ARTS活动

ARTS week 3

刘昱

像孩子一样认识新事物 —— 读《终身幼儿园》

YoungZY

学习 读书笔记 读书

我为什么开始技术写作?

flyer0126

技术创作

Vue生态篇(一)

shirley

Java Vue

美团可能会强势涉足 ToB

罗小布

创业 互联网巨头 深度思考 互联网

知识也会生宝宝?

史方远

个人成长 随笔杂谈

奈学:传授“带权重的负载均衡实现算法”独家设计思路

奈学教育

分布式

Mysql索引不会怎么办?6000字长文教会你

Super~琪琪

MySQL 数据库 sql 索引

ARTS-1

你当像鸟飞往你的山

ARTS 打卡计划

重学 Java 设计模式:实战单例模式

小傅哥

设计模式 编程思维 重构 优化代码

DDD 中的那些模式 — 使用 Specification 管理业务规则

Joshua

设计模式 领域驱动设计 DDD 架构模式

ARTS - Week Two

shepherd

js algorithm

# LeetCode 215. Kth Largest Element in an Array

liu_liu

算法 LeetCode

我的编程之路 -6(新时代)

顿晓

android 编程之路 时代

如何做好Code Review?

flyer0126

Code Review

爬虫框架Scrapy应用实践-淘宝保险频道数据抓取【2】-抓包分析

hadesxiong

Python 爬虫 保险 Scrapy

深入计算机底层,从几本靠谱的书开始

HackMSF

计算机工作原理

那些会阻碍程序员成长的细节[2]

码闻强

程序员 程序人生

眼中有码,心中无码

小眼睛聊技术

学习 深度思考 程序员 最佳实践 算法

每个人都是领导者的工程团队

hongfei

# LeetCode 863. All Nodes Distance K in Binary Tree

liu_liu

算法 LeetCode

你不知道的SSD那些事

焱融科技

分布式 存储 SSD nvme

关爱孩子的心理建设

Neco.W

人生 感悟 教育

5G时代下应用的安全防御研究

Nick

5G 5G网络安全 5G安全

我常用的浏览器插件

彭宏豪95

chrome 效率工具 浏览器 插件

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