转载

英国Monzo银行，用K8s管理1600个微服务实践

英国数字银行Monzo两位资深工程师 Matt Heath 和 Suhail Patel 在伦敦一场研讨会上，分享了如何管理1600个后端微服务的经验。这间设立超过 5 年的英国银行，金融用户超过了 4 百万人，去年 9 月开始进军美国市场，目前也正在开发企业用的数字银行服务。Monzo所有金融服务都是通过手机App提供，也因此，他们一开始就决定建立分布式架构，而不是建立一套庞大的银行核心系统。最初采用Mesos来建立容器集群，在2016年时则全面换成了 K8s ，来打造了一个执行各种金融微服务的平台。 Monzo 是少数很早就开始建立K8s的企业，也将基础架构迁移到AWS平台，来减少运维人力。

Monzo使用了容易水平扩展的NoSQL数据库Cassandra，后端系统主要开发语言则是简洁的 Go ，他们的理由是，这个语言保证向下相容，所以遇到语言改版时，例如有次新版增加了垃圾搜集功能，原有代码不用修改，直接用新版Go重新编译后即可执行，就能使用新功能来提高记忆体管理效率。

这是一家喜欢自己开发工具的公司，若有需要连接第三方系统或支付平台时，Monzo都尽可能自制开发整合机制，来提高效率，避免采用第三方整合工具，而带进了许多额外不需要的代码，例如他们就开发了一个互动工具，来连接AWS环境和 K8s 环境，让开发者通过一个pull reques指令，就可以快速进行部署或恢复旧版部署。

在微服务设计上，Monzo将每一个微服务，都跑在一个 Docker 容器中。容器化微服务的代码，还分为两层，一层是所有微服务都必须内置的共用核心代码库层（Shared Core Library Layer），包括了 RPC 、 Cassandra 、锁定机制、 Log 记录机制、监控 Matrics 、 Queuing 等六大类代码库，另一层则是业务层，也就是这支微服务要放进入的代码。

英国Monzo银行，用K8s管理1600个微服务实践

Monzo拆分微服务颗粒度的原则是，进可能地拆解到越细小的程度，他们解释，拆解得越细，可以将变动风险降到最低，例如更新单一功能，能减少对其他微服务的影响。但是，微服务颗粒度越小，代价是会产生大量的微服务。 Monzo 统计，第一年不过数百个微服务，但到了 2019 年 11 月初达到了 1,500 个微服务，甚至去年 12 月更暴增到 1,600 个已上。这些微服务间互相的不重复呼叫超过了 9,300 个。

英国Monzo银行，用K8s管理1600个微服务实践

因为所有服务都在线上，Monzo希望尽可能落实零信任安全制度，因此，采取白名单方式来管控每一个微服务可呼叫的其他微服务名单。起初微服务数量不多时，这份白名单使用人工维护，但是数量达到数千，甚至近万个时，维护工作非常复杂，因此，Monzo决定开发自动化维护工具。

习惯自己开发工具的Monzo先挑了安全管控最严格的一支微服务 service.ledger 来测试，利用 K8s 的网络政策资源，在配置文件中建立一个呼叫白名单。这是一支负责跨帐户移动金钱的微服务。

接着，Monzo开发了一个微服务通讯剖析 rpcmap ，可以自动分析每一支 Go 语言程式，找出对 service.ledger 微服务的所有呼叫来源，来建立白名单。

有了名单之后，Monzo下一步是利用 K8s 的 NetworkPolicy 资源来执行过滤，在 service.ledger 所属的 ledger 服务配置文件中建立网络政策，只有加上可允许标签的网络流量来源才可以放行，并在ledger代码目录中，放入一份授权来源的白名单文件。一旦有其他开发团队想要取得呼叫权限时，就得更新这个白名单文件，并且重新创建ledger服务（因为代码内的档案有异动）后才能生效，ledger开发团队在构建阶段就可以审查这个新增的外部呼叫。

不过，测试后发现了几个问题，多了不少人工审查呼叫的负担，也会提高微服务回复旧版本的风险，再加上开发团队习惯手动编辑配置文件，每一个人都能修改呼叫白名单，而难以管控。后来Monzo决定导入开源的 K8s 网络安控项目Calico，在每一个微服务上建立一个微型防火墙功能，来管理存取。另外， Monzo 也大力提高微服务管理的信息透明度，如自制微服务剖析工具，方便开发团队查询每次代码checkout后，微服务所用 API 的清单和状态信息，并且大量采用视觉化监测工具来追踪流量和用量。

除了工具面的管理机制， Monzo也制作了一份后端工程师 101 指南，要求开发团队第一次撰写后端程序就要开始遵循，内容从新服务建立，RPC处理程序导入、信息查询、如和通过Firehose发布和使用信息、如何撰写单元测试，到如何部署，都有详细的说明和规定，并提供了一个Slack频道来讨论这套后端应用规范的上手问题。 Monzo 要求，每一个开发成员都要遵守这个规范来开发后端的微服务。

Monzo解释，微服务的颗粒度越细，尽管有助提高弹性，但是需要搭配一致的程序架构和工具，通过标准化让工程师聚焦在业务问题，持续改善工具和功能，才能快速进行一系列的迭代修改，来打破大型金融应用的复杂性，又能降低风险。

参考：https://www.ithome.com.tw/news/136462

END

Kubernetes 线上直播班

英国Monzo银行，用K8s管理1600个微服务实践