作为中国最大的寿险公司之一，中国人寿保险（Ping An Life Insurance）的 Java 开发系统承载着极其复杂、高并发、强合规、多渠道的业务流程。以下是一份详尽的 Java 开发视角下的人寿保险系统业务流程与核心概念文档，涵盖业务模型、系统架构、核心概念定义、流程图解、技术实现要点与行业最佳实践，适用于你即将参与的开发与维护工作。
📄 寿险 Java 系统业务流程与核心概念完整文档
适用对象：Java 开发工程师、系统架构师、测试工程师、运维人员
版本：v2.0（适用于平安寿险 2024 年核心系统架构）
更新时间：2025年4月
一、引言：寿险系统在金融科技中的地位
人寿保险是长期性、金融性、精算性、合规性极强的金融产品。与财险不同，寿险涉及：
- 长达数十年的保单生命周期（缴费、保全、理赔、退保）
- 精算模型驱动的保费计算
- 多渠道销售（代理人、电销、互联网、银行代理）
- 复杂的监管要求（银保监会、偿二代、IFRS17）
- 高并发交易（如双11、开门红期间百万级保单涌入）
寿险系统基于分布式微服务架构，采用 Java 技术栈（Spring Boot / Spring Cloud / MyBatis / Kafka / Redis / Oracle / 分库分表），支撑日均百万级保单处理。
二、核心业务流程全景图（Lifecycle）
寿险业务生命周期 = 销售 → 承保 → 缴费 → 保全 → 理赔 → 续期 → 退保/满期
三、核心业务概念详解（Java 开发视角）
1. 保单（Policy）
定义：保险公司与投保人签订的法律合同，载明保险责任、保费、期限、受益人等核心条款。
| 属性 | 说明 | Java 实体示例 |
|---|---|---|
| policyNo | 保单号（唯一，如P202404050001） | String |
| insuredId | 被保险人ID | Long |
| applicantId | 投保人ID | Long |
| beneficiaryList | 受益人列表 | List<Beneficiary> |
| policyStatus | 状态：待核保/已生效/失效/退保/满期 | enum PolicyStatus { PENDING, ACTIVE, LAPSED, TERMINATED, MATURED } |
| premiumAmount | 总保费 | BigDecimal |
| sumAssured | 保额 | BigDecimal |
| policyTerm | 保障期限（年） | Integer |
| paymentTerm | 缴费年限 | Integer |
| issueDate | 签发日期 | LocalDateTime |
| effectiveDate | 生效日期 | LocalDateTime |
技术要点：
- 保单是核心聚合根（DDD领域驱动设计）
- 使用 分库分表（按 policyNo 哈希分片）
- 每次变更需记录历史快照（AuditLog 表）
@Entity
@Table(name = "policy")
public class Policy {
@Id
private String policyNo;
private PolicyStatus status;
private BigDecimal sumAssured;
private BigDecimal premiumAmount;
private LocalDateTime issueDate;
private LocalDateTime effectiveDate;
@OneToMany(mappedBy = "policy", cascade = CascadeType.ALL)
private List<PolicyPremium> premiums; // 缴费计划
@OneToMany(mappedBy = "policy", cascade = CascadeType.ALL)
private List<PolicyChange> changes; // 保全变更历史
}
2. 投保单（Application）
定义：客户提交的投保申请，尚未生成保单，处于核保流程中。
- 一个投保单 → 可能生成 1 个保单（成功）或 0 个（拒保）
- 包含健康告知、职业信息、财务信息等
关键字段：
applicationNo：申请编号healthDeclaration：健康告知（JSON结构）underwritingResult：核保结果（标准体/加费/延期/拒保）sourceChannel：渠道（代理人/官网/微信）
Java 实现：
- 使用 状态机（Spring State Machine）管理：
DRAFT → SUBMITTED → UNDERWRITING → APPROVED / REJECTED - 健康告知使用 规则引擎（Drools / EasyRule）自动判断风险等级
3. 核保（Underwriting）
定义：保险公司评估投保人风险，决定是否承保及条件。
核保流程：
- 自动核保（规则引擎）→ 健康问卷、年龄、职业、既往病史
- 人工核保（高风险客户）→ 核保员介入
- 输出：核保结论 + 附加条件（如加费10%、除外责任）
技术实现：
- 规则引擎：Drools 规则库（.drl 文件）
- 示例规则：
rule "HighRiskOccupation"
when
$app : Application( occupationCode in ("1001", "1002"), age > 50 )
then
modify($app) { setUnderwritingResult("ADDITIONAL_PREMIUM"); }
end
- 集成外部数据：医保数据库、征信系统、第三方健康平台（如平安好医生）
4. 保费（Premium）与缴费计划（Premium Schedule）
定义：客户需定期缴纳的费用，按年/月/季缴纳。
核心概念：
- 期缴：每年交一次（如终身寿险）
- 趸缴：一次性交清（如高端养老险）
- 宽限期：逾期30~60天内仍有效
- 犹豫期：签收后15天内可无条件退保
Java 模型：
@Entity
public class PremiumSchedule {
private String policyNo;
private Integer installmentNo; // 第几期
private LocalDate dueDate;
private BigDecimal amount;
private PremiumStatus status; // DUE, PAID, OVERDUE, WAIVED
private LocalDateTime paymentTime;
private String paymentChannel; // 支付宝/微信/银行代扣
}
技术要点：
- 定时任务：Quartz / XXL-JOB 每日扫描待缴清单
- 支付对账：对接平安支付平台，使用 消息队列（Kafka） 异步处理支付结果
- 逾期处理：触发短信/电话提醒 → 保单失效 → 复效申请
5. 保全（Policy Service / Policy Change）
定义：保单生效后，客户申请的非理赔类变更。
常见保全项目：
| 类型 | 说明 |
|---|---|
| 受益人变更 | 更换受益人 |
| 通讯地址变更 | 更新联系信息 |
| 缴费方式变更 | 银行卡更换 |
| 保额增加/减少 | 需重新核保 |
| 附加险增减 | 如增加重疾险 |
| 复效 | 保单失效后恢复（需补缴+健康告知） |
| 减额交清 | 停止缴费，保额降低 |
技术实现：
- 事务一致性：使用 Saga 模式 或 TCC（Try-Confirm-Cancel）
- 每次变更生成 保全记录（PolicyChange），记录操作人、时间、旧值、新值
- 涉及精算重算的变更（如加保额）必须调用 精算引擎
@Entity
public class PolicyChange {
private String changeId;
private String policyNo;
private ChangeType type; // ENUM: BENEFICIARY, ADDRESS, SUM_ASSURED
private String oldValue;
private String newValue;
private String operator;
private LocalDateTime changeTime;
private ChangeStatus status; // PENDING, APPROVED, REJECTED
}
6. 理赔（Claim）
定义：被保险人发生保险事故后，向保险公司申请赔付。
理赔流程：
- 客户提交理赔申请（APP/微信/电话）
- 理赔受理 → 资料审核（病历、死亡证明、发票等）
- 理赔审核（自动/人工）
- 理算（计算赔付金额）
- 支付 → 通知客户
核心概念：
- 理赔类型：身故、重疾、医疗、伤残、满期
- 免赔额：不赔的金额（如医疗险100元）
- 赔付比例：如80%报销
- 等待期：投保后180天内不赔重疾
Java 架构：
- 理赔引擎：基于规则 + AI 图像识别（OCR识别病历）
- 文件管理：集成 MinIO / 阿里云OSS 存储电子材料
- 审批流：Activiti / Flowable 工作流引擎
- 赔付计算：调用 理赔精算模型（Java + Python 混合部署）
@Service
public class ClaimCalculator {
public BigDecimal calculatePayout(Claim claim) {
if (claim.getClaimType() == ClaimType.CANCER) {
return claim.getSumAssured().multiply(BigDecimal.valueOf(1.0)); // 100%赔付
} else if (claim.getClaimType() == ClaimType.MEDICAL) {
return claim.getExpense().subtract(claim.getDeductible()).multiply(claim.getPayoutRatio());
}
return BigDecimal.ZERO;
}
}
7. 现金价值（Cash Value）
定义：长期寿险（如分红险、万能险）的储蓄部分，退保时可返还的金额。
重要性：
- 客户退保时的核心计算依据
- 与精算假设（死亡率、利率、费用率）强相关
- 受 IFRS17 准则影响，需按“履约现金流”模型计算
Java 实现：
- 精算引擎（通常为 C++/Python 部署，Java 通过 RPC 调用）
- 使用 缓存（Redis）存储常见保单的现金价值（每日凌晨更新）
- 计算公式复杂，涉及：
CV = 保费累积 - 死亡成本 - 管理费用 - 利息调整
⚠️ 注意：现金价值计算是监管合规红线，任何偏差都可能导致审计失败！
8. 精算模型（Actuarial Model）
定义：基于统计学、概率论、金融数学，计算保费、准备金、现金价值的数学模型。
平安使用模型：
- 死亡率表：中国寿险业经验生命表（2020）
- 利率假设：3.5%~4.0%（受银保监会指导）
- 费用率：首年60%，续年10%
技术实现：
- 模型用 Python（NumPy/Pandas）开发，通过 gRPC 或 REST API 供 Java 服务调用
- 模型参数通过 配置中心（Nacos）动态加载
- 每年更新模型 → 触发 全量保单重算（批处理任务）
@Service
public class ActuarialClient {
@Autowired
private RestTemplate actuarialEngine;
public CashValueResponse calculateCashValue(String policyNo) {
return actuarialEngine.postForObject(
"http://actuarial-engine:8080/calculate",
new CalcRequest(policyNo),
CashValueResponse.class
);
}
}
9. 准备金（Reserve）
定义：保险公司为履行未来赔付责任而计提的负债，是财务报表核心。
监管要求：
- 中国偿二代（C-ROSS）要求：准备金 = 未来赔付现金流的现值
- 必须每日计算，由 精算系统 生成 → 导入 财务系统
Java 系统角色：
- 保单系统提供每日生效/退保/理赔数据
- 财务系统通过 定时任务（凌晨2点）调用精算引擎
- 数据写入 Oracle 数据仓库，供审计使用
10. 渠道与客户管理（Channel & Customer）
| 概念 | 说明 |
|---|---|
| 客户（Customer） | 一人一户，唯一ID，整合投保人/被保人/受益人 |
| 渠道（Channel） | 代理人、电销、官网、银行、APP、微信小程序 |
| 客户画像 | 标签：年龄、收入、健康、购买历史、活跃度 |
技术实现：
- 客户中心（Customer Master）：独立微服务，统一客户ID
- 使用 身份证号 作为主键（需脱敏）
- 与 CRM 系统（Salesforce / 自研）集成
- 客户标签系统：基于 Flink 实时计算用户行为
四、系统架构分层（Java 微服务架构）
✅ 关键技术栈：
- 框架：Spring Boot 3.x + Spring Cloud Alibaba
- 数据库：Oracle 19c（核心）、MySQL（日志）、Redis（缓存）、Elasticsearch（理赔文档检索）
- 消息队列：Kafka（高吞吐）、RabbitMQ（低延迟）
- 分布式事务：Seata（TCC模式）
- 监控：Prometheus + Grafana + SkyWalking
- 部署：Kubernetes + Docker
- 安全：国密SM4加密、数字证书、等保三级
五、关键业务规则与合规要求（Java 开发必须遵守）
| 类别 | 规则 | 技术实现建议 |
|---|---|---|
| 监管合规 | 保单回访必须在15日内完成 | 定时任务 + 短信/语音自动回访 |
| 数据安全 | 身份证、银行卡号必须脱敏 | 使用 @Encrypt 注解 + AES加密存储 |
| 审计追踪 | 所有变更必须留痕 | 每个实体继承 AuditEntity（创建人、时间、IP） |
| 数据一致性 | 缴费成功必须更新保单状态 | 使用 Saga 或 TCC 保证跨服务一致性 |
| 容灾要求 | 核心系统 RTO < 30分钟 | 双活数据中心 + 读写分离 + 熔断降级 |
| IFRS17 | 保费收入需按“预期利润法”确认 | 精算引擎输出收入确认表，财务系统按月导入 |
六、典型开发场景示例
场景1：客户通过APP投保重疾险
- 客户填写信息 → 前端校验 → 调用 投保服务
- 投保服务 → 调用 客户中心 验证身份
- 投保服务 → 调用 核保引擎（Drools） → 返回“标准体”
- 生成保单 → 保存到 保单库（分库分表）
- 生成缴费计划 → 写入 缴费服务
- 发送短信通知 → Kafka → 短信服务
- 同步数据至 财务系统、监管报送系统
场景2：客户申请退保
- 客户提交退保申请 → 保全服务
- 系统校验：是否在犹豫期？是否欠费？
- 调用 精算服务 计算现金价值
- 生成退保金 → 调用 支付服务
- 更新保单状态为“退保”
- 记录退保日志 → 同步至财务系统
- 触发 客户流失分析（数据中台）
七、Java 开发最佳实践（平安内部规范）
| 类别 | 建议 |
|---|---|
| 命名规范 | PolicyService, ClaimProcessor, PremiumScheduler |
| 事务管理 | 所有保单变更必须加 @Transactional(isolation = REPEATABLE_READ) |
| 幂等设计 | 所有支付、退保、保全接口必须支持幂等（使用 requestId） |
| 日志规范 | 所有关键操作记录 TRACE_ID + 业务流水号 |
| 缓存策略 | 现金价值、条款信息缓存1小时，使用 @Cacheable |
| 异常处理 | 业务异常统一抛 InsuranceBusinessException，不直接抛 RuntimeException |
| 测试覆盖 | 核心流程单元测试 ≥ 90%，使用 TestContainers 模拟 Oracle |
| 性能要求 | 投保接口响应 ≤ 800ms，缴费 ≤ 500ms |
八、总结：Java 开发者在寿险系统中的角色定位
| 角色 | 关键职责 |
|---|---|
| 业务开发 | 实现投保、保全、理赔等核心流程，理解业务规则 |
| 系统架构 | 设计高可用、可扩展的微服务，保障数据一致性 |
| 数据工程师 | 处理保单数据清洗、ETL、监管报送 |
| 测试工程师 | 设计保单生命周期测试用例（如“缴费逾期30天后自动失效”） |
| 运维工程师 | 监控保单生成峰值、支付成功率、精算引擎健康度 |
💡 金句：
“在寿险系统中，你写的每一行代码，都可能影响一个人未来十年的保障。”
九、推荐阅读与学习资源
| 类型 | 名称 | 说明 |
|---|---|---|
| 书籍 | 《保险精算原理》（中国精算师协会） | 必读 |
| 标准 | IFRS 17 保险合同准则 | 理解财务计量 |
| 技术 | Spring Boot 实战（王松） | 平安内部培训教材 |
| 工具 | Drools 官方文档 | 规则引擎开发 |
| 案例 | 寿险开放平台API文档 | 内部系统访问 |
| 规范 | 《人身保险业务基本服务规定》（银保监会2022） | 法律依据 |
十、附录：术语缩写表
| 缩写 | 全称 | 中文 |
|---|---|---|
| UI | User Interface | 用户界面 |
| API | Application Programming Interface | 应用程序接口 |
| DDD | Domain-Driven Design | 领域驱动设计 |
| TCC | Try-Confirm-Cancel | 两阶段提交补偿事务 |
| IFRS17 | International Financial Reporting Standard 17 | 国际财务报告准则第17号 |
| CRM | Customer Relationship Management | 客户关系管理 |
| OCR | Optical Character Recognition | 光学字符识别 |
| KYC | Know Your Customer | 了解你的客户 |
| RTO | Recovery Time Objective | 恢复时间目标 |
| SLA | Service Level Agreement | 服务等级协议 |
✅ 结语：你不是在写代码，你在守护承诺
寿险系统不是一个普通的“订单系统”，它承载着数亿家庭的生命保障、财务安全与情感寄托。每一个保单编号，背后都是一个家庭的希望。
你的代码，是责任的代码。
你的架构，是信任的架构。
1489
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
