de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

案例研究：现代化“BigBank”互联网银行架构

引言

在当今以数字化为先的银行业环境中，金融机构面临着现代化其技术基础设施的关键挑战，同时必须确保安全性、可靠性以及无缝的客户体验。本案例研究从“”的视角，审视BigBank互联网银行系统的架构设计。C4模型，一个用于可视化软件架构的分层框架，将系统设计分解为上下文（Context）、容器（Containers）、组件（Components）和代码（Code）四个层级。
通过聚焦于容器图这一分析揭示了BigBank如何协调一个多层级的架构，将现代的Web和移动应用程序与遗留的大型机系统连接起来。该图展示了技术选择、通信协议和数据流，使个人银行客户能够安全地通过多个渠道访问其账户。这种架构方法表明，传统银行机构可以在不放弃经过验证的核心系统的情况下，提升其数字能力，为正在经历类似数字化转型的组织提供了宝贵的见解。

1. 执行摘要

本案例研究分析了虚构金融机构“BigBank”的互联网银行系统的架构设计。该项目的目标是为个人银行客户提供安全、可访问且多渠道的账户访问（通过Web和移动设备），同时与现有的遗留核心银行基础设施集成。

该架构采用C4模型（容器图）进行记录，该模型可视化了高层次的技术选择以及系统中各个容器（应用程序、数据库等）之间的交互方式。

C4 Model Container Diagram for Internet Banking System

2. 业务挑战

  • 遗留系统集成：银行拥有一个强大但较老的“大型机银行系统”，该系统保存着客户数据的核心信息。新系统需要暴露这些数据，但无需立即替换大型机。

  • 多渠道访问：客户要求通过桌面浏览器和移动设备进行访问。

  • 安全性：处理敏感的金融数据需要严格的认证机制和安全的通信通道。

3. 架构解决方案（C4容器视图）

该解决方案设计为一个解耦的系统，其中表示层与业务逻辑层和数据层分离。

A. 用户界面层（前端）

该系统为个人银行客户:

  1. 单页应用程序（SPA）：

    • 技术：JavaScript 和 Angular。

    • 角色：它在客户的网页浏览器中运行。它提供了完整的互联网银行功能套件。它是一个动态、响应式的界面，能够与后端异步通信。

  2. Web 应用：

    • 技术：Java 和 Spring MVC。

    • 角色：它是网络体验的入口点。它提供静态内容（HTML/CSS/JS），并托管单页应用。它充当 Angular 应用的“启动器”。

  3. 移动应用：

    • 技术：Xamarin（支持跨平台开发，可能是 iOS 和 Android）。

    • 角色：为移动设备提供“有限子集”的功能，经过优化。这表明复杂任务（如设置国际汇款）可能仅限于完整的 Web/SPA 界面，而常见任务（如查询余额）则可在移动设备上使用。

B. 业务逻辑层（后端）

  • API 应用：

    • 技术：Java 和 Spring MVC。

    • 角色：这是架构的中枢神经系统。它充当一个API 网关或前端后端（BFF）.

    • 功能：它向 Web 和移动客户端暴露一个JSON/HTTPS API。它处理身份验证、授权以及数据请求的编排。

C. 数据与集成层

  1. 数据库：

    • 技术：Oracle数据库模式。

    • 角色：存储互联网银行专用数据。其中包括用户注册信息，哈希认证凭据（安全最佳实践），以及访问日志。它不存储实际的银行余额（这些数据在大型机中）。不存储实际的银行余额（这些数据在大型机中）。

    • 通信：API应用程序通过JDBC.

  2. 大型机银行系统：

    • 角色：记录系统。它存储核心银行信息（客户、账户、交易）。

    • 通信：API应用程序使用HTTPS上的XML。这表明大型机很可能是一个基于SOAP的遗留服务，或是一个需要结构化XML数据交换的旧系统。

  3. 电子邮件系统：

    • 技术：Microsoft Exchange。

    • 角色：处理通知。

    • 通信：API应用程序通过SMTP发送到Exchange服务器，然后由该服务器将邮件发送给客户。

4. 关键数据流与用户旅程

