传统保险企业基于 Dubbo 的微服务实践

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文整理自中国人寿保险(海外)股份有限公司深圳中心技术总监家黄晓彬在 Dubbo 社区开发者日深圳站的现场分享。中国人寿保险(海外)股份有限公司负责香港、澳门、新加坡和印尼的业务开发,和国内业务不同的是,海外业务面临不同的法规、语言、币种等难题,技术上对业务的支持会存在一些挑战。

lADPDgQ9q5HXxf_NA1XNBQA_1280_853_jpg_620x10000q90g
本文整理自中国人寿保险(海外)股份有限公司深圳中心技术总监家黄晓彬在 Dubbo 社区开发者日深圳站的现场分享。

中国人寿保险(海外)股份有限公司负责香港、澳门、新加坡和印尼的业务开发,和国内业务不同的是,海外业务面临不同的法规、语言、币种等难题,技术上对业务的支持会存在一些挑战。通过本文,您将了解中国人寿保险在这方面的处理经验。

遇见Dubbo

2013年,我们在做整个数据库转换的时候,需要找一款RPC的框架。当时市场上成熟的产品很少,不像今天百花齐放,比如今天有 Spring Cloud 和 Dubbo,但我们更倾向于有实际生产经验的框架,Dubbo在淘宝有比较丰富的实施经验,再加上阿里的业务形态和我们的业务模型契合度很高,例如需要支持海外不同地区的请求,不同地区也都有一些自己的定制化业务需求。

从2013年到今年,我们已经使用 Dubbo 6年了。2016年,业务系统上线港澳地区, 2019年5月份,在印尼上线,未来还会在新加坡以及整个东南亚,快速部署我们的业务系统。

在部署效率和低成本方面,Dubbo 给予了我们很大的帮助,这里我先分享下在使用Dubbo 之前,传统保险公司的架构。

使用Dubbo 前,传统保险公司的架构

从服务器硬件层面去看,传统保险的业务系统用的是小型机,例如 IBM、惠普,只有这两个可以选择,他们都是基于 Unix 的操作系统。

lALPDgQ9q5HZX9zNAn7NBL0_1213_638_png_620x10000q90g

从业务架构的层面去看,以前的软件开发用的是 C/S 架构,在 C/S 架构下有一个很好用的中间件叫 Tuxedo,用于处理分布式事务管理,一致性和高并发性能都非常好,但是为什么要把它替换掉它?一是因为价格太高,二是因为相关的运维人员很难找到。三是因为业务高度集成,在分布式和跨平台的场景下性能和调度很差。四是因为他的设计是针对单体的,导致我们拆不开,也不敢动。

核心业务系统的改造过程

lADPDgQ9q5HW0ObNAe3NBNY_1238_493_jpg_620x10000q90g

这张图很形象的说明了微服务相比单体的优势,Dubbo 在里面的作用相当于在各个组建之间做一个卡口的交互,类似于乐高的凸点、凹点之间,提供通讯的管理和服务的治理。我们就是通过这个设计思路,将一个庞大的传统核心架构进行拆解的。

OneLife 是我们的业务支撑平台,意思是指,一个平台能够解决所有保险业务的处理,形成内部的生态圈,提供对影像、新的业务、保全和理赔业务的支持,还有自建的一些引擎,比如工作流、产品引擎、核保引擎、消息引擎等。以上就是一家保险公司大概要具备的业务能力。

借助Dubbo,自主研发保险业务处理平台

lALPDgQ9q5HW0OrNAo_NBAM_1027_655_png_620x10000q90g

我们借助 Dubbo 搭建了新的保险业务处理平台,实现了“六多”的保险业务处理。六多是指,多业务、多产品、多监管、多引擎、多币种和多语言。例如一个保单生成的过程中,要考虑是生成英文还是中文或者印尼文?这需要与业务进行配合,然后设计、开发适合自己的处理平台。

OneLife分布式体系的形成

lALPDgQ9q5HW0O7NAnfNBDU_1077_631_png_620x10000q90g

由上图可知,由基于Dubbo的微服务调用、基于 Jenkins 的持续集成、基于Rancher 的云部署应用和基于 Pinpoint 的链式监控这四块内容形成一个闭环。云部署方面,印尼版本正在与阿里云的团队洽谈中,未来的印尼地区可能会率先切换成阿里云服务的版本。关于 Pinpoint 链式监控,它所显示的拓普图非常清晰,可以很清晰的看到组建中断或者调用不通等问题,今年我们通过 Pinpoint 链式监控,在系统内找到100+ Bug,所以我认为 Pinpoint 链式监控与 Dubbo 的搭配是个绝妙的组合。

Dubbo在港澳地区的分布

lALPDgQ9q5HW0O3NAnrNBJc_1175_634_png_620x10000q90g

Dubbo 在港澳地区拥有150+台服务器,210+个应用,2100+个消费者,1300+个提供者。对于保险公司来说,不存在太多的高频交易,特别是业务系统,更多的高频交易是在前端。虽然业务系统不是一直处于高频状态,但是也必须保证其稳定性,确保每一条业务都能够非常准确的输出。这也是我们选择 Dubbo 的原因之一。

