来源:年第二届中小金融机构数智化转型优秀案例评选
近年来,随着金融科技的快速发展,各商业银行纷纷加快IT架构优化调整,向分布式架构进行转型。年以来,齐商银行按照“整体规划、分步实施”的策略,在分布式微服务架构转型方面进行了一些实践和探索,现已初见成效。
一、项目背景和挑战
齐商银行成立于年8月,作为一家地方城市商业银行,始终坚持“科技兴行”战略,尤其是在年制定了中长期信息科技发展规划,明确了数字化转型的目标及路线,加快了信息科技建设进程,形成了覆盖了渠道、客户服务、产品处理、会计、数据服务、管理分析等领域余套信息系统的建设成果。但随着数字化转型的深入,传统的IT架构难以支撑各类金融业务在市场、监管、组织架构等方面的频繁变化,主要表现在:
(一)各应用系统之间功能和数据相互孤立,存在功能重复建设和数据不对称的现象,难以满足多场景、快速迭代的业务发展需要;
(二)单体系统内部紧耦合,需求升级对其他功能模块的影响难以评估,加大了开发、测试的工作量和周期;
(三)集中式架构高可用性不足,所有业务都运行在一台主机设备上,一旦发生故障就可能影响到业务的连续性。
为了让科技创新更好的支持业务快速发展,年我行开始启动技术架构转型升级,以达到提升掌控能力,降低系统运行和维护风险以及提升系统快速交付能力的目标。在实施过程中,面临诸多挑战,包括:
(一)微服务架构的关键技术选型是落地的关键,在当前市面上存在多个流行的微服务技术栈,如何在其中选择适合自己的,对于缺乏经验的我们是一个考验;
(二)微服务架构自身存在明显的优势,但同时也带来诸多新问题,如分布式架构固有的复杂性,对项目实施和运维人员提出了更高要求等,哪些系统适合采用微服务架构需要慎重选择;
(三)现有系统中大部分是引入外部厂商的产品,系统架构不统一,难以统一规划,如何在架构转型中对存量系统的服务进行构建等。
二、项目上线时间
分布式微服务架构整体设计完成之后,选择CRM作为平台应用实践。项目从年7月开始启动,在年12月完成验收上线,标志着我行分布式微服务架构正式部署使用。
三、分布式微服务架构应用技术
分布式微服务架构目标是建立全行级信息系统架构标准,坚持开放、敏捷的原则,通过跨平台的服务复用和编排,快速实现业务场景,具备多活、故障隔离和自动扩容能力。在统一的服务注册中心中,具备服务注册发现、负载均衡、黑白名单管理、流量控制熔断等服务治理机制,对不同的应用系统按照租户概念进行隔离管理,租户之间通过授权实现服务共享。
(一)关键技术选型
通过对多种分布式微服务整体解决方案做了调研分析后,最终制定了总体技术体系:
Nacos作为服务注册中心及配置中心
使用使用Feign来实现服务互调
使用Ribbon作为负载均衡器
采用了Hystrix的作为熔断器
利用SpringBootAdmin监控各个独立服务的运行状态
使用SpringCloudGateWay实现服务网关
Swagger作为在线文档自动生成
分布式系统流量防卫兵使用Sentinel
使用zipkin实现链路调用跟踪
vue+element-ui支撑前端开发
(二)技术实现说明
1、基于阿里Nacos来实现服务管理中心,支持SpringCloud和Dubbo等多种分布式主流架构的微服务注册和发现,使用Feign封装基于HTTP方式的API接口暴露,满足不同开发语言的客户端进行服务访问。
2、自行实现服务访问安全管理,配置中心对接入消费者进行登记,并分配相应的授权码。外部系统在服务调用时需通过鉴权验证合法性,服务网关先后进行授权码校验有效性性、黑白名单的检测、服务权限授权情况,充分保证系统功能和数据的安全性。
3、使用Ribbon技术实现服务高可用和负载均衡,通过心跳轮询服务列表方式自动检查微服务的健康状况,及时维护可用服务列表,剔除不可用的服务或者加入可用服务,根据监控服务生产者的响应时间优化分配权重,也可自行设置权重。
4、利用熔断机制实现微服务链路保护机制,避免服务之间调用出现“雪崩效应”。通过Hystrix技术框架监控微服务间调用的状况,当失败频率达到一定阈值或系统过载时,平台自动启动熔断机制,进行服务的降级或熔断该节点微服务的调用,当检测到该节点微服务调用响应正常后,恢复链路调用。
四、实施过程
我行分布式微服务架构的实施经历了架构选型设计、实施论证、推广使用等三个阶段。
(一)架构选型设计
架构选型时综合评估了Eureka、Zookeeper、Consul和多家厂商封装的注册中心,选用以Nacos为基础进行二次改造,实现多种微服务架构一个注册中心,进行服务治理、策略统一配置下发。微服务开发框架同时兼容SpringCloud和Dubbo主流的架构。《齐商银行分布式微服务架构规范》对前端和数据库持久层进行的技术栈的规范约束,使用VUE+SpringCloud+Mybatis封装了系统快速开发脚手架。
(二)实施论证
CRM系统承载了全行客户管理和产能提升等功能,包括了系统管理、工作平台、客户管理、产品管理、营销活动、考核管理、权益服务、短信服务、报表管理、文件管理十个功能模块,功能模块之间边界相对清晰,也是其他系统进行客户分析的主要数据来源,比较适合使用分布式微服务架构,因此选择作为架构落地实践项目。
1、微服务拆分
按照功能模块将CRM横向切分成不同的微服务群集,每个群集内按照业务场景进行纵向切分,遵循高内聚低耦合、服务力度适中的原则设计原子微服务,所有的微服务做到无状态化,通过对微服务进行编排实现不同的业务场景。
2、微服务的管理
CRM中所有服务的生产者和消费者通过RPC协议实现服务的动态发现及注册,通过一套简洁易用的UI界面管理所有的服务,包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的SLA以及最重要的metrics统计数据,让服务的管理变得更加高效和敏捷。
3、运维管理
微服务架构部署节点多,为了合理使用硬件资源,降低运维难度,我行同时引进Docker容器管理平台,利用平台持续部署流水线的自动化部署能力,实现程序包自动部署,有效避免人为失误,提升发版效率。结合平台可视化应用编排、自动化弹性伸缩、一键巡检、故障隔离、故障自愈等运维管理能力,降低运维复杂度,减轻了运维人员的日常运维压力。
(三)推广使用
分布式架构落地验证成功后,又在多个信息系统中成功实施,包括综合积分权益平台、交易银行系统、理财销售系统等,此架构规范也是我行今后信息系统建设的硬性要求。今年5月份我行也启动对已上线系统进行微服务化改造升级,典型的信贷系统于年上线,随着每年的需求升级,已经变得非常臃肿和难以维护,目前启动了押品管理、统一额度管理、风控管理三个功能模块的剥离和微服务化改造。
微服务跨平台复用能力减少了系统开发周期,为了持续提升研发敏捷化程度,我行在微服务架构基础上自主研发了可视化服务编排工具,通过对微服务组件拖拉拽完成场景流程的实现,目前已经应用在了新的中间业务平台。
我行信息系统最终建设目标是实现“统一的服务注册管理中心+各业务系统微服务群集”的全行系统逻辑关系,每个业务系统微服务群集包含若干个独立的业务场景微服务,实现全行级别服务集中共享能力。
五、经验总结
微服务架构技术优势明显,但存在较高的技术门槛,经过初期的探索与实践,我行的技术团队积累了一些经验,希望给正在或即将进行微服务架构的同行一些借鉴。
(一)分布式微服务架构的部署的节点较多,以CRM为例,传统单体架构只需要部署主备2个节点即可,新的系统架构需要部署22个节点,生产问题跟踪变得很复杂,我行在系统开发规范中明确规定日志文件和流水记录使用全局统一业务流水号,配合Zipkin及日志管理平台的使用,最终实现日志的全链路追踪。
(二)分布式架构通过跨平台服务共享解决了代码冗余的问题,也出现个别业务场景升级导致其他调用者受到影响,我行在开发规范中规定每个微服务对开放的API接口都包含版本号信息,需要同步进行升级的消费者改用新版本的接口,不受影响的消费者继续调用原版本的服务接口,在服务注册中心中监控某个服务不再有消费者的时候,将进行服务下架。
六、应用效果
(一)分布式微服务架构固有的跨平台服务共享能力,大大提升了我行中台化系统建设能力,CRM系统打通了各个应用系统客户信息维护的孤岛,实现了全行统一的客户信息管理中心和客户服务管理中心,丰富了客户标签数据,为精准营销提供了可靠的数据来源。CRM系统的上线,解决了信贷、供应链、营销系统、移动展业系统、客服、电子银行等多个系统需要展示客户全景视图的难题。在统一风控平台中,避免了网贷系统、信贷系统、供应链融资等系统重复建设风控引擎功能,风控模型统一管理后不但避免重复开发也保证了全行级别模型输出结果的一致性。
(二)新的系统架构具备高可用和自动服务伸缩能力,有力支撑了我行“疯狂星期二”的营销活动。每周二上午十点,齐乐惠商城近千件优惠商品在一分钟内瞬间被抢完,系统完美的支撑了这种陡增的业务量。而服务在初期部署时仅需支持正常情况下的业务需要的资源,管控平台侦测到服务资源到达上限阈值时,会自动克隆出一个新的节点,在业务量回归正常值的时候会自动释放新增节点。
(三)在新的系统框架规范下,所有的服务都具备随时开放的能力,系统之间交互更加便捷,服务提供方仅需在控制台上实现白名单授权即可。在交易银行里新增业务场景所需成本和实施周期降为传统架构系统的三分之一。伴随着新业务需求不断沉淀可复用的微服务组件,系统开发的工作量有明显下降趋势,新中间业务平台目前已经积累了一百多个可复用的功能组件,目前正在努力建设成为无代码开发平台。
更多金融科技案例,请登录数字金融创新知识服务平台-金科创新社(FintechinChina.