金融行业分布式架构转型发展与趋势

1、金融行业分布式架构转型发展与趋势银行IT服务能力为什么需要转型银行金融业务中台支撑能力构建12微服务与分布式架构实现敏捷化开发3金融云平台助力银行IT转型42目录当前银行面临的挑战监管变化用户体验传统银行难满足日益增长的用户体验随时的、超前的7x24 服务0秒授信随需的、个性的招行APP埋点3万个个性化推荐超3亿次/每天随地的、普惠的新网银行开业二年，客户增长-2500万竞争加剧Fintech蚕食银行市场份额、利润资产业务Fintech影响银行1/3的收入负债业务余额宝导致银行利息多支出600亿中间业务移动支付市场失去40%，结算收入下降50%监管规则变化，压力和机会并存业务连续性中国银监会要

2、求千亿资产的银行 必须建灾备中心，确保业务连续 性民营银行牌照推动本地银行开放创新截止2019年 大陆19家民营银行监管科技针对金融机构监管科技，沙盒测 试一块正在快速追赶国外成本增加3传统银行获客留客成本高昂被动依靠互联网渠道获客被动依靠互联网公司引流，无法真正获得场景，成本越来越高，单个 客户成本超100元。客户粘性低，运营成本高无自建场景，客户粘性低，依靠线下运营成本高昂。IOE架构升级成本高昂传统IOE架构在对客户运营业务需求满足上，升级成本高昂数字银行变革构筑七大核心竞争力4国内银行典型实践- 移动优先、数据驱动、开放架构、开放银行未来银行科技致胜平台+生态=银行即服务-BaaS用户