Dubbo在中国人寿海外的实践

lALPDgQ9q5HW0PDNAjzNA48_911_572_png_620x10000q90g

我们70%的业务使用的是低版本的 Dubbo-2.4.9 版本,之前在 Dubbo 的基础上做过一些代码的修改,例如对分布式事务的补偿,后来发现会由于改动太大,造成以后不能升级版本。剩余的30%是用什么呢?我们会尝试最新的版本,但都只是在外围,只有经过实践证明新版本是可行的,才会把它运用到核心业务架构中。目前,中国人寿海外的 Dubbo 每天调用次数超过2100万次,从上线到现在,还没有出现过宕机的情况。

Dubbo的配置结构

lALPDgQ9q5HW0PLNAkjNBKs_1195_584_png_620x10000q90g

这里再分享一下我们所用的配置,需要强调的两点是,一是重试的机制,即服务中断的时候利用控制平台进行人工干预,或者特别关键的服务,通过反复交易的方式进行补偿。二是使用 Zookeeper 注册中心,它是有弊端的,高峰期时期,网络的消耗太大。Dubbo2.7 版本里面元数据的概念非常好,未来我们也会去尝试,看看能不能通过新版本的Dubbo去解决 Zookeeper 的弊端问题,或者优化Zookeeper。

Dubbo微服务的应用场景

lALPDgQ9q5HW0PTNAijNAxE_785_552_png_620x10000q90g

Dubbo 微服务的应用如同上图中所描述的,从线上服务页面到新业务组件,然后触发工作流,查询核保的结果,结果会自动查询保费的计算,再返回到前端。在印尼的国际化方面,低成本是必须的,另外需要做到业务的分离,这个就涉及到 Base 的开发模式,什么叫 Base 开发模式?

当业务遍布多地区时,各个地区必定有自己特定的版本。但是只要保证公共的基础版本相同,就可以在以后的工作中提高效率。例如 :公司总部有一些基础性的服务,但是印尼有自己的法规需求,如果后期香港也有这个需求,可以在基础版本达到某个级别审核之后,把基础版本打回到 Base 版本里,Base 版本再把它发布到对应的不同地区的版本,就是说,在比较复杂的情况下,它具有不同业务逻辑分离的层次,也具有代码管理的层次,又有服务治理之间不同地区的管理层次。

建议

lADPDgQ9q5HW0L3NAlbNAwQ_772_598_jpg_620x10000q90g

第一,加强可视化管理;

第二,引入服务网格,打包成一个全家桶,提供微服务体系内更丰富的功能,包括服务之间的网络调用、限流、熔断和监控。

第三,支持多语言,Dubbo 目前已经提供 PHP/Node.js/Python/Go 的客户端,希望可以支持更多的客户端。

第四,不建议 Dubbo 支持分布式事务管理。以前我们刚开始使用Dubbo的时候,认为有必要支持分布式事务,所以在 Dubbo 基础上改写了代码,使用过程很流畅,也能够保证我们事物的一致性,而且跨平台也可以做到,但是当某个服务挂掉的时候,所有等待提交的事务会全部崩掉,会给数据库造成致命的风险。

所以我们更倾向的是让 Dubbo 提供更多消息机制的支持,能够在做业务开发的同时对分布式事务进行补偿,以上就是我们实践中的一点思考和建议。

解疑时间

Q1:微服务组件替换单体的过程中是一步步替代老系统,还是直接整体替换?替换过程中,需要用到多少人力、物力?
A1:首先将现有结构模块化,模块间相对独立,最重要的数据结构要先分离业务逻辑,其次,再分库或者设置权限,然后进行模块化的一步步替换,在开发前需要计划好整个替换过程。我们第一个模块启动时,只有五个人,但要求每个人技术要强、业务要精通,最重要的是得到管理层的支持。

Q2:如果系统中没有分布式事务控制,数据不一致性如何发现?怎么解决?
A2:基于Pinpoint的链式监控,运维人员可以快速发现问题,继而排除网络问题之后进行人工干预,我们在关键业务上使用MQ机制,但是其存在耗时、耗力、耗人的问题,不建议大规模使用分布式事务控制。

Q3:公司内部数据量大的条件下,把旧系统迁移到新系统的过程中如何去O?
可以文回答下这个问题么?
A3:首先在数据库层面要保证Oracle数据库到其他数据库的表结构及数据一致,可以利用ETL等数据工具进行对比。其次,在应用层面可以分两步走,第一步自动化处理,通过自写工具将应用的SQL在两边数据库执行,发现错误的及时修正,当进行到第三轮的时候就差不多所有SQL都可以正常执行;第二步抽查关键算法或接口,批量数据两边数据库执行对比结果。

