银行核心系统|应用架构与案例,这次不谈中台

本文阐述银行应用架构概念,解析其支撑业务战略的关键作用,涵盖设计原则、分层与分组策略,及规划方法,旨在为银行信息化建设提供蓝图。

阿里云幸运券

应用架构(Application Architecture)介于业务与数据和技术架构之间,在银行企业架构和信息系统规划起着很重要的作用。

本文主要介绍应用架构的原则和包含的内容,以及典型银行应用架构的样子。

此文适合人群:

银行从业人员,企业架构师,系统架构师、软件工程师。

此文解决问题:

应用架构的概念、原则、工具、视图

银行应用架构内容

此文分为四部分:

一、什么是应用架构

二、应用架构如何支撑业务架构

三、应用架构规划方法

四、应用架构抽象(分层、分组)

1

什么是应用架构

企业架构(Application Architecture),简称AA。站在IT视角应用架构可以理解为支持业务的关键应用应用群,描述了这些应用如何分布、相关之间的关系、与外围系统的关系等。站在企业管理者视角应用架构是实现业务能力并支撑业务发展的基础,是上承业务战略,向下指导银行信息系统建设的蓝图。

应用架构包括设计原则、应用分层、分群、分组与边界定义、应用的集成关系与交互方式等。

2

应用架构如何支撑业务架构

为了支撑业务发展经常会基于业务架构进行IT系统建设,业务能力和IT系统映射示意图如下图所示,而过去这样的建设过程多为业务发起IT配合采购选型进行建设的。

读者可能也发现了上图的一些问题,具体的问题我们后文会说。

美国国家标准与技术研究院发布的企业架构框架中描述的应用架构对业务的支撑如下图所示:

图片源自NIST Special Publication 500-167

在基于平台型企业架构中,应用架构对业务的支持是如下图所指示的样子:

图片源于如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘

在面向服务的企业架构应用架构对业务架构的支撑是如下图所示的样子:

如果我们按照渠道、客户、产品、决策支持、基础支撑等维度对系统细化会得到一个按照应用和模块等维度细分的一个逻辑架构图,大致如下图所示。

图片源于网络

3

应用架构规划方法

应用架构规划是从企业业务战略出发,提出IT规划和流程变革思路:

通过对外行业交流,市场研究对内与高管沟通,了解企业的现状、未来的发展战略和当前面临的挑战

了解企业的资源和计划,根据经验设计一个可以分阶段实施和持续交付的IT架构,推动相关业务流程改造

根据企业现状、未来发展战略,对企业的IT规划整体架构定期进行调整。

设计主要应用系统的功能,以及IT架构的实施路线图

摘自:企业信息化总体架构

在规划过程中,参考同业和行业内标杆银行在流程、信息、应用、计划、组织、资源利用等方面的最佳实践,并结合银行自身特点进行规划。

摘自:企业信息化总体架构

在进行应用架构规划是应该遵循以下原则:

使用一致的应用框架爱与应用设计原则

构建企业应用集成架构,基于现有系统功能,解决当下系统多、功能分散、边界不清等问题

构建服务为导向实现资产复用化

构建统一的、易用的信息门户平台

构建集中化的信息管理平台

构建全行应用统一的授权和认证机制

适配业务,能够支撑银行业务或技术发展战略的目标并具备足够的灵活性和扩展性

在选择架构时,必须明确当下面临问题的重点,和未来的方向,以此来选择合适的设计

摘自:企业信息化总体架构

4

应用架构抽象

在分解复杂的软件系统时,做多使用的技术技术分层。在计算机领域随处可见分层的例子。从7层网络协议到多层的企业架构,分层带来诸多好处的同时也存在一些问题。

典型的银行应用架构可以划分为:场景/渠道对阶层、渠道整合层、客户管理层、产品服务层、业务处理层、运营管理支撑层、外联集成层共8层:

中文的分层常不区分layer和tier,这就导致了经常对横向切分的层与纵向切分的层混淆,物理分层与逻辑分层混淆。比如我们常说的C/S和B/S模式,是 tow-tier system,指的是物理上的分离,客户端和物理段分属不同的机器;而MVC是使用layer的分层,旨在强调无需把不同的层次放在不同的机器上运行,逻辑的分层。

本文中所使用的分层主要是强调逻辑层次的layer分层。所以读者不必纠结他们的物理部署,而是将更多的焦点放在如何通过将整体新系统中的的各部分分离,实现上面提到的分层的目的。当然各系统部署的拓扑和物理结构也很重要,这个后面在技术架构部分会有重点介绍。

与分层相对的另一个就是分组,分组的目的是:

应用架构分组视图:

5

小结

本文是应用架构的第一篇,主要介绍了银行应用架构的概念、原则和视图,后面还会分几篇详细介绍银行应用架构系统、微服务架构、应用架构成熟度指标模型等方面内容。

腾讯云代金券

原文链接

https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ%3D%3D&mid=2651031719&idx=1&sn=2db8b7240d727c2758faca50d529a296&chksm=8c4c5da3bb3bd4b5e649ee0c74e570a5c0e6f40619321ffaac71b8ae2ad314515b398d9c2fda&mpshare=1&scene=23&srcid=%23rd

服务推荐