3、画像| 精准营销 |在线征信| 决策分析打造开放银行平台，联结银行与商业/生活的生态伙伴单用户成本贷款量(元）7千万3千亿活跃用户数￥70.6%不良贷款率去IOE，完全自主研发纯开源技术 , MySQL，Linux257API接口(个)200万100万日交易量(笔）用户数92平台应用(个)全分布式 云化架构移动支付| 移动营销 |主动获客|普惠金融离柜率ICBC 97%行业平均近88%月度活跃用户数 MAU招商银行 数字化转型KPI-“北极星” 2017年起，3年内MAU目标6千万 =2亿招商银行历史交易：在线查询 1年=7年 在线征信：信用卡征信 2周 =0秒（实时征信）Sberbank公司

4、客户 放贷审批 X天=7分钟（目标）（应用AI+大数据）5电子渠道逐渐由渠道、产品为中心，向以用户为中心转变移动信贷完成线上贷前贷中贷后管理，让客 户随时随地享受普惠金融服务6金融开发平台金融生态建立的基础，实现金融能 力和生态技能的输入输出家庭银行智能音响金融助手移动银行手机银行、企业版手机银行，新形 态的门店、新战场的主要输出微信银行小程序围绕用户体系，获客、活客以及营 销互动开发站移动柜面移动开卡开户、行用卡进件移动营销、智能厅堂储蓄产品、理财基金销售、营销活 动开展网点小助手、实现预填单、 CRM管理，产品展示新形态 新战场智能客服智能交互实现智能语音服务为什么建设敏态核心客户经营-银

5、行业务发展 的内生动力外接流量内建场景开放银行生态C端+衣 食 住 行 娱教 游 医+B端G端+合作方+平台+五大行和股份制：与互联网巨头的对接和合五大行和股份制：五大行和股份制：作较多，且合作较为深入，谈判地位平等，但业建行的“善融商务”，“住房金融”，退伍军人等生态；中国银行的“开放银行”平台，为分行开发务布局存在部分重叠，属于竞合关系。工行的“融E购”，“融E行”，“融E联”；基于总行开放能力的特色应用提供支持；平安的“金融服务、医疗健康、汽车服务、房产服务、光大银行的云缴费业务，缴费项4000余项，智慧城市”五大生态打造；微信、支付宝等都是接入的光大云缴费，光招商银行的“掌上生活”，涵

6、盖购物，美食，出行，娱 乐等场景。大按照笔数收取手续费。城农商行：与互联网巨头的合作谈判地位不对城农商行：城农商行：等，除少部分银行和互联网企业有深入合作外，部分科技能力较强的银行自建场景，比如江苏银行的南京银行鑫云+平台，与阿里合作搭建互联如南京银行的鑫云+；金融金融的京东联名信用“串串盈”，西安银行的“社区银行”，中原银行的网开放平台，2018年实现获客近千万，累计卡，合作内容基本停留在购买流量的阶段，且对“吃货地图”等；发放贷款820亿元，与20家银行达成战略合银行的定制化方案响应不及时，引流效果一般；科技能力较弱的银行与合作方共建场景，以合作方的产作协议的签订。城农商行转而向属地化互联

7、网企业聚焦，与当地企业或创业型公司互换资源，实现获客。品化平台为基础，实现场景的搭建。鑫E家，互联网同业平台，平台累计注册金融机构180余家，交易金额1万1千亿元7业务快速发展对金融IT系统带来的挑战简化运维业务快 速发展移动化互联网金融市场利率化监管严格快速交付安全可控稳定可靠提高利用率高性能弹性扩展成本可控8IT架构向开放分布式架构演进IOE架构（传统银行）双模IT架构（传统+数字银行）分布式互联网架构（全数字化银行）封闭，玩家少，以IOE为代表可维护性差，成本高扩展性差，难以支撑大规模交易封闭开放系统并存，传统核心业务运行 在封闭架构上，新兴业务运行在分布式 架构上灵活，易扩展传统核心业

8、务维护成本高基于开源技术和x86服务器，全分布式灵活，易扩展支持多种移动互联网场景低TCO，运维自动化程度高支撑业务快速创新分布式架构+开源成为银行IT架构演进趋势9架构介绍特征典型银行大部分中小银行，如城市商业 银行、农村信用合作社工行、建行、新网银行、招商银行网商银行、微众银行分布开源集中化分布双模架构存储阵列数据库：数据库：数据库：小型机大型机AS400技术架构适应时代的发展“分布式”时代“大集中”时代大机/小机银行应用PaaSIaa S微服务 框架企业 大数据容器分布式数据库消息中间件分布式运维虚拟计算/虚拟存储/虚拟网络COBOL/RPG/Java/C+CICS/WAS/Tuxedo

9、DB2/OraclezOS/OS400/Unix业务 特点强一致性软+硬IaaS区块链AIIoT应用组件客户认证记账组件签约组件流程银行开放银行对账组件咨询、实施、运维、外包咨询、实施、运维、外包+服务PL/SQLSQLExadataTeradataDaaSM/RYarnHDFSHbaseCarbonData应用组件ESFlinkHiveMahout10银行IT服务能力为什么需要转型银行金融业务中台支撑能力构建12微服务与分布式架构实现敏捷化开发3金融云平台助力银行IT转型411目录银行IT系统建设由集中式向分布式转型转型驱动力：分布式架构应对互联网业务浪涌业务中台微服务化加快业务创新降低总拥

10、有成本传统银行IT应用架构重点在建设“业务系统”，新一代银行IT应用架构重点 在建设“业务中台”。12基于业务中台的应用架构13互联网敏态银行业务架构14目录银行IT服务能力为什么需要转型银行金融业务中台支撑能力构建12微服务与分布式架构实现敏捷化开发3金融云平台助力银行IT转型415物理资源池（IaaS）中间件资 源层应用层业务部门1OracleDB ArrayPG-SQLSLBWeblogic Conherence Websphere业务部门2PG-SQLOSBArray OracleDBWeblogic Tomcat MQ业务部门3MySQLTomcat分布式存储AutoScaleACM

11、emcache分布式文件业务部门4HIVE HBASE SPARK-SQLStreamGBase Aster Storm静态资源分配、分散管理：各分散的业务部门通常按照规划的最大资源申请物理机、虚机资源，物理资源仍被私有化，无 法实现共享，利用率低。通常数据中心利用率在10% 20%。应用架构七国八制：技术架构、中间件有各业务部门（合作ISV）独立选型、采购，OS、中间件选择不统一，类型众多。16虽然通过IaaS实现物理资源的池化，但由于人为静态独占资源，并不能很好的解决资源共享和利用率的问题。挑战1：烟囱式应用系统构建，难于共享，资源利用率低大代码基线、错综复杂依赖的单体应用架构，导致往往新

12、增一个小特性需要数月到半年之久！开发周期长：庞大代码基线，涉及100200人团队开发维护组件耦合大、责任不清楚，牵一发而动全身部署慢、扩容慢：部署过程不可重复、出错率高；不支持自动弹性伸缩升级难：固定时间窗、集中大规模人力中断服务升级请求接入 处理文件 访问加解 密日志异常处理国际化数据访问服务控制 组合冲正处理批量作业 调度批量处理服务后处 理交易记录 应用服务器：基础层 OSVM 运行时配置层报文适P配 la流量t控f制or交m易调.度ja对r外呼出产品服务1产品服务2产品服务n几十M1kb+4.7G+几百M17某 客 户 现有术堆单栈体应 用 技挑战2：臃肿的单体应用架构，无法满足敏捷和

13、快速业务的诉求挑战3：互联网时代的新常态：快与变互联网、移动互联网时代1、互联网流量的不可预测性，对业务弹性要求越来越高如何通过云计算改善IT效率应对互联网时代“快与变”的新常态，是传统企业数字化转型迫切希望解决的问题！快速创新诉求1、企业现场业务办理、远程异地办公等移动化业务需求2、通过移动办公提高企业对业务的快速反应、高效服务的能力18紧耦合，系统复杂、错综交互，动一发而牵 全身重复制造各种轮子：OS、DB、Middleware完全封闭的架构松耦合在大型、超大型企业中仍然流行通常通过ESB进行系统集成大团队：100200人TTM: 1年、半年、月集中式、计划内停机扩容解耦互联网公司、中小企

14、业、初创公司小团队：2 Pizza TeamTTM: 按天、周进行升级发布DevOps: CI, CD, 全自动化可扩展性：自动弹性伸缩高可用：升级、扩容不中断业务第一代：单体架构第二代：SOA架构第三代：微服务架构应用架构在发展演进：云原生、微服务19微服务组件成为当前和未来的主流架构，带来的核心价值是能缩短业务上线周期和保障业务运行高可靠微服务核心特征：小、独、轻、松小 独 轻 松Own process单独的进程Lightweight mechanisms轻量级通信机制，通常是HTTP/REST接口Independently deployable松耦合、可独立部署 微 服 务须 同 时 满

15、 足 四 个 条 件区别于传统单体应用，后者各个模块、组件或动态库是集成在一个大进程中运行的区别于传统SOA架构，后者是基于重型总线ESB、Centralized Governance集中管控的架构每个微服务可独立编译（无二进制接口依赖），独立部署（无部署顺序依赖），独立运行（无启动顺序依赖）微服务特征Small services粒度小，且专注一件事情如何界定微服务多小算小：代码行数？重写时间？跟语言、技能相关，都不合适亚马逊认为：由2-Pizza团队端到端负责1个或1组服务，大小是合适的当今世界软件开发 领域最具影响力的 五位大师之一20Martin Fowler总结Netflix等互联网架

16、构实践，提出了Microservice（微服务）架构的概念：微服务不是银弹分布式下的平衡之道集成依赖打桩，孤岛测试(基于接口编程，录制请求)问题分散，定位困难(日志聚合)部署环境更加复杂(PaaS，Docker，自动化)运维更 难 沟通 更分布式事务难保证数据强一致性（补偿）远程调用的网络开销，超时问题大(API网 关，合并请求，批量处理)更加复 杂保障AvailabilityPartition Tolerance规避(补偿)Consistency (一致性)无状态计算服务最终一致性CAP原则：一个分布式系统最多只能同时满足三项中的两项一致性（Consistency）可用性（Availabil

17、ity）分区容错性（Partition tolerance）涉及团队多，沟通成本高分布式带来的问题21CAP原则根据业务来平衡首先保证服务的幂等性（查询是天生幂等的） 乐观锁:更新删除都带条件（更新时间/版本） 失败后隔时重试直到成功来补偿分布式改造的痛点应用面 变革数据面变革基础设施面 变革数据分片表3表2表1直销银行互联网 金融核心信用卡Cloud OS + AC ControllerPaaS遗留系统区3微服务化业务中台2数据分布化1基础设施云化业务中台用户中心产品中心资产中心外联中心营销中心风控中心22无成熟分布式数据库产品 及生态，采用分库分表+MySQL 。分库分表设计，以及给应用带

18、来改造。自动化运维部署。大量外设无法纳入云化管理。痛点缺乏分布式改造建设经验。初期建设开发量大，需要大量人力投入。分布式事务管理，分布式架构下的通信，分布式批处 理调度。目录银行IT服务能力为什么需要转型银行金融业务中台支撑能力构建12微服务与分布式架构实现敏捷化开发3金融云平台助力银行IT转型423金融云整体架构图24业务云化建设与规划场景APP1中间件1 数据库1OS1OS2APP2中间件1 数据库1OS3OS4x86x86x86x86适合在池外的应用 系统，如数据库等APP1APAPP2APAPP3APVM VMVM VM中 间 中 间件 1 件 2VM VM中间 件3中间 件4中间 件

19、5中间 件6部署、配置、监控虚拟化虚拟化虚拟化x86x86x86适合应用和中间件紧耦 合的应用系统等APP2APP1APP3x86IaaS自动化编排C VMC VMC VMAPAPAP中间 件1中间 件2中间 件3中间 件4中间 件5中间 件6适合应用和中间件不 绑定的应用系统，如 办公类业务等x86IaaS自动化（I/P层打通）PaaS中间件服务平台中间件n中间件1APP1APP2APP3中间件2APAPAP中间件能力从应用层转 移到PaaS层形成标准化 服务、可共享平台架构IaaSPaaS中间件服务平台x86数据中间件APP2微服务应用APP1适合新定制开发 的应用系统等池外应用系统的物

20、理资源纳管到资源 池（应用不改）应用系统的基础设 施云化（应用不改 或少改）应用容器化，快速发 布和弹性伸缩（应用 不改或少改）中间件服务化， PaaS大集中（应 用不改或少改）应用微服务化实现 Cloud-Native架构（应用架构改造）传统IT服务器虚拟化私有云/融合资源池混合云/IT服务化混合云/云原生2527应用上云建议：多场景并存，渐进式演进通过需求驱动应用分场景上云，渐进式演进（遗留应用/老应用不做代码级改造，以自动化为主）PaaS核心是为应用上云提供服务化、自动化和分布式化的支撑能力，降低应用上云难度低高高落地难度（涉及组织、流程、平台、应用架构的变革）生 态 要 求(3)容器

21、应用部署 运维自动化（自动编排部 署、弹性伸缩、监控运维）(4)微服务 应用业务 微服务化（新建、改造）软件自动化（应用少量适配）Cloud-Native（应用架构重构）(1)虚拟化 基础设施 资源池化（单体应用、手 工部署）(2)服务治理 历史服务快速 接入治理框架（自助申请、 自动发放）实施 节奏 建议路线1：“跳跃式”路线2：“渐进式”全面 云化 演进 建设 路径平台类ISV 业务范围应用类ISV 业务范围APP（业务逻辑）(4)(3)平台能力(2)(1)（数据库、运行时、中间件等，如CBB组件）OS基础设施传统应用软件栈端到端的云Stack金融技术中台解决方案，加速金融数字化转型技术沉

22、 淀产品经验沉 淀服务云容器引擎CCE微服务引擎PaaS平台底座（通用PaaS能力）开发测试DevOps 调用链APM应用运维APM标准化服务集成建设（集成设计/系统开发/集成验证/试运行/集成验收）运营运维咨询规划DevOps规 划 咨 询业 务 应 用 平 台 咨 询微 服 务 改 造 咨 询开源通用中间件商用通用中间件行业ISV中间件DevOps实施服务软件开发管理服务中间件开发支持服务服务目录开发支持服务微服务/容器化开发支持服务API对接开发支持服务应用上云开发支持服务最佳指导中间件集成服务按需使用云化开发集成管理服务管家服务PaaS规划设计与实施基础服务咨询规划服务最佳策划商业级分

23、布式中间件市场（分布式改造能力中心）分布式缓存DCS分布式消息DMS分布式事务DTM其他服务API网关APIG云Stack拥抱第三方组件，开放生态！金融数字化转型中台落地总结角 色定 义规划建设部门负责整体IT系统建设和云平台规划建设的部门平台运维 部门负责云平台（含IaaS、PaaS等） 的整体建设和运维业务 部门提出公司新业务商业场景的部 门，比如市场部，负责公司数 字化业务的规划和提出业务开发部门负责业务系统的开发、测试或迁移的研发团队或ISV合作伙伴业务运维部门负责业务上线生产系统的运维部门，对业务SLA保障负责管云上云/用云建云IT系统摸底调查应用上云评估规划建云评估与规划建云用云规

24、划应用迁移规划中台架构规划DevOps转型规划制定业务 上云计划租户项目申请软件基础设施申请应用开发或改造自动构建应用建模部署设计应用管理弹性伸缩故障自愈灰度升级业务测试业务上线平台运维规划建设/业务部 门/平台运维部门业务开发部门/运维部门业务开发/业务运 维/平台运维部门规划建设/平 台运维部门规划建设部门业务部门/ 业务开发部门/ 业务运维部门租户租户（开发/测试/运维）（开发/测试/运维）租户（开发/测试）租户（开发、测试）租户（开发/测试/运维）租户（开发/测试）租户（交付/运维）单元测试集成测试验收测试部署架构 设计高可用设 计租户（运维）监控运维需求/bug持续迭代容量管理扩容评

25、估集群扩容故障处理日常运维应用驾驶舱组织权限 角色管理中台服务 运维管理安全管理在网性能压测平台运维部门持续集成 CI持续交付 CD业务应用平台咨询微服务改造咨询 DevOps规划咨询容器化开发支持服务微服务开发支持服务API对接开发支持服务28遗留应用C微服务Java微服务微服务引擎：多元、开放的云原生微服务框架，更快开发低门槛开发微服务开发框架（标准OpenAPI，多语言）微服务高级治理服 务 发 现服服 务 路 由多 通 信 访 问调 用 链 跟 踪务配置微服务基础治理多 事 务 管 理多 运 行 时 管 理ServiceMesh&容 错熔 断限灰监流度控降发分级布析微 服 务 安 全0

26、改动接入Service Mesh客户价值兼容利旧，敏捷开发 适应未来的云原生架构经历终端云亿级用户考验WeLink手机办公平台首选架构挑战烟囱式大颗粒应用无法满足DevOps 遗留应用与创新应用如何快速接入？ 海量微服务如何治理？产品亮点创新应用Go微服务29统一微服务治理* 微服务引擎 ServiceComb 是Apache基金会的顶级开源项目；* 社区网站：http:/servicecomb.io/微服务设计最佳实践 领域驱动设计（DDD）领域驱动设计的核心思想：技术专家、领域专家一起，建立统一的语言，通过事件风暴、命令风暴、寻找聚合、划分上下文边界，从而定义微服务。30云中间件平台-帮助

27、企业轻松应对业务分布式改造和涌浪DCS分布式缓存中间件适用于高读写性能场景及弹性伸缩 的业务需求，提高网站访问性能。 如视频直播、电商行业促销秒杀。DMS分布式消息中间件提供高可靠、可扩展的托管消息队 列，提升系统响应速度，轻松应对 数据洪峰。DTM分布式事务中间件高性能、高可靠、接入简单的分布 式事务中间件，解决分布式系统的 事务一致性问题。31分布式消息服务DMS功能特性及场景分布式消息服务一键部署： 免去重复搭建 无忧运维数据高可靠：消息持久化，多副本高可用：集群架构，跨AZ弹性扩缩： 海量消息堆积， 高度可扩展性安全加固，更可靠： 提供云端审计、消息 加密、网络控制基于开源：支持开源，

28、零改动为应用系统提供异步消息队列服务，通过高可用的消息缓冲队列，实现应用解耦、突发流量处理及与第三方集成。典型场景：处理用户上传任务，报告生成，日志传输，推送通知等32为什么需要消息服务？在云上提供分布式消息队列的服务， 让用户使用更加方便、高效、快捷、 免运维，让应用具有分布式、可扩 展、高可用性能力系统解耦削峰填谷异步通知数据交换日志通道基于发布订阅模型和异步通信，增加应用水 平扩展性和快速响应能力大促等流量洪流来袭时，消息服务可以缓冲 突发流量，避免整个系统崩溃解决1对多数据交换，解决多服务模块数据 汇聚海量终端数据接入、高吞吐、低时延实时并 发消费消息做为重要日志的监控通信管道，将应用

29、日志监控对系统性能影响降到最低33分布式消息适用场景订单系统订单数据库库存系统积分系统仓储系统库存数据库积分数据库仓储数据库DMS1233334分布式缓存中间件DCS功能特性及场景分布式缓存服务规格灵活：主备、集群，最大可至 1024GB基于开源：Redis完善的API接口数据安全： 租户物理隔离， 支持跨AZ高可用多维安全加固，更加可靠高性能：单实例 QPS10W+WEB页面缓存会话数据缓存配置数据缓存业务数据缓存使用特点：高性能读写(百万级并发)，数据 量G级别，多种数据类型，需要持久化解决问题：提高数据查询和读写效率，减轻管理维护工作量，降低数据库存储成本主要应用场景为应用系统提供高性能

30、的Key-Value的缓存数据库服务。有效提升热点数据访问速度，并大幅降低数据库的压力。典型场景：热点数据访问加速、非关键数据/过程数据在缓存读写，降低数据库负荷。35DTM保证分布式事务一致性价值避免因数据不一致问题带来的经济损失高性能：每秒完成2500+分布式事务高可用：服务器集群高可用，秒级故障自动恢复广泛性：支撑各种服务框架、关系型数据库简单易用：事务注解或API接入，开发成本低挑战微服务拆分与分布式应用如何保持将数据一致性？亮点支付系统存款帐户传统核心内部帐DTM试 探试 探试 探同步试探结果试探结果？提交/ 撤 销提交/ 撤 销提交/ 撤 销Y/N36高效管控、统一规范、稳定安全的

31、API开放平台API 管理API Administrator轻松管理、统一规范API生命周期管理API创建微网关管理API兼容性保障微网关API Micro Gateway灵活安全、敏捷集成高性能路由转发协议开放：REST、SOAP安全访问、流量控制服务自动发现API 分析API Analytics精细监控、稳定可靠API调用分析API运维监控开发者门户Developer Portal统一管控、友好体验API产品目录APP生命周期管理API订阅API资料检索定义、创建、发布APIAPI提供者获取、学习、订阅、调用API消费者审批、分析API系统管理员API运行与安全API通道37云容器引擎核心

32、技术堆栈业务“伸缩快”故障“定位快”混编应用与中间件混编弹性应用生命周期管理自动化分布式应用编排部署中间件智能应用性能监控分析资源“准备快”应用 “上线快”CCE：云原生应用生命周期管理平台Software RegistryHELMCluster ManagementIngressControllerAPMPolicyEngineS2I/B2ICNIiCAN IPv6CSIFuxi FusionStorgeK8S + DockerCCMCRIFusionSphereEuler DockerFusionComputeSuse DockerDevice PluginNvida GPU D-芯片38

33、云容器功能架构图容器网络：iCAN自研技术，支持L2 Overlay网络模型容器存储：支持临时存储和持久化存储；支持指定存储类型 申请块存储；支持容器实例迁移后，块存储卷跟随迁移软件仓库：支持软件仓库管理(镜像/模板)，支持S2I/B2I应用管理：支持故障迁移、服务升级、灰度发布(ALB配合)应用运维：支持应用/实例/容器等全维度监控，支持日志分析弹性伸缩：支持定时伸缩、周期伸缩，支持自定义弹性伸缩 策略关键能力39容器技术3大典型场景及价值应用快速部署实现应用快速上线应用弹性伸缩提升资源利用率应用自动升级不中断业务运行支持容器和非容器应用部署部署时间通常在秒级启动亲和性：就近部署，就近路由反亲和性： 高可靠性考虑，减少宕机影响，避免干扰。按需扩容或缩容应用资源节点，即可以 保障业务高可靠运行，又可以合