APP下载

破茧化蝶:中邮消费金融系统服务化和容器化实践

消息来源:baojiabao.com 作者: 发布时间:2024-03-28

报价宝综合消息破茧化蝶:中邮消费金融系统服务化和容器化实践

消费金融是近年来新兴的热门行业,市场广阔、需求量大、行业竞争激烈。为了突破传统金融行业限制,建立一套灵活、高效、可靠的消费金融系统,支持互联网环境下高并发访问、可靠资金交易、互动式场景化的需求,中邮消费金融从基于集中式商业中间件搭建的传统信贷系统,演进为基于微服务、分散式、灵活快速迭代的互联网消费金融系统。

在 2018 年 12 月 7-8 日北京 ArchSummit 全球架构师技术峰会上,我们邀请到了中邮消费金融 IT 运营部总经理助理 & 架构师 李远鑫老师从服务化和容器化两个方面剖析中邮金融系统的迭代更新。

服务化演进

开业初期,为了能够迅速把 IT 系统搭建起来,支撑公司的业务开展,我们基于集中式的商业中间件构建了一套传统的金融信贷系统,涵盖了贷前、贷中和贷后管理,采用的是烟囱式架构,属于传统的交易型 IT 系统,这样的架构在业务高速发展的过程中显得开发迭代更新效率低下、创新困难、难以扩展,形成数据孤岛。为此,我们采用了“大中台、小前端”的中台战略,将应用架构设计为渠道、应用、共享服务中心和基础技术平台四个层次,其中共享服务中心按照业务领域来划分,尽量将原有的业务功能进行解耦,沉淀出公共部分,采用微服务的方式进行构建,整个系统架构也由原来的集中式架构转变为分散式的架构,不仅提升了系统的整体性能和可扩展性,也使新业务和新产品的开发效率有了明显的提升。本次主题的第一部分将分享中邮消费金融从烟囱式系统向多个共享服务中心演进的服务化实践。

分散式技术平台的搭建

共享服务中心建立在分散式技术平台之上,主要包括服务调用和治理框架、消息中间件、缓存、分散式文件系统、分散式数据库等。这里重点介绍服务调用、消息中间件和应用配置中心的搭建情况以及分散式事务处理的方案。

(1)在服务调用框架方面,我们早期对 DubboX 进行了裁剪和优化封装,作为主要的微服务开发技术,后续逐渐以 Springboot+Jersey 提供 Restful 服务、SpringCloud 替代,阿里巴巴恢复对 Dubbo 的支持,我们也计划将部分原来通过 DubboX 开发的服务迁移到目前的 Dubbo 版本。同时基于企业内部微服务体系的逐步庞大,服务的有效治理也成为了我们逐步关注的重点,通过对比和研究业界的成熟方案,以及结合我们自身的系统设计。我们最终选择了 Zookeeper 作为我们服务治理中心,即基于 Zookeeper 的 Dubbo RPC 服务与基于 Spring Cloud Zookeeper 的 http 服务管理并存的服务结构。

随着应用越来越多,系统之间的调用关系也越来越复杂,对服务的调用进行全链路跟踪和监控非常有必要。对此,我们通过 Java Agent、Byteman、OpenTracing 等技术构建了自动的日志监控埋点,基本不需要应用程序改动即可将日志埋点嵌入,从而形成完整的微服务调用链路,再通过日志搜索和图形化展示,可以实现对微服务的有效监控。

(2)消息中间件的选择。消费金融的特点是前端进件的业务量和并发量较大,但是大部分交易不需要强实时的响应。为了把大部分服务解耦,提升系统的吞吐率和性能,需要实用消息中间件技术。根据消费金融的特点及公司业务定位,要求消息队列必须是高可用,高性能且自主可控的,从社区的活跃度、消息堆积能力和性能来看,Kafka 更适合于我们的场景。另外,大数据处理和运维监控大部分消息队列也需要用到 Kafka,为了统一消息队列标准,便于维护,我们最终选择了 Kafka 作为消息中间件。

