38、云原生银行构建：策略、架构与实践

最新推荐文章于 2025-12-06 10:02:57 发布

pca5navigator

最新推荐文章于 2025-12-06 10:02:57 发布

阅读量39

点赞数

CC 4.0 BY-SA版权

分类专栏：云原生转型：从理论到实践的全面指南文章标签：云原生银行构建微服务架构

本文链接：https://blog.youkuaiyun.com/pca5navigator/article/details/149992904

云原生转型：从理论到实践的全面指南专栏收录该内容

41 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

云原生银行构建：策略、架构与实践

1. 关键策略与架构模式

在大型项目，如云原生转型中，有几个关键的策略和架构模式起着至关重要的作用。

1.1 高管承诺

为确保足够的资源分配和合理的交付时间框架，大型项目需要强有力的高管承诺。高管的支持和决策对于项目的顺利推进至关重要，他们能够调配资源，设定优先级，并为项目提供战略方向。

1.2 动态策略

如今由技术驱动的市场环境不断变化，无论处于何种行业，都需要制定动态的战略。这意味着要根据市场的变化及时调整游戏计划，以适应不断变化的需求和竞争环境。

1.3 价值层级

明确组织的价值层级有助于日常决策。关键价值层级为安全 > 弹性 > 规模，次要价值层级为速度 > 经济性。这种层级关系使团队在复杂多变的环境中能够做出具体的决策。

例如，在架构选择上，单体应用和微服务各有优劣。单体应用初始启动速度快，但随着时间推移会变慢，且难以更改；微服务初始复杂，但随着管理能力提升会变快，且受团队干扰小。为了兼顾两者优势，采用了类似微服务或迷你服务的架构，但在很多方面采用单体应用的做法，如同时发布多个微服务。

以下是单体应用和微服务的对比表格：
| 特性 | 单体应用 | 微服务 |
| ---- | ---- | ---- |
| 初始速度 | 快 | 慢 |
| 长期可维护性 | 差 | 好 |
| 团队协作干扰 | 大 | 小 |

1.4 核心团队

可以由一个五到八人的小工程师团队构建云原生平台。核心团队专注于发现最佳转型路径并实施，降低转型风险，同时积累经验，以便后续引入其他团队。

1.5 微服务架构

为降低大型单体应用团队之间的协调成本，将软件构建为一组模块化服务，这些服务可以独立构建、部署和运营。这种架构使得不同团队能够独立负责不同组件，提高开发和维护效率。

以下是微服务架构的 mermaid 流程图：

graph LR
    A[业务需求] --> B[模块化服务设计]
    B --> C[独立开发]
    C --> D[独立部署]
    D --> E[独立运营]
    E --> F[客户反馈]
    F --> A

2. 团队组织与沟通

在团队组织和沟通方面，也有一些重要的模式和实践。

2.1 远程团队

如果团队需要分布在不同地点，应建立定期的面对面交流活动和强大的沟通渠道，以确保团队之间的紧密协作和信息流畅。

2.2 跨职能团队

构建跨职能团队，将工程和业务人员结合在一起。这样可以消除业务和 IT 之间的距离，提高决策效率和响应速度。例如，当支付运营人员遇到问题时，工程师可以立即解决，而无需高层决策。

3. 技术栈与应用构建

在技术栈和应用构建方面，有以下要点。

3.1 技术栈选择

构建 Java 服务并打包在 Docker 镜像中，部署到运行 CoreOS 的 EC2 实例上，同时使用 sidecar 进行日志传输和指标发布。还使用了许多云服务，如 GitHub、Quay.io、Artifactory 和 Slack，以及 Circle 和 TeamCity 进行 CI/CD，基础设施代码使用 CloudFormation，滚动部署工具自行开发。

3.2 移动应用构建

作为一家仅提供移动应用的银行，选择为 iPhone 和 Android 分别开发应用，不共享代码。原因一是需要深入访问硬件，二是认为专注于特定平台的开发者能够提供更好的代码质量。

4. 构建原则与实践

在构建银行系统时，遵循了以下几个重要原则。

4.1 无 IT 部门理念

将自己视为拥有银行牌照的科技公司，而非需要开展技术的银行。避免传统银行中业务和 IT 分离的模式，构建跨职能团队，让业务和技术人员紧密合作，提高效率和响应速度。

4.2 你构建，你运行

