本文整理自中国人寿保险 (海外) 股份有限公司深圳中心技术总监家黄晓彬在 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 都可以正常执行; 第二步抽查关键算法或接口, 批量数据两边数据库执行对比结果.
来源: http://www.jianshu.com/p/45dc363f6ffd