相关文章
|
4天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。
|
8天前
|
设计模式 API 数据库
构建高效微服务架构:从理论到实践
【2月更文挑战第29天】 在现代软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分成一系列小型、独立的服务来提高系统的可维护性、扩展性和敏捷性。本文将深入探讨微服务的核心概念、设计原则以及如何在实际项目中实现和优化微服务架构。我们将从微服务的定义出发,讨论其与传统单体架构的区别,并分析微服务的优势与挑战。接着,文章将提供一套实践指南,包括服务划分、通信机制、数据一致性问题以及安全性考虑等方面,以指导开发者构建和维护一个高效的微服务系统。
|
14天前
|
消息中间件 Kubernetes Java
构建高性能微服务架构:从理论到实践
【2月更文挑战第24天】 在当今快速发展的数字化时代,微服务架构已成为软件开发领域的关键趋势。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、技术选型和性能优化策略。我们将通过实际案例分析,揭示微服务架构在提高可伸缩性、容错性和维护性方面的优势,并讨论在实施过程中可能遇到的挑战及其解决方案。
|
15天前
|
消息中间件 缓存 持续交付
构建高效微服务架构:从理论到实践
【2月更文挑战第23天】 随着现代软件系统向着复杂且动态的环境演进,传统的单体应用架构已不足以应对快速变化的市场需求。微服务架构作为一种新兴的架构模式,以其灵活性、可扩展性和技术多样性受到广泛关注。本文将深入探讨微服务架构的设计原则和实施策略,通过具体案例分析如何构建一个既满足业务需求又保证系统稳定性的微服务系统。我们将讨论微服务拆分的策略、服务间通信的最佳实践、数据一致性的挑战以及持续集成与部署的重要性。文章的目的是为开发者、架构师和技术决策者提供一份实操指南,帮助他们在构建和维护微服务系统时做出明智的选择。
|
4天前
|
消息中间件 敏捷开发 运维
构建高效可靠的微服务架构:策略与实践
随着现代软件开发的复杂性增加,微服务架构逐渐成为企业解决大型应用系统分解、敏捷开发和持续部署问题的有效手段。本文深入探讨了构建一个高效且可靠的微服务架构的关键策略,包括服务的合理划分、通信机制的选择、数据一致性保障以及容错处理。通过分析这些策略在具体案例中的应用,我们旨在为开发者提供一套可行的微服务设计及实施指南。
115 6
|
11天前
|
安全 数据管理 API
构建高效微服务架构:从理论到实践
【2月更文挑战第27天】 在数字化转型的浪潮中,微服务架构已成为企业追求敏捷、灵活与可扩展性的关键解决方案。本文将深入探讨微服务的设计原则、开发流程以及如何在实际项目中实现一个高性能的微服务系统。我们将通过分析微服务的核心优势,揭示其背后的技术挑战,并提供一系列切实可行的策略来优化微服务的性能和稳定性。文中不仅包含了丰富的理论依据,还结合了实际案例分析,为开发者和企业决策者提供了一套全面的微服务实施指南。
|
13天前
|
监控 持续交付 开发者
构建高效微服务架构:从理论到实践
【2月更文挑战第25天】本文旨在深入剖析微服务架构的核心概念、设计原则以及实践中的关键技术挑战。通过探讨微服务的独立性、分布式特性和弹性机制,文章为读者提供了一套系统化的方法论,以指导如何构建和维护一个高效、可扩展且容错性强的微服务系统。文中将结合案例分析,展示微服务架构在真实业务场景中的应用,并提供性能优化和故障恢复的策略建议。
59 3
|
17天前
|
监控 Kubernetes 持续交付
构建高效微服务架构:策略与实践
【2月更文挑战第20天】 在现代软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为一组小型、独立的服务来提高可维护性和扩展性。本文旨在探讨构建高效微服务架构的关键策略和实践方法。我们将分析微服务设计原则、服务划分的最佳实践、容器化技术的应用,以及如何通过持续集成和持续部署(CI/CD)流程确保微服务的快速迭代和稳定性。此外,文章还将讨论监控和日志管理在微服务环境中的重要性,并提出一些处理分布式系统常见问题的策略。
|
4天前
|
消息中间件 缓存 API
微服务架构下的API网关性能优化实践
在现代的软件开发中,微服务架构因其灵活性和可扩展性被广泛采用。随着服务的细分与增多,API网关作为微服务架构中的关键组件,承担着请求路由、负载均衡、权限校验等重要职责。然而,随着流量的增长和业务复杂度的提升,API网关很容易成为性能瓶颈。本文将深入探讨API网关在微服务环境中的性能优化策略,包括缓存机制、连接池管理、异步处理等方面的具体实现,旨在为开发者提供实用的性能提升指导。
|
6天前
|
缓存 负载均衡 监控
构建高效微服务架构:API网关的作用与实践
【2月更文挑战第31天】 在当今的软件开发领域,微服务架构已成为实现系统高度模块化和易于扩展的首选方法。然而,随着微服务数量的增加,确保通信效率和管理一致性变得尤为重要。本文将探讨API网关在微服务架构中的核心角色,包括其在请求路由、安全性、负载均衡以及聚合功能方面的重要性。我们将通过具体案例分析,展示如何利用API网关优化后端服务,并讨论实施过程中的最佳实践和常见挑战。

相关产品

  • 微服务引擎
  • 服务网格