工程师对所构建的系统全面负责，包括设计、开发、运行、支持、修复、增强等各个方面。这种“你构建，你运行”的模式增强了工程师的责任感，提高了系统的质量和可维护性。

4.3 持续交付

持续交付是构建银行的重要原则之一。保持小的构建周期，确保代码始终准备好投入生产，功能能够立即发布给客户，并快速获取客户反馈。

例如，每天发布和部署整个后端 1 - 5 次，每天进行至少同样数量的基础设施更改，移动应用每 1 - 2 周发布一次。如果一天没有发布，会被视为一个危险信号，因为这意味着没有练习关键业务功能，增加了下一次发布的风险，也是一个失去获取生产环境诊断信息的机会，还可能暗示某个流程出现问题。

以下是持续交付的好处列表：
- 代码始终准备好投入生产
- 功能能够立即发布给客户
- 快速获取客户反馈
- 降低发布风险
- 及时发现和解决问题

4.4 降低风险的部署策略

采用发布策略来降低引入变更到生产系统时出现问题的可能性。例如，在工程 Slack 频道进行“承担责任仪式”，增强团队成员的责任感和对变更的承诺。

4.5 自动化测试

将测试责任从人工转移到自动化测试框架，使开发人员能够更快地交付，并将更多时间用于改进功能以满足客户需求。自动化测试提高了测试效率和准确性，减少了人为错误。

云原生银行构建：策略、架构与实践

5. 避免常见误区与实现范式转变

在云原生转型过程中，很多公司容易陷入一些误区，而正确认识并避免这些误区对于成功转型至关重要。

5.1 避免将云原生视为敏捷的简单延伸

很多公司在采用敏捷实践后，未能认识到向云原生实践转变是一次真正的范式转变，而仅仅将云原生视为“一种新的敏捷方式”，把云原生转型当作一系列技术相关任务添加到现有开发待办事项中。这种做法往往导致转型失败。

传统银行在尝试云原生转型时，常将敏捷转型仅视为 IT 部门的举措，业务部门只是勉强接受。例如，虽然对团队进行了重组，使其不再严格专业化，但最终仍未与核心业务紧密结合，与业务的沟通仍需中介人员，这依然存在诸多问题。

而在构建银行系统时，应将云原生视为一种真正的范式转变，全面改变软件开发和交付的方式，从构建流程到人员组织和沟通方式都要进行调整。

5.2 灵活应对康威定律

康威定律指出，软件结构会反映构建它的公司的组织结构。微服务架构能够很好地遵循这一定律，便于调整服务所有权，使系统架构与组织架构保持一致。

然而，对于快速发展的小型初创公司来说，组织架构尚不完善且不稳定，过早致力于遵循康威定律可能并非明智之举。因此，应尽可能保持灵活性，待组织架构成熟后再考虑这一问题。

以下是应对康威定律的决策流程图：

graph LR
    A[初创公司] --> B{组织架构是否成熟}
    B -- 否 --> C[保持灵活性，暂不专注康威定律]
    B -- 是 --> D[调整服务所有权以遵循康威定律]

6. 各模式与原则的协同作用

上述各种策略、架构模式和构建原则并非孤立存在，而是相互协同，共同推动云原生银行系统的成功构建。

模式/原则	与其他模式/原则的协同关系
高管承诺	为其他模式和原则的实施提供资源和战略支持，确保核心团队、微服务架构等的顺利推进
动态策略	根据市场变化调整微服务架构、持续交付等策略，以适应不断变化的需求
价值层级	指导微服务架构设计、核心团队组建等决策，确保资源分配和优先级设定符合组织价值
核心团队	为微服务架构的实施积累经验，推动持续交付等原则的落地
微服务架构	支持跨职能团队的运作，便于实现“你构建，你运行”的原则，同时为持续交付提供基础
跨职能团队	促进业务和技术的融合，有助于实现无 IT 部门的理念，推动持续交付和降低风险的部署策略的实施
无 IT 部门理念	为跨职能团队的组建和运作提供组织架构基础，与“你构建，你运行”原则相契合
你构建，你运行	增强工程师的责任感，提高微服务架构的质量和可维护性，促进持续交付的顺利进行
持续交付	依赖于微服务架构的独立性和自动化测试的支持，同时为获取客户反馈和改进系统提供途径
降低风险的部署策略	与持续交付相结合，确保在频繁发布的情况下降低变更引入生产系统的风险
自动化测试	为持续交付和微服务架构的稳定运行提供保障，提高开发效率和质量