银行业微服务实践探索

银行业中的微服务实践

摘要

CCS概念
•软件及其工程~云计算
•软件及其工程~软件即服务编排系统

关键词

微服务、Kubernetes、持续集成/持续交付、DevOps

1 背景

传统银行业已不再传统。社会、经济、监管，以及最重要的技术，都已发生变化，推动了一场可称为“第二次银行革命”的变革（第一次革命是基于计算机的信息系统的引入）。

将人们带到银行网点从来都不容易，但对于新一代而言，这几乎已成为一项不可能完成的挑战。千禧一代已经成年，他们愿意消费银行的产品和服务，但前提是能够“在此时此地立即获得”。

传统零售银行无法忽视新的全球数字消费者经济。“金融科技公司”已抓住这一机遇，通过数字渠道以极低的成本甚至免费提供产品和服务，并利用附加服务实现盈利。

这促使监管机构改变游戏规则，关注零售消费者需求以及在发展缓慢的行业中巨大的增长机遇。GDPR和PSD2是向开放银行转变的良好范例。

但大型企业如何才能应对这些挑战而又不产生巨额成本呢？
信息技术通过新的范式、流程和架构回应了这一及其他相关需求：DevOps、云原生、容器、敏捷方法、整洁代码与架构、全渠道，以及微服务！

2 项目

本次演讲将介绍一个从零开始构建的全新全数字化银行的真实案例，该案例充分考虑了上述所有因素，主要目标是快速且有效地响应变化，即在不牺牲质量的前提下尽快为客户创造价值。

因此，所有技术决策始终以在最短时间内交付最大价值为驱动，而缩短时间的最佳方式就是并行工作。

为此，必须将整个系统和交付过程拆分为独立自主的部分，涵盖以下方面：组织、生命周期、功能、技术、部署、执行和运维。

自主性的要求自然导向了微服务范式，以及其完整的实践、模型和模式。尽管这在项目初期可能被视为不必要的负担，但对我们而言，这不仅是一个实现并行交付的机会，也是采用最佳行业标准的契机。

从这一点开始，我们的目标是支持和提升自主性与并行性，以避免微服务开发中最大的陷阱：分布式泥球。

关于团队组织，我们遵循了Spotify模型：
• 特性小组负责一个垂直功能切片或子域。它们本质上是跨职能的，涵盖前端、中间件和运维。他们共同工作和办公。
• 能力小组是某一技术领域的横向专家小组。他们定期聚集，以维护和演进其所负责的技术方面或层级。

敏捷方法是银行的核心，开发团队也不例外。

小队的任务由Scrum指导，每两周为一个迭代。用户故事完全以客户为中心，因此小队必须实现并负责所需功能涉及的所有层级，包括部署和运维。

另一方面，能力小组通过看板跟踪他们的任务。

首要任务是完成用户故事，同时不牺牲质量并控制技术债务。
因此，开发人员必须在他们所属的特性小组和能力小组之间平衡时间。

在特性小组任务和能力小组任务之间进行平衡并不总是容易的，但我们设法将锁和依赖项保持在最低限度，对Scrum速度的影响也较小。

说到速度，小队花了超过3个迭代才稳定下来。结对编程、代码审查和拉取请求起到了很大的帮助作用。

其他一些基本实践和原则（遗憾的是，并不总是被遵循）包括基于主干的开发、测试驱动开发（TDD）、你不会需要它（YAGNI）和保持简洁（KISS）。

另一个支持自主性的重要策略是API优先。API蓝图描述被用作可读文档、模拟服务器和契约测试的来源。其中，模拟服务器和契约测试在处理服务间依赖关系时尤为有用。

关于功能自主性，微服务专注于特定的业务技术能力。
尽管这些服务并非基于领域驱动设计（DDD），但面向客户端的服务提供了领域功能（子域）的垂直切片，因此我们将其称为“垂直应用”。
其他将核心银行系统（Core Banking System）与第三方提供商集成的微服务称为“连接器”。

支持同步通信和异步通信。前者通过REST HTTP调用实现，后者通过Kafka事件实现。

一个艰难的决定是：要么完全采用事件优先（event‐first）的方式（结合 CQRS 和事件溯源），要么仅在带来足够价值时（用于状态共享和匿名命令请求）使用事件来降低耦合度。

到目前为止，后一种方法已成功与所选择的功能分解方式结合使用。然而，目前已经计划迁移到采用中央Kafka事件总线的事件溯源架构。

尽管我们应努力追求技术自主性，但到目前为止，我们一直坚持使用Spring Boot以及一套自定义的启动器，这些启动器对平台的各个方面进行了标准化：错误处理、审计追踪、身份认证与授权、多语言、事件、数据字典和测试。

2 项目（续）

基于 GitLab CI/CD、Nexus、SonarQube 和 Kubernetes 的完全自动化 DevOps 流程，支持部署和执行的自主性。
这里没有讨论，因为这是在生产环境中部署独立功能的标准方式。

我们正在通过 Ansible 和 Terraform 全面自动化基础设施的创建过程。

到目前为止，Kubernetes 为负载均衡、断路、服务发现和配置提供了出色的支持。

一个重要的基础设施原则是避免供应商锁定，因此仅使用通用的云服务。

最后但同样重要的是，如果没有端到端的审计和监控系统，微服务环境就不算完整。虽然这里有很多选择，但到目前为止，我们决定保持简洁，采用基于 ElasticSearch 和 Kibana 的成熟方案，用于监控和调试。该数据存储还被用作商业分析和大数据的来源。

3 未来

总体而言，利益相关者、产品负责人（POs）和开发人员对流程和交付的产品感到满意，但仍存在改进空间。

除了遵循Scrum的口号，在每次回顾会议中尝试偶尔提出的新想法外，目前没有计划改变团队组织。

入职流程尚不完善；大多数开发人员仍需内化基本原则，尤其是测试驱动开发。

关于技术，我们正在研究其他质量保证技术，例如验收测试驱动开发（ATDD）和领域驱动设计（DDD）。

但迄今为止，最具影响的挑战是转向CQRS和事件溯源。我们相信这将提升各个层面的自主性、可扩展性（尽管目前尚无扩展性问题）以及审计能力（目前远未完善）。

其他开放性话题包括：使用 Ansible 和 Terraform 实现自动基础设施创建、端到端自动化测试，以及真正的持续交付（目前尚无足够的测试支持直接上线生产环境）。