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

程序那点儿事 2019-08-08 17:01:10 ⋅ 536 阅读

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

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

遇见Dubbo


2013年，我们在做整个数据库转换的时候，需要找一款RPC的框架。 当时市场上成熟的产品很少，不像今天百花齐放，比如今天有 Spring Cloud 和 Dubbo，但我们更倾向于有实际生产经验的框架，Dubbo在淘宝有比较丰富的实施经验，再加上阿里的业务形态和我们的业务模型契合度很高，例如需要支持海外不同地区的请求，不同地区也都有一些自己的定制化业务需求。
从2013年到今年，我们已经使用 Dubbo 6年了。 2016年，业务系统上线港澳地区， 2019年5月份，在印尼上线，未来还会在新加坡以及整个东南亚，快速部署我们的业务系统。
在部署效率和低成本方面，Dubbo 给予了我们很大的帮助，这里我先分享下在使用Dubbo 之前，传统保险公司的架构。

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


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


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



核心业务系统的改造过程



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

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

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



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

OneLife分布式体系的形成



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

Dubbo在港澳地区的分布




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

Dubbo在中国人寿海外的实践




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

Dubbo的配置结构




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

Dubbo微服务的应用场景




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

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

建议



第一，加强可视化管理；

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

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

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

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

解疑时间


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

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

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



注意：本文归作者所有，未经作者允许，不得转载

#dubbo
阅读全部

全部评论: 0 条

    我有话说:

    「轻阅读」Dubbo 如何成为连接异构微服务体系的最佳服务开发框架

    要实现异构微服务体系间的共存或迁移，关键点在打通异构体系间的协议与服务发现，得益于 Dubbo 自身对多协议、多注册模型的支持

    【开源资讯】JWCloud 专业版 v1.0.0 发布，基于 SpringCloud 研发的微服务框架

    简介 JavaWeb_Cloud 微服务平台是一款基于 SpringCloud 框架研发的分布式微服务框架，主要使用技术栈包括： SpringCloud、Vue、ElementUI

    服务化改造实践 | 如何在 Dubbo 中支持 REST

    随着微服务的流行以及多语言互操作诉求的日益增多，在 Dubbo 中暴露 REST 服务变成了一个不容忽视的诉求。

    SpringBoot+zk+dubbo架构实践（一）：本地部署zookeeper

    SpringBoot+zk+dubbo架构实践系列实现目标：自己动手搭建微服务架构

    你的老板逼你上微服务了吗？

    “ 这些年软件的设计规模越来越庞大，业务需求也越来越复杂，针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。   图片来自 Pexels可以说业务需求是软件架构能力的

    「转载」微服务分布式架构中，如何实现日志链路跟踪？

    背景 开发排查系统问题用得最多的手段就是查看系统日志，在分布式环境中一般使用ELK来统一收集日志，但是在并发大时使用日志定位问题还是比较麻烦，我们来看下面的图     上图

    SpringBoot+zk+dubbo架构实践（五）：搭建微服务电商架构（内附GitHub地址）

    集成了mybatis和swagger让接口可视化并完成了一些增删改查的基础业务，对了还有个分页查询！

    MateCloud 3.2.8 版本发布，基于 Spring Cloud Alibaba 的微服务平台

    软件简介 MateCloud 是一款基于Spring Cloud Alibaba的微服务架构。目前已经整合 Spring Cloud Gateway、Spring Security

    SpringBoot+zk+dubbo架构实践（三）：部署Dubbo-admin管理平台

    本系列架构实践不做深入探讨，主旨是带领大家能够快速踏入微服务架构门槛，能够轻松的搭建一套属于自己的微服务架构。——写代码我们是认真滴！

    精品推荐：Nacos 发布 v0.6.0 版本，支持 Dubbo 和 Docker 部署

    阿里巴巴微服务开源项目Nacos发布 v0.6.0 版本，该版本开始支持 Dubbo的服务发现和配置管理，并针对 Docker 部署提供了官方的 Docker 镜像，以及优化了Nacos 控制台的

    架构实战篇（十）：Spring Boot 集成 Dubbo

    Dubbo是阿里巴巴SOA服务化治理方案的核心框架，一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案。

    微服务架构学习笔记（一）：重新认识微服务

    微服务（Microservice）是服务化思路的一种最佳实践方向，遵循SOA的思路，各个企业在服务化治理的道路上走的时间长了，踩的坑多了，整个软件交付链路上各个环节的基础设施逐渐成熟了，微服务

    Dubbo Admin重构版-v0.1发布

    为了提升 Dubbo 里程碑版本2.7.0的使用体验，去年年中启动了 Dubbo Admin 的重构计划

    Fizz Gateway 1.1.1 发布，基于 Java异步框架WebFlux开发的微服务网关

    Fizz Gateway 是一个基于 Java异步框架WebFlux开发的微服务网关，能够实现热服务编排、自动授权选择、线上服务脚本编码、在线测试、高性能路由、API审核管理等目的，拥有强大的自定义

    Micronaut 2.2.3 发布，基于 JVM 的微服务应用框架

    Micronaut 2.2.3 发布了，本次更新内容主要为项目组件升级。 Micronaut 是 Grails 框架作者打造的开源项目，也是新一代基于 JVM 的全栈微服务框架，用于构建模块化的

    Micronaut 2.3.3，基于 JVM 的微服务应用框架

    Micronaut 是 Grails 框架作者打造的开源项目，也是新一代基于 JVM 的全栈微服务框架，用于构建模块化的、易于测试的微服务应用。有关 Micronaut 的特性介绍点此查看。 近日

    Micronaut 2.4.0 发布，基于 JVM 的微服务应用框架

    Micronaut 是 Grails 框架作者打造的开源项目，也是新一代基于 JVM 的全栈微服务框架，用于构建模块化的、易于测试的微服务应用。有关 Micronaut 的特性介绍点此查看。 近日

    Micronaut 2.4.2 发布，基于 JVM 的微服务应用框架

    Micronaut 是 Grails 框架作者打造的开源项目，也是新一代基于 JVM 的全栈微服务框架，用于构建模块化的、易于测试的微服务应用。有关 Micronaut 的特性介绍点此查看。 近日

    Martian-cloud 4.0，跟注册中心拜拜了，基于传染机制的分布式组件诞生

    这次真的要跟注册中心讲拜拜了，微服务不再需要占用一套注册中心集群了，大大节约了运维成本 更新点如下 丢弃了一开始的【生产者->注册中心->消费者】模型 采用传染机制，实现服务的发现与