场景 1：通过网页浏览器登录

  1. 该个人银行客户通过 HTTPS 访问bigbank.com/ib使用 HTTPS。

  2. 请求到达Web 应用程序（Java/Spring MVC）。

  3. Web 应用程序将单页应用程序（Angular）发送到客户的浏览器。

  4. 客户在单页应用程序中输入凭据。

  5. 单页应用程序发起一个 API 调用（JSON/HTTPS）到API 应用程序.

  6. API 应用程序将凭据与数据库（通过 JDBC）。

  7. 成功后，单页应用程序请求账户余额。API 应用程序从大型机银行系统 (XML/HTTPS获取此数据，并将其返回给单页应用程序。

场景 2：移动交易通知

  1. 客户通过移动应用程序（Xamarin）。

  2. 应用程序向 发送请求API 应用程序.

  3. API 应用程序与 处理付款大型机.

  4. API 应用程序通过向 发送 SMTP 请求来触发确认邮件电子邮件系统（Exchange）。

  5. 客户收到电子邮件通知。

5. 技术亮点与最佳实践

  • 关注点分离：该图清晰地将“网上银行”专用数据（Oracle 数据库）与“核心银行”数据（大型机）分开。这可防止网页层直接访问核心财务账本。

  • 协议转换：API 应用程序充当翻译器。现代前端使用 JSON，但旧版后端使用 XML。API 应用程序弥合了这一差距。

  • 安全性：凭据在数据库中以“哈希”形式存储，确保即使数据库被攻破，原始密码也不会暴露。所有外部通信均使用 HTTPS.

  • 可扩展性：通过使用单页应用（Angular）和解耦的 API，前端可以独立于后端逻辑进行扩展。

6. 实施的架构指南

6.1 安全性与合规性

  • 零信任通信：强制对内部服务间调用（尤其是 API 应用程序与大型机之间）使用双向 TLS（mTLS）。所有外部端点必须使用现代加密套件终止 HTTPS。
  • 身份与访问管理： 使用 OAuth 2.0 / OpenID Connect 进行身份验证。在 Oracle 数据库中仅存储加盐哈希后的密码（例如 Argon2 或 bcrypt）。对高风险交易强制执行多因素认证（MFA）。
  • 设计即合规： 使数据流符合 PCI-DSS、GDPR 和本地银行监管要求。确保个人身份信息（PII）和金融数据在静态和传输过程中均被加密。在数据库中维护不可篡改的访问日志，以供审计追踪。

6.2 以 API 为先与契约驱动开发

  • 尽早定义契约： 使用 OpenAPI/Swagger 对 API 应用程序暴露的 JSON/HTTPS API 进行版本控制。将契约视为 SPA 和移动团队的唯一真实来源。
  • 支付的幂等性： 所有支付端点都必须支持幂等性密钥，以防止在网络重试期间发生重复交易。
  • 面向前端的后端（BFF）模式： 如果移动端和 Web 端的需求差异显著，可考虑将 API 应用程序拆分为专用的 BFF，以避免数据过度获取或获取不足。

6.3 战略性遗留系统集成

  • 防腐层： API 应用程序应作为现代 JSON 数据包与主机系统 XML/HTTPS 模式之间的转换层。这可防止遗留数据模型泄露到前端代码中。
  • 熔断器与降级机制： 在主机系统调用周围实现弹性模式（例如 Resilience4j 或 Polly）。如果遗留系统变得无响应，应优雅降级为只读模式或使用缓存余额。
  • 异步卸载： 对于电子邮件通知或审计日志等非关键操作，使用消息队列（例如 RabbitMQ、Kafka）以避免阻塞面向客户的请求线程。

6.4 数据一致性与事务完整性

  • 分布式事务管理： 由于账户数据存储在主机系统中，而会话/认证数据存储在 Oracle 中，应使用 Saga 模式或补偿事务来维持支付流程中的数据一致性。
  • 在适当情况下采用最终一致性： 余额视图和余额显示可使用短 TTL 缓存以减轻主机系统负载，而交易历史应同步获取或通过事件流获取。
  • 严格的模式演进： 将数据库变更与 API 版本控制协调一致。使用向后兼容的模式迁移和弃用窗口，以避免破坏移动应用的发布。

6.5 可观测性与运营卓越

  • 分布式追踪： 在 Web/移动端入口处注入关联 ID，并将其通过 API 应用程序、主机系统调用和邮件系统进行传播，以实现端到端请求追踪。
  • 结构化日志与指标： 使用一致的严重性级别记录所有身份验证尝试、API 调用和主机系统交互。将指标导出到时序数据库，用于实时仪表盘。
  • 健康检查与就绪探针： 暴露 /health 和 /ready 在 API 应用程序上暴露端点，以在容器化环境中实现平滑部署和自动扩展。

7. 现实世界成功的技巧与窍门

7.1 掌握 C4 建模工作流程

  • 每个图仅保留一个抽象层级： 保持容器图仅在容器层级。将技术细节、类或数据库表推送到组件/代码图中，以避免混乱。
  • 自动化图生成： 使用 Structurizr、C4-PlantUML 或 Mermaid 等工具，从代码或配置生成图表。这可确保图表随系统同步演进。
  • 链接到文档： 将 C4 图表嵌入架构决策记录（ADRs）和入职维基中。为每个容器打上所有者团队、服务级别协议（SLA）和部署流水线的标签。

7.2 性能与延迟优化

  • 静态资源的 CDN： 将 Angular/JavaScript 包、CSS 和图像从 Web 应用程序卸载到 CDN。这可降低源服务器负载，并提升全球页面加载速度。
  • 移动端的负载优化： Xamarin 应用应仅请求必要字段。在 API 中实现 GraphQL 或字段选择参数，以减少移动网络上的 JSON 负载大小。
  • 连接池与保持连接： 调整 Oracle 数据库的 JDBC 连接池以及主框架调用的 HTTP 客户端池，以避免在银行高峰期出现连接抖动。

7.3 弹性与故障处理

  • 优雅降级： 如果电子邮件系统宕机，应将 SMTP 请求排队而非使用户事务失败。通过警报通知运维团队，而非用户。
  • 速率限制与限流： 在 API 应用程序上应用自适应速率限制，以在发薪日或市场波动期间保护主框架免受突发流量冲击。
  • 使用指数退避重试： 为瞬时故障（如网络超时、5xx 错误）实现智能重试，但绝不能在没有显式幂等性密钥的情况下重试幂等的支付调用。

7.4 跨分布式边界的测试

  • 契约测试： 使用 Pact 或 Spring Cloud Contract 验证 SPA/移动客户端与 API 应用程序是否遵循商定的 JSON 模式，防止在独立部署期间出现集成中断。
  • 遗留系统测试替身： 在CI/CD流水线中模拟或伪装主框架银行系统。使用记录的XML请求/响应对来测试API转换逻辑，而无需接触生产环境的主框架。
  • 轻量级混沌工程： 定期向非关键路径（例如，电子邮件发送、日志记录）注入延迟或故障，以验证备用行为和告警阈值。

7.5 文档作为动态资产

  • 与代码同步的版本图： 将C4图存储在与源代码相同的Git仓库中。将架构文档视为需要审查和CI验证的代码。
  • 维护系统上下文图： 与容器图一同保持更新的C4上下文图，以追踪外部依赖（例如，第三方欺诈检测系统、监管报告系统）。
  • 开展架构演练： 每季度组织跨职能团队（开发、运维、安全、产品）进行图示评审会议，以验证假设、识别瓶颈，并就现代化路线图达成一致。

这些指南和实用建议为实施、扩展或现代化类似互联网银行架构的团队提供了切实可行的蓝图。通过将严谨的C4建模与稳健的工程实践相结合，组织能够在安全地连接现代云原生模式与遗留核心系统的同时，提供安全、高性能的数字银行体验。

 

8. 工具：通过Visual Paradigm加速C4建模

记录和维护像BigBank互联网银行系统这样的复杂架构，需要强大且灵活的工具。Visual Paradigm 提供对完整C4模型层级的全面原生支持，使架构团队能够精确高效地创建、协作和演化图表。

8.1 为何选择Visual Paradigm进行C4建模？

Visual Paradigm因其以下特点，成为企业级C4建模解决方案中的佼佼者：

  • 完整的层级支持： 在单一统一环境中原生创建全部六种关键C4图类型——系统上下文图、容器图、组件图、系统全景图、动态图和部署图。[1, 2, 6, 7]

  • 多平台可访问性： 在以下平台无缝工作：桌面端（v16.3及以上版本），在线端（基于浏览器），以及AI驱动平台，确保分布式团队和不同工作流程偏好的灵活性。[4, 16, 18]

  • 以架构为先的设计： 元素是丰富且具有语义的实体，而不仅仅是视觉形状。对自定义属性、构造型和标记值的支持，使图表能够承载有意义的元数据，用于治理、影响分析和自动化文档生成。[8, 12]

8.2 BigBank案例研究的关键特性

为了记录BigBank架构，Visual Paradigm提供了针对性的功能：

特性 在BigBank架构中的应用
AI驱动的图表生成 通过用自然语言描述系统（例如：“SPA与API应用通信，该应用连接到Oracle数据库和大型机”），快速生成初始容器图。AI生成器会创建一个结构化的起点，便于后续优化。[5, 13]
元素可重用性与一致性 只需定义一次“API应用”容器，即可在上下文图、容器图、组件图和部署图中重复使用。更新会自动传播，确保架构一致性并降低维护成本。[8, 12]
C4-PlantUML集成 对于偏好基于代码建模的团队，可使用集成的C4-PlantUML Studio以文本形式编写图表，支持即时可视化渲染和完整的C4语义支持。非常适合与源代码一起进行架构版本控制。[12, 15]
动态视图与部署视图 使用动态图建模运行时交互（例如：“用户通过SPA登录”），使用部署图将容器映射到基础设施（例如：“API应用部署到AWS ECS”）——这对运营就绪性和DevOps交接至关重要。[5, 9, 11]
协作与模板 使用Visual Paradigm Online用于与安全、后端和前端团队实时协作编辑图表。利用预构建的C4模型模板，加速团队入职并确保图表标准统一。[4, 17]

8.3 实践工作流集成

  1. 从上下文开始：使用系统上下文图，使利益相关者明确BigBank的边界和外部依赖（大型机、邮件系统、客户）。

  2. 聚焦容器：创建容器图（如本案例研究中分析的那样），详细说明技术选型和高层级数据流。

  3. 深入组件：对于复杂的容器（如“API应用”），生成组件图以分解内部模块（认证服务、大型机适配器、通知服务）。

  4. 建模运行时与部署：使用动态图验证关键用户旅程，使用部署图规划基础设施部署和扩展策略。

  5. 作为动态文档持续维护：将图表存储在您的Git仓库中，将其与ADR和用户故事关联，并使用Visual Paradigm的版本控制功能，跟踪架构演进与代码发布同步进行。

8.4 开始使用

通过利用Visual Paradigm专为C4提供的支持，BigBank架构团队能够将静态图表转变为动态、协作且可操作的权威来源——加速设计决策，提升跨团队协作一致性，并确保架构在满足业务需求的同时安全演进。

结论

BigBank的互联网银行系统架构体现了金融服务业数字化转型的一种务实方法。通过利用C4容器图，利益相关者能够清晰理解各种异构技术——从现代JavaScript框架到遗留大型机系统——如何协同工作，以提供一致的银行体验。该架构的优势在于其分层关注点分离，其中API应用作为关键的集成层，负责在基于现代JSON的前端与基于XML的遗留后端之间进行转换。
这种设计模式具有多项战略优势：它保护了核心银行基础设施的投资，支持面向用户的应用程序独立扩展，并通过凭证哈希和加密通信维持严格的安全标准。此外，多渠道方法——支持网页浏览器、单页应用和移动设备——体现了对不断变化的客户需求的响应能力。
C4模型在向各类受众（从技术开发人员到业务利益相关者）传达这一复杂架构方面具有不可估量的价值。通过清晰地展示容器、技术及交互关系，它有助于就未来改进、技术迁移和系统集成做出明智决策。随着BigBank持续发展其数字服务，这一架构基础使该机构能够适应新兴技术——如开放银行API、生物识别认证和AI驱动的个性化服务——同时保持客户对其金融机构所期望的稳定性和安全性。