<think> 嗯,用户这次想了解数据中台、数据仓库、应用架构、云原生和微服务这些概念的信息。从问题来看,用户应该是技术架构相关领域的从业者或学习者,需要系统性的知识梳理。用户特别提到需要了解概念、关系、应用场景和技术实现,说明ta的需求非常全面。 我注意到用户提供的引用材料主要集中在云原生和微服务的关系上,尤其是引用[4]提到"下沉非功能性需求"这个关键点很有价值。过用户实际需要的范围更广,涉及五个概念的交叉分析。 在组织回答时,我会特别注意几个关键连接点:数据仓库如何演进成数据中台,微服务架构如何支撑现代应用架构,以及云原生技术如何赋能所有这些领域。技术实现部分要给出具体方案示例,比如提到Kubernetes和Service Mesh这些实际工具。 用户可能正在做技术选型或架构设计,所以应用场景要区分传统企业和互联网新业务。特别要强调数据中台和微服务的结合点——这正是很多企业数字化转型的痛点。 考虑到概念较多,需要用树状结构组织内容,但回答中要转化为自然段落。每个概念的解释控制在两句话内点透本质,重点放在关系网和应用落地上。技术实现部分引用具体工具链时要区分"基础组件"和"选型方案"两个层次。 最后生成的问题要引导用户深入特定场景,比如"金融行业如何组合使用数据中台和微服务",这样比泛泛提问更有价值。过当前回复里的三个问题已经覆盖了主要维度,特别是第二个问题直指技术整合这个难点。 </think> 以下是关于数据中台、数据仓库、应用架构、云原生和微服务的系统性解析,涵盖核心概念、相互关系、应用场景及技术实现: --- ### **1. 核心概念** | **术语** | **定义** | **核心目标** | |-------------------|--------------------------------------------------------------------------|---------------------------------------| | **数据仓库** | 集成的、面向主题的历史数据存储库,用于支持决策分析 | 提供历史数据的统一视图,支撑BI和报表 | | **数据中台** | 企业级数据能力共享平台,整合数据资产并提供标准化服务(如数据开发、治理、API化) | 打破数据孤岛,加速数据赋能业务创新 | | **应用架构** | 软件系统的结构化设计,包括模块划分、交互逻辑和技术选型 | 保障系统的可扩展性、可维护性和性能 | | **微服务** | 将单体应用拆分为独立部署的小型服务,各服务通过API通信 | 提升开发敏捷性、技术异构性和容错能力 | | **云原生** | 基于云基础设施(容器、K8s、服务网格等)构建和运行应用的方法论 | 实现弹性伸缩、自动化运维和持续交付 | --- ### **2. 相互关系** ```mermaid graph LR A[应用架构] --> B[微服务] A --> C[云原生] B --> D[数据中台] C --> D D --> E[数据仓库] ``` - **微服务云原生** 微服务是云原生的**核心架构范式**。云原生提供容器化(Docker)、编排(Kubernetes)、服务网格(Istio)等能力,解决微服务的部署、治理和观测问题[^3][^4]。 - **数据中台数据仓库** 数据仓库是数据中台的**底层支撑**,负责结构化数据的存储加工;数据中台扩展其能力,集成实时流、非结构化数据,并通过API提供数据服务(如用户画像、推荐引擎)[^1]。 - **应用架构的演进** 传统单体架构 → SOA → **微服务+云原生**。云原生技术(如Serverless)进一步将非功能性需求(扩缩容、故障恢复)下沉至基础设施,使开发者聚焦业务逻辑[^4][^5]。 --- ### **3. 应用场景技术实现** #### **(1) 数据中台** - **场景**: - 跨部门数据共享(如电商整合订单、用户行为、库存数据) - 实时风控(金融行业交易欺诈检测) - **技术栈**: ```python # 示例:数据服务API化(通过Data API Gateway) from flask import Flask app = Flask(__name__) @app.route('/user_profile/<user_id>') def get_user_profile(user_id): # 调用中台数据服务层 profile = data_platform.query("user_behavior", user_id) return profile.to_json() ``` #### **(2) 微服务云原生** - **场景**: - 高并发电商系统(订单、支付、库存服务独立伸缩) - 快速迭代的互联网应用(各服务可独立部署) - **技术栈**: - **容器化**:Docker封装服务 - **编排**:Kubernetes管理容器生命周期 - **观测**:Prometheus+Grafana监控服务性能[^5] $$ \text{服务可用性} = \frac{\text{总时间 - 宕机时间}}{\text{总时间}} \times 100\% $$ #### **(3) 数据仓库的现代演进** - **场景**: - 历史数据分析(如年度销售趋势报表) - 合规审计(金融行业数据归档) - **技术演进**: 传统数仓(Teradata) → 云数仓(Snowflake/BigQuery) → **实时数仓**(Apache Doris) --- ### **4. 协同价值** | **组合方案** | **收益** | **案例** | |---------------------------|----------------------------------------|---------------------------------------| | 云原生+微服务+数据中台 | 快速响应业务变化,数据驱动创新 | 抖音推荐系统:微服务实时处理用户请求,数据中台提供画像支持 | | 数据仓库→数据中台 | 从滞后分析到实时决策 | 银行反欺诈:数仓存储历史交易,中台实时计算风险评分 | --- ### **5. 挑战趋势** - **挑战**: - 数据中台:数据治理复杂度高(质量、血缘管理) - 微服务:分布式事务(Saga模式)、链路追踪(Jaeger)难度大 - **趋势**: - **Serverless微服务**:进一步简化运维(如AWS Lambda)[^2] - **AI赋能数据中台**:自动数据标注、智能ETL调度
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值