简介《新一代金融核心业务系统云架构》演示文稿面向金融行业信息技术架构师、核心系统建设者及技术决策者完整呈现一家中小型寿险公司利用云平台重构核心业务系统的实践路径。内容从技术陈旧、集成困难、批处理性能差等真实痛点切入随后给出公有云、私有云、混合云组合部署以及基础设施即服务、平台即服务、软件即服务分层服务的总体设计并重点拆解批处理平台的多租户平台化改造包括ZooKeeper分布式调度、动态节点管理、故障自动转移与数据隔离方案。资源共1个PPTX文件大小2.58MB已有91人浏览学习既覆盖顶层架构思路也包含平台化落地的具体实例全片按项目背景、云平台设计、批处理与用户管理两个实例展开结构清晰便于按模块查阅可借鉴其分层设计、多租户隔离和动态调度经验减少试错成本适合正面临核心系统升级、云化转型的团队快速获取经验。1. 云架构改造不是推倒重来新核心系统云平台的第一手拆解看云架构的PPT很多翻到这份《新一代金融核心业务系统云架构》还是有点意外——它没堆概念讲的是一个真实到有点扎心的项目。农业银行控股的一家中小型寿险公司业务年增长50%以上核心系统却是2007年用JDK 1.4.2和JSPServlet搭的集成不动、扩容没门、批处理慢到影响开单。IT想跟上业务又怕推倒重来翻车。这份PPT就是他们的解题过程不换底层IOE而是用私有云PaaS把批处理、用户权限这些基础能力抽成平台让新应用开发只管业务逻辑。适合正在被遗留系统拖累的金融IT从业者看。2. 新核心系统的云平台设计私有云为主PaaS十个件怎么取舍2.1 部署模式与服务模式从公有云到混合云的路线这套云平台在部署模式上分了三层当前核心生产全部放在私有云公有云定位在远期非核心业务的对接混合云作为远期规划用来应对业务峰值时的资源突发。保险行业对数据安全要求高核心保单数据、客户信息放在私有云是底线这一点最开始就定了没有争议。服务模式上更值得琢磨。SaaS层是待规划状态IaaS层只有三样东西VMware虚拟化、Oracle 12C数据库、Weblogic 12C中间件。真正的重头戏是PaaS层一共规划了10个平台组件。也就是说他们没打算直接用别人的SaaS而是把软件能力自己抽成平台再支撑上层业务系统。这个选择对传统金融公司来说非常典型SaaS买来改不动核心逻辑IaaS只是把物理机换成虚机只有PaaS既能控制权在自己手里又能把公共能力沉淀下来复用。2.2 PaaS十组件清单与选型理由商业、自建、二次开发三分PPT里PaaS的10个组件可以整理成一张表能看出当时每个组件的状态和实现方式组件用途实现方式状态流程管理业务流程编排IBM BPM商业产品完成规则管理业务规则配置与执行IBM ODM商业产品完成内容管理文档、影像等非结构化内容商业产品实施中监控平台系统与业务监控MONITA自研实施中分布式事务管理跨服务事务一致性DTX自建实施中用户管理用户、权限、认证统一管理UM自建自建完成批处理平台大规模批量数据处理Batch自建合作厂商二次开发完成报表平台报表生成与展示自建自建完成渠道接入平台对接各类业务渠道CIPS自建完成产品工厂保险产品参数化配置自建自建完成这里能看到一个明显的倾向商业产品只买了两个关键的——IBM的流程和规则引擎因为保险业务里流程审批和规则变更是最高频的自己从零写成本太高、稳定性没保障。其余能用Java自研的全部自研而且Java体系里面一个开源中间件都没选。原因很直接传统金融公司不敢让开源组件出问题没人兜底商业产品再贵至少出了问题能找到人。这个决策无关技术优劣纯粹是风险偏好决定的。2.3 为什么强调“充分利用现有资产”三个不跟风的决策这份PPT里最反常识的部分就是“跟别人有点不一样”那一页。大多数云架构规划都是从清理技术债开始他们反而提出三个原则充分利用遗留应用系统充分利用已购买的软硬件资产充分利用现有人员的知识技能。拆开看这三个原则不是口号。遗留应用系统的价值在于业务逻辑沉淀——保险核心系统的承保、批改、理赔逻辑跑了十年里面全是真实的业务规则这些规则不可能靠重写IT系统重写出来。已购软硬件资产指的是之前买的Weblogic、Oracle、VMware这些授权费用不便宜直接弃用等于之前几百万打水漂。人员知识技能则更现实团队熟悉的Java技术栈改造时坚持Java Only就不会出现招不到人、现有团队接不住的局面。这套方案的底层逻辑是上云是为了让业务跑得更快不是为了展示技术先进性。3. 批处理平台改造从Batch到Batch PaaS的核心模型与改造路径3.1 Job-Task-Executor三件套并行批处理的编程模型批处理平台是这份PPT里着墨最多的实例也是技术含量最高的部分。原生的批处理系统是单机顺序执行改造后的Batch PaaS把一次批处理拆成三个概念Job是整个业务任务比如“分红批处理”Job被拆分成多个并行执行的分片每个分片叫Task真正执行Task逻辑的代码叫Executor。这个模型要落地开发人员只需要关注三个Java接口。PPT里明确写了Java Only所以下面的接口设计是这套平台最可能的落地形态/** * Job拆分器把一个大Job拆成多个Task */ public interface JobDistributor { // 返回拆出来的Task列表每份Task要带独立的参数范围 ListTask split(Job job); } /** * Task执行器真正执行一个Task的逻辑 */ public interface TaskExecutor { void execute(Task task) throws Exception; } /** * 共享资源封装初始化数据库连接池、缓存、Spring上下文 */ public abstract class SharedResourceHolder { protected DataSource dataSource; protected CacheManager cacheManager; protected ApplicationContext springContext; // 子类必须实现资源初始化 protected abstract void initResources(); }开发人员学这套平台需要理解五个概念但真正要写代码的只有三个地方实现split逻辑、实现execute逻辑、继承SharedResourceHolder封装公共资源。其余什么节点间通信、任务下发、失败重试都是平台兜底业务开发感知不到。拆分粒度是第一个要定的参数——以保险分红批处理为例几十万张保单如果按一张一条Task拆Task数量会被推到十几万光任务调度的开销就不可接受。常见做法是按数据量分页每页2000条左右一个Task既保证并行度又不会让调度器被压垮。3.2 ZooKeeper在这套架构里管什么节点感知与故障转移批处理平台能实现PPT里写的“无单点故障、支持节点动态增减、自动故障转移”核心依赖是ZooKeeper。Executor启动时向ZooKeeper注册临时节点Job提交后由Distributor从ZK拿到当前存活的Executor列表把Task派发下去。一旦某台Executor所在节点宕机ZK的会话就会断开临时节点自动消失平台立刻感知并把该节点上还没完成的Task重新派发给其他存活节点。ZooKeeper在这个场景里不是可有可无的选择。Eureka这类注册中心只能做服务发现而批处理平台还需要分布式锁防止同一个Job被重复提交、队列Task排队和领导选举管理节点高可用。一套ZK全解决了这是它被选中的根本原因。关键参数在sessionTimeout。默认值通常是10秒但批处理节点的特点是任务执行时CPU和磁盘IO吃满容易造成心跳发送延迟被ZK误判为宕机。我一般会把这个值调到20到30秒同时把心跳发送单独放一个线程不要和任务执行的线程池抢资源。3.3 原部署结构与PaaS化后的差异二次开发做了哪些事原批处理平台的部署结构是固定的几台服务器跑批任务写死在这几台上。问题很明显服务器数量固定业务量增长后跑批时间只能干等某台机器出故障它负责的任务全部中断没有自动转移机制。改造后的Batch PaaS三层结构是最上面管理平台负责Job调度和资源分配中间是ZooKeeper集群做协调底层是动态的计算节点池。用户提交一个Job后Job经过Distributor拆分分发到多个Executor并行执行。计算节点不是预先装好的固定几台而是维护一个资源池按需扩容。所谓“二次开发”的部分是把合作厂商原产品的基本框架保留围绕PaaS化补了三块支持多租户支持虚拟机动态分配支持数据库和中间件的动态分配。其中虚拟机动态分配已经实现数据库和中间件的动态分配在PPT里明确标了“未完成”。这个边界很重要——看方案时不能把PPT上画的全当成已经落地的能力哪些是现状、哪些是蓝图要分清楚。4. 多租户与动态分配批处理PaaS化的两块硬骨头4.1 多租户的三层隔离数据、性能、安全缺一不可多租户的初级理解是在用户表加个字段区分租户但批处理平台的多租户完全不是这个量级。原系统每个用户都能查看和管理所有批处理任务批处理会自动分配到所有服务器上执行数据库访问由批处理程序自己设定。这在多租户场景下同时踩了三个雷越权访问、资源争用、数据泄露。改造后变成三层隔离对照着看更清楚隔离维度原系统问题新系统方案数据隔离批处理程序自行设定数据库访问越权风险高用户只能访问自己的数据库数据源由平台统一控制性能隔离所有用户的批处理在全部服务器上混合跑互相抢资源每个租户的资源池独立批处理只在自己的服务器上执行安全隔离任何用户可查看和管理所有批处理只能查看和管理自己的批处理并且由授权审批流控制三层隔离里最难落地的是数据隔离。不能靠SQL加where条件控制因为批处理程序里到处是原生SQL根本改不干净。正确的做法是在数据源层面做隔离每个租户连接自己的数据库代码里拿数据源时按租户ID取出对应连接。关键实现是租户数据源缓存// 租户数据源管理每个租户独立数据库连接 public class TenantDataSourceManager { private MapString, DataSource tenantDataSourceCache new ConcurrentHashMap(); public DataSource getTenantDataSource(String tenantId) { // 缓存命中直接返回 if (tenantDataSourceCache.containsKey(tenantId)) { return tenantDataSourceCache.get(tenantId); } // 首次访问从租户配置表读取数据库连接信息 TenantDbConfig config getConfigFromDb(tenantId); DataSource ds createDataSource( config.getJdbcUrl(), config.getUsername(), config.getPassword() ); tenantDataSourceCache.put(tenantId, ds); return ds; } }这里最容易翻车的是缓存膨胀。租户数量多、每个租户一个连接池会占满数据库连接资源。常见做法是给连接池加最大连接数限制并且空闲超过一定时间就释放。另一个细节是租户上下文的传递JDBC连接拿到后要确保整个调用链里都用的同一个租户数据源不能中途被全局默认数据源顶掉。4.2 虚拟机级动态扩容从申请到审批到自动创建动态分配是批处理平台PaaS化的另一大改造。原系统如果计算资源不足要走审批流程甚至采购流程等服务器到货再部署环境业务等不起。新系统的流程是一整条自动化链第一步用户发起计算节点申请指定CPU和内存规格。第二步虚机管理员审批审批通过。第三步系统自动调用VMware接口按照模板创建虚机这一步不需要人工登录vCenter操作。第四步批处理管理员把新虚机授权给该租户使用。第五步用户的Job下一次运行时就可以把Task调度到新节点上跑批时间立刻下降。这个流程里调用VMware接口创建虚机的动作可以用一个接口抽象出来后续接其他虚拟化平台也好替换/** * 虚拟机资源供给接口 */ public interface VmProvisioner { // 按模板创建虚机返回虚机唯一ID String createVm(String templateName, int cpuCores, int memoryMB); // 查询虚机状态判断是否已就绪 String getVmStatus(String vmId); // 回收虚机释放资源 void deleteVm(String vmId); }创建虚机不是瞬间完成的事虚机启动后还要等操作系统起来、中间件和应用部署好。所以接口调用之后需要轮询虚机状态状态变成READY才算真正可用。另一个必须处理的细节是“预授权”模式——管理员可以为租户预创建一批虚机挂在那里用户提交Job时不用临时申请直接从资源池拿。这样既保证了审批合规又避免了申请过程的等待。4.3 没做完的部分Oracle数据库和Weblogic的动态分配PPT里很坦诚地标注了两个未完成的动态分配Oracle DB和Weblogic。这不是藏着的坑而是技术上的硬边界。虚拟机可以随时创建销毁因为它的状态就在虚机文件里不依赖外部基础设施。但数据库动态分配涉及的问题多得多数据要迁移过去数据库连接要切换事务要保证一致性Oracle RAC本身的网络配置和license还限制着节点扩容方式。Weblogic的动态分配也没完成因为中间件集群的扩展需要同步修改应用部署包、数据源配置和进程管理脚本这中间任何一步出错都会让整个集群不可用。这笔账值得记下来先做虚拟机级动态分配看效果、积累经验再逐步向数据库和中间件层面的自动弹性推进。步子迈小了最多慢一点步子迈大了真的会翻车。5. 云化改造避坑指南五个常见问题与排查思路5.1 遗留代码与新运行时的兼容性冲突现象把老的批处理程序直接改造成Executor放到新平台后启动报LinkageError或者NoSuchMethodError有些老代码用到的私有API在新JDK里整个被移除。原因老系统跑在JDK 1.4.2上新平台的运行环境已经是JDK 6/7javax包、数据库驱动、日志库的版本全部变了。老代码里为了绕旧版缺陷写的hack代码在新版本上直接跑不起来。更隐蔽的是jar包冲突同一个类出现多个版本ClassLoader加载到哪个全看命。解决先做全量jar依赖清单把所有第三方库的版本钉死用启动脚本里的-classpath参数显式指定而不是靠环境变量。另一个常用方案是把老程序的核心计算逻辑提取出来重新编译而不是整包迁移——编译一次就能暴露大部分API不兼容问题。从这套项目的经验看跑批程序这种“重计算轻交互”的老代码在Java体系内做过一次编译升级后绝大多数兼容问题都能暴露在测试环境里。5.2 ZooKeeper把“活着”的节点误判为宕机现象生产环境一台Executor节点并没有真正的故障但ZK会话超时临时节点被删掉平台判定节点死亡把任务全部转移走形成不必要的调度抖动。原因批处理任务执行时CPU使用率打满ZooKeeper客户端心跳线程得不到调度心跳发送延迟累积超过sessionTimeout后ZK就断开了会话。解决先把sessionTimeout从默认的10秒调到25秒到30秒给GC停顿和CPU抢占留出余量。再把ZK客户端的发送心跳逻辑独立成单独线程并设置合理优先级避免被业务线程池饿死。最后要做好监控可视化的会话状态面板这样大促期间就能一眼看到哪些节点心跳异常而不是等Job失败才查日志。5.3 动态创建的虚机环境不一致现象通过VMware模板动态创建的虚机有的跑批成功有的跑批报错报错信息五花八门找不到规律。原因虚机模板创建后被更新过或者创建时拉取了最新的依赖包快照而不是固定版本。不同批次创建的虚机环境本来就不一致。批处理任务对运行环境极度敏感差一个小版本号的驱动结果都可能不同。解决镜像模板统一基线版本打一个版本标签比如gold-image-v20231201。应用版本通过配置中心下发不放入镜像中。虚机启动后要进行环境自检检查java版本、jar包版本、关键配置文件为预期值校验失败则不允许注册到ZK节点池。从那以后每次新增虚机我都要看到自检通过才敢跑批。5.4 租户数据源误连A租户跑批处理用了B租户的数据库现象多租户隔离上线后租户A提交的批处理有时能把租户B的数据读出来差点酿成严重事故。原因数据源缓存用租户ID做Key这个Key在某条调用链上没有正确传递。共享线程池里上一个租户的ThreadLocal没有清理下一个租户任务复用线程时拿到的是上一个租户的数据源。解决必须在每次任务执行前用当前租户上下文重置数据源。关键点有两个一是ThreadLocal在线程归还到池子前显式移除二是数据源查找逻辑里加租户和非租户双向校验。另外像这种跨租户数据混淆的问题把数据源连接串打印到运行日志里做审计非常好用一次就能定位是哪跳传错了。5.5 故障转移后Task重复执行数据重复入账现象某计算节点宕机平台把Task自动转移到其他节点重新执行。任务本身跑完了但有一部分数据已经写入数据库重复执行后同一保单被处理了两次。原因Task执行成功但结果还没来得及上报就发生了故障转移平台不知道它已完成于是重新派发。批处理程序本身不是幂等的重复执行必然出问题。解决最有效的方式是Task表增加执行状态字段包含执行批次号、Task状态、完成时间。平台派发Task之前先查调度记录确认这个Task在当前批次中没有已经完成的记录。批处理程序侧同步做幂等控制对关键的表操作加唯一索引重复插入时捕获异常跳过。这两层一起设才能保证“最多执行一次”。6. 用户管理PaaS的杠杆效应公共模块抽出来才是云化改造的真正转折点批处理平台是这份PPT里最显眼的实例但从省钱省力的角度看用户管理UM PaaS反而是更有杠杆价值的平台。原因很简单批处理平台只服务于跑批这一个场景而用户、权限、认证这些能力是每一个业务系统都要用的。旧系统里每个应用单独做登录和权限管理相同功能重复开发五六遍每次权限逻辑改起来还容易出漏洞。核心系统云化改造的第二年他们把用户管理抽成UM PaaS所有新建应用接入统一认证和权限点审批审计问题大幅下降权限管理效率提升明显。UM PaaS的关键设计是权限点全生命周期管理。每个应用开发时需要申请自己的权限点经过审批后生效。用户被授予权限后拿token访问各个应用由统一平台校验。这样权限点从注册、审批到回收每一步都有记录。这个思路放到任何金融公司都适用核心逻辑就是横切能力集中化。批处理平台解决的是“跑得动”UM PaaS解决的是“管得住”两者合在一起上面的业务应用开发真的只需要关心业务逻辑开发量只剩下原来的两成。从那以后我评估任何一个云化改造方案第一件事就是看它的用户权限管理是独立PaaS还是继续散落在各个应用里第二件事看批处理这类重任务有没有统一的调度托管平台。这两个问题答案对了方案基本靠谱答案不对的哪怕虚机画得再漂亮也只是把旧架构换了个包装不是真正的云化。判断真伪PaaS就看基础件是不是独立平台而不是凭虚拟化程度。希望帮到你。本文还有配套的精品资源点击获取