Kafka 在操作系统崩溃时可能会存在消息丢失的情况,当然在 Kafka1.0 版本以后,得到了比较大的优化。早期,为了保证消息的可靠投递,我们基于 Spring Kafka 幂等发送和支持事务等特性确保消息发送成功,自实现了消息多线程处理及 Offset 管理,引入 Redis 缓存 Offset,支持应用异常时从 Redis 恢复消息进行重新处理,实现 At-least-once 消费语义。

在 Springboot 2.0 发布后,消息消费通过 Spring Cloud Stream 支持 Partition 数据应用实例数及每个实例的并发数自动创建扩容,实现对每个 Partition 消息的单线程、幂等处理及整体上的多线程并发处理,Offset 通过 Spring Kafka 自动管理,实现 At-least-once 消费语义。另外很重要的一点,为了确保 At-least-once,消费端必须实现幂等性。通过优化和有效的异常处理机制,我们的系统没有出现消息丢失的情况,而且具备较高的吞吐率,达到了预期的效果。

(3)消息医院。使用 Kafka 消息中间件的服务必须要考虑消费端应用异常时如何进行处理,我们早期的做法是扩展 Spring Kafka,当消息消费出现异常时,将异常消息统一送进一个异常处理 topic,由各应用自己监听异常 topic 并进行相应的处理,例如重试、丢弃等。为了使消息的异常处理形成统一标准, 简化异常处理,减少重复开发,我们自研实现了一个消息医院(名称来源于 Sam Newman 的《微服务设计》,也称为死信队列),将所有异常消息都发送到消息医院中,通过一个管理端界面来查看异常消息列表,设计一定的异常处理策略(如定时自动触发一定次数的重试、手工重试或直接丢弃等),作为 at- least-once 消息投递保证的必要措施。

(4)分散式事务处理。分散式事务处理的常见解决办法是两阶段提交 2PC、补偿事务、TCC、基于消息的可靠事件机制。消费金融的大部分场景不需要保证强一致性,只需要保证最终一致性即可,TCC 模型过于复杂,而且可能会存在读脏数据或者中间事务状态不一致的问题,鉴于消费金融的事务大部分复杂度不高,并且可以通过场景化和多交互步骤的方式避免分散式事务,我们主要选择了可靠事件机制,通过消息的可靠投递实现最终一致性。

分散式事务处理是一项复杂的研究课题,目前没有非常完美的解决方案。分散式事务处理的关键,在于进行系统设计时,首先分析清楚强事务是否是真正的需求(例如转账),如果强事务不是真正需求,则应该通过场景化设计来尽量避免产生分散式事务。由于微服务实施后,无法通过场景化弱化事务的情况下(例如跨共享服务中心的多服务调用),应避免采用两阶段提交,尽量采用基于消息的可靠事件机制保证最终一致性。对于跨越内部系统和外部系统的分散式事务(如放款记账和银联代付),目前没有很好的解决方案,只能采取补偿事务、幂等重试的方式解决,在进行系统设计时,应遵循良好的设计原 则,确保补偿机制和重试机制足够合理和健壮。

(5)应用配置中心。在微服务架构中,服务之间有着错综复杂的依赖关系,每个服务都有自己的依赖配置,在运行期间很多配置会根据各种因素进行动态调整,传统的配置信息处理方式是将配置信息写入 xml、.properties 等配置文件中,和应用一起打包,每次修改配置信息,都需要重新进行打包,效率极低;同时在分散式应用场景下,配置的批量更新,灰度发布,集群管理、设置回滚、审计日志等开发与运维需求也对配置信息的管理提出了更高的要求。因此,我们开发了一个适用于各个应用系统、实现配置集中管理、支持信息实时更新等功能的配置应用中心。应用配置管理系统的使用,不仅使得配置信息能更统一、更有效的集中管理,同时也降低应用系统代码的耦合,使得开发、测试人员以一种更灵活的方式对环境、场景进行管理。

微服务集成及容器化演进

随着共享服务中心和微服务的不断扩充和完善,应用层与微服务之间、微服务之间的调用关系会面临变得越来越复杂的情况,如果不加以管控,会变成蜘蛛网式的调用,应用程序开发也会变得越来越复杂。为此,我们引入了微服务统一运营平台的概念,目的是将微服务在线化和可视化,对微服务进行集中管理,通过容器技术提供微服务快速组合和扩展的能力,达到业务流程的快速落地和调整,实现业务的高效拓展,另外,平台还可以对微服务组合出来的应用程序进行全面的监控和数据稽核。

首先是服务的在线化。将各共享服务中心提供的服务注册到统一运营平台的服务注册中心,注册中心提供一个可视化的界面,业务和技术人员可以方便地检索现有的共享服务,查看其用途、界面规范和目前正在使用该服务的应用。我们主要以 CDC 的模式(Consumer-Driven Contracts,消费方驱动的契约开发方式,是指从消费者业务实现的角度出发,驱动出契约,再基于契约,对提供者验证的一种测试开发方式)进行了服务界面的规范化约束,确保了开发流程的高效性和正确性。

其次是服务的集成。传统的服务组合和集成有两种方式:编排和协同,其中编排的方式一般是通过 ESB 或工作流引擎进行统一配置和管理,有明确的流程,由一个中心大脑控制;协同是事件驱动的方式,每个系统收到信号后启动处理,职责分明,细节独立,系统模块间的耦合度低。我们选择了基于事件驱动的协同方案,首先通过将现有的微服务以代理服务的方式注册到 SpringCloud DataFlow,并以可视化拖拽的方式对各种代理服务进行流程设计,通过服务间的组合串联来完成业务流程。串联的微服务之间的数据传递是通过事件驱动的模式进行,即通过 kafka 异步消息的模式,并通过消息医院和事后补偿机制进一步确保事务的最终一致性。

接下来是容器化。在系统应用微服务化的背景下,运用 Docker 技术栈将应用容器化成为了我们的目标。容器技术为实现更高效的资源利用,更快速的交付和部署,更轻松的迁移与扩展和更简单的更新管理提供了可能,同时也更适应快速变化的市场和业务需求。在应用容器化进程中,我们运用 Docker 技术对不同的微服务应用打包成相应的镜像,并将 Docker 镜像发布到私有镜像仓库统一管理。同时运用 Kubernetes 对容器和微服务进行编排和管理。

在服务集成运行环境方面,前面提到的服务在线化,向业务和技术人员展示的实际上就是集成 Docker 镜像仓库形成的微服务应用商店,通过可视化界面实现对微服务的参数动态展现和进行设计配置,Kubernetes 会根据设计过程生成的配置文件到 Docker 仓库获取相应镜像,部署到容器节点中,形成所需的服务,利用 Docker 和 Kubernetes 的特性,服务可以实现高可用、自动负载均衡、失效重建以及自动扩展。

最后,金融系统追求的是账务的准确性,需要对组合服务开发的应用进行业务稽核。业务稽核模块以业务为维度登记业务及其检验规则,实现统一应用系统的抽样数据收集,对抽样数据进行样本聚合,并根据设置的检验规则进行校对和检验,对校验异常的数据进行预警,并提供统一的监控界面。

本部分会以其中一个真实具体的业务模型为例介绍服务集成的实例,预览如下:

作者介绍

李远鑫,中邮消费金融有限公司IT 运营部 总经理助理 & 架构师。曾参与中国邮政储蓄银行全国中间业务平台、储蓄系统逻辑大集中等大型金融项目,曾任中邮消费金融公司软件研发高级总监,现任 IT 运营部总经理助理、架构师,负责中邮消费金融公司等 IT 系统规划和架构设计,并带领团队完成从基于集中式商业中间件的金融交易系统向灵活、可靠、高性能、分散式的微服务消费金融交易系统的演进,在 2017 年支付宝 66 信用日活动中支撑日均 10 万的交易量和 30 万 PV 峰值。

欢迎大家来 12 月 7 日北京 ArchSummit 会议上听我的分享,希望和大家有更多的交流探讨。扫码查看会议的其他演讲内容,本周是 8 折最后一周,购票可以联系灰灰姑娘 17326843116





2018-10-24 11:34:00

相关文章