保险公司产险电销系统新平台项目方案征集书.doc

产险电销系统新平台项目 - 方案建议书第1章 对本次征集的目标和需求的回应1.1 项目目标理解 建设以人为中心的，以任务驱动的多产品销售系统。 支持多产品的快速扩展。 实现系统的模块化，轻应用化，降低系统的耦合度。 实现前端功能的可配置化，减少坐席操作的复杂度。 提高系统性能，以应对坐席扩容到10000至15000。 增加系统灵活性，以应对不同的挑战业务架构设计原则1.1.1 以人为中心的销售系统 以人为中心的销售系统：现有系统的销售模型是以车为中心安排销售计划和任务，随着业务的发展，该模型已经不再适应现有的业务需要，因此本次系统重构就是将业务模型由以车为中心调整为以人为中心，通过人的唯独来安排销售计划，任务以及售后服务 以任务驱动的销售系统：现有的系统可以说是一个简单的任务驱动的销售系统，其仅仅只有车险销售一种任务。新的电销系统将支持复杂的任务驱动模型，不但能够产生覆盖车，非车险，非保险产品的销售任务同时也能够支持产生服务类和自定义任务。系统能够通过任务来更好的规划业务销售和服务流程。 支持产险非车险以及非保险产品的销售系统：现有的系统和它的名字一样，仅仅只是车险销售系统，但从现在行业发展来看电话销售不应该仅仅限于销售车险，其应该作为产险的一个销售渠道，能够销售多元化的产品。因此新的系统需要支持产险除车险以外其它保险产品的销售1.1.2 支持多产品的快速扩展 新的电销系统需要支持多种保险产品以及非保险产品的销售。 需要能够根据业务需要灵活的改变产品的组合，比如车加意，车+保养等优惠产品组合 需要能够根据市场的要求在短时间内调整产品属性，比如打折，优惠等。1.1.3 实现系统的模块化、轻应用化及低耦合化 能够提升系统的稳定性，降低系统出错的概率。 和已经完成模块化的系统(配送，质检，名单)对接。 前端销售轻量化方便操作任务学习和掌握技能 拆分现有的系统,将其按不同的业务划分为不同的模块1.1.4 实现前端功能的可配置化 系统能够跟据不同的权限展现不同的前端操作界面1.1.5 增加系统灵活性 系统功能采用可配置化，能够灵活的打开和关闭，可以应对不同的情况1.1.6 非功能性需求 最少支持15000个坐席同时使用该系统。 对系统进行性能测试，通过性能测试报告分析要优化的点。 支持7*24小时服务，稳定性应达到99.9%-99.99%，系统年故障时间低于4.8小时,平均故障恢复时间低于1小时本项目最终需要实施的功能性需求及非功能性需求以项目启动后的客户确认的需求规格说明书为准。1.2 业务解决方案1.2.1 业务架构设计原则1.2.1.1 业务平台化 业务平台相互独立，如交易平台、支付平台、销售平台。 基础业务下沉，可复用。如，用户、商品、品类。1.2.1.2 核心业务、非核心业务分离 系统核心业务与非核心业务分离，核心业务精简（利于稳定），非核心业务多样化。如，主交易服务、通用交易服务。1.2.1.3 区分主流程、附流程 区分哪些是系统主流程。运行时，优先保证主流程顺利完成，辅流程可以采用后台异步化的方式。避免主流程失败导致主流程的回滚。如，下单时，同步调用快照，异步通知台账，短信通知。1.2.1.4 隔离不同类型的业务 交易业务就是签订买家、卖家之间的交易合同，需要确保高可用性，让用户能够快速下单。 质检业务对可用性没有太高的要求，可以优先保证一致性。 秒杀业务对高并发要求很高，应该跟普通业务隔离。1.2.2 业务架构设计原则1.2.2.1 稳定性原则 一切以稳定为中心 架构尽可能简单、清晰 不过度设计1.2.2.2 解耦/拆分 稳定部分与易变部分分离 核心业务与非核心业务分离 主流程与辅流程分离 应用与数据分离 服务与实现细节分离1.2.2.3 抽象化 应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理数据库的位置和分片 服务器抽象化：应用虚拟化部署，不需要关心实体机配置，动态调配资源1.2.2.4 松耦合 跨域调用异步化：不同业务域之间尽量异步化解耦。 非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦 必须同步调用时，需要设置超时时间和任务队列长度1.2.2.5 容错设计 服务治理：服务能彼此独立修改、部署、发布和管理。避免引发连锁反应 集群容错：应用系统集群，避免单点1.2.3 业务逻辑架构说明：根据要求，新的电销系统将拆分为更加专业的模块。系统将形成销售服务，人力资源服务，运营管理，销售管理，客户信息管理，后台维护等相关应用。 销售服务：包含报价模块，批改模块，质检模块，支付模块，落地服务模块。 人力资源服务: 包含人事管理，质检人员管理，批改人员管理，在线培训与考试，坐席排班管理 运营管理:包含产品管理，知识库，公告管理，模板管理 销售管理:包含活动管理，名单管理，话术管理，单证管理 客户信息查询管理: 包含白名单管理，字典数据管理，沟通管理 后台维护: 包含运维支持，实时监控，统一登陆，组织人员架构管理，权限管理 作业管理: 包含批处理作业，归档作业1.2.4 系统功能及流程说明1.2.4.1 销售模块1.2.4.1.1 报价模块 功能描述负责保险产品的报价与销售，其包含车险，非车险以及非保险产品 非车险销售流程说明a) 非保险销售流程说明 车险销售流程说明1.2.4.1.2 批改模块 功能描述实现对保单的更改； 流程说明1.2.4.1.3 支付模块 功能描述完成支付号的生成以及保单的支付； 电话支付(上海) 电话支付1.2.4.2 人力资源服务1.2.4.2.1 人事信息管理 功能描述管理人事信息； 流程说明1.2.4.2.2 在线培训与考试 功能描述实现对坐席的培训与考试； 流程说明1.2.4.3 运营管理1.2.4.3.1 知识库管理 功能描述问题的解决方案以便后人查询； 流程说明1.2.4.3.2 公告管理 功能描述发布系统通知和公告； 流程说明1.2.4.4 销售管理1.2.4.4.1 活动管理 功能描述坐席销售任务的整体计划描述； 流程说明1.2.4.4.2 话术管理 功能描述给坐席在销售过程中提供标准话术； 流程说明1.3 技术架构设计方案1.3.1 总体架构设计原则1.3.1.1 架构基本原则本系统采用Java语言作为主要开发语言，在开发时遵循以下架构设计原则。 以服务为核心的系统架构，电销围绕着“业务流程”展开的，充分保证系统功能和流程实现的灵活性和扩展性 采用标准和开放技术 采用面向对象的技术 采用前后端分离的技术 采用三层分布式架构 采用基于JavaEE的B/S技术架构 采用增强Web动态能力的Ajax技术 采用基于组件的技术1.3.1.2 业务流程图1.3.1.3 软件开发平台及框架具体架构图如下：1.3.1.4 项目关键技术组件 目前电销项目中存在大量名单数据文件批量双向导入。建议采用高度可视化ETL工具DataExchange进行数据高性能批量写入。 DataExchange产品定位 DataExchange集成场景 DataExchange典型应用场景 工作原理-数据不落地模式 工作原理-数据落地模式 整体设计是基于目前微服务的架构思想进行设计，采用目前互联网比较流量的分布式服务框架DubboX工作原理如下：1） 服务提供者注册到服务中心后，服务消费者会自动同步服务提供者列表。2） 服务消费者调用服务时，会根据软负载均衡算法直接调用服务提供者。3） 当某个服务提供者节点宕机后，服务注册中心会通知服务消费者更新服务提供者列表。4） 当服务注册中心集群宕机后，服务消费者可根据自身缓存的服务提供这里表继续工作。1.3.2 总体架构设计1.3.2.1 系统架构图及说明1.3.2.2 项目面向互联网化解决方案设计策略拆分尽量让手机、PC复用前端页面。采用半静态化分离。前端页面展示与后端动态资源分离。前后端采用Dubbox进行系统间的同步交互解耦按照系统不同的垂直业务领域进行解耦。每个垂直业务领域都是单独的一套系统，提供服务。进而使系统由原来的单体式应用变成分布式面向微服务的整体架构。动态伸缩SaCaAclome为用户提供了能满足应用弹性控制场景的图形化策略定义工具，支持复杂策略条件的定义，以满足客户不同的使用场景。基于SaCaAclome开发高可扩展性业务系统，用户能够按需定制系统自动伸缩控制策略，在业务出现短期负载冲击时，SaCaAclome可基于预定义策略自动调配资源完成应急响应；在业务负载逐渐平缓降低时，可以自动化回收资源，让业务应用随着负载的变化动态调整资源，提升资源利用效率。服务高可用面向用户、业务人员的前端系统采用Nginx或者Apache进行系统的高可用保证。面向服务的系统间通信采用Dubbox进行系统的高可用保证 面向用户应用的动态发布应用系统采用Nginx或Apache实现动态扩展。将待发布的服务包构建好，并存放在docker容器中。在集群环境中分别启动每个docker容器。并且动态修改Nginx或Apache负载均衡配置，确保应用热发布 面向服务的动态发布系统框架统一采用Dubbox分部署服务框架实现服务动态动态注册、发现，进而实现热发布。将待发布的服务包构建好，并存放在docker容器中。在集群环境中分别启动每个docker容器。 应用本身是无状态热/灰度发布在热度发布过程中可以快速的发布任意系统Dubbox能够自动、快速的发现应用。前端应用发布后，需要手动或者自动（需要人为写动态脚本或者依赖类似Aclome这样的弹性伸缩应用）添加配置，无需重启前端本身异步交互在跨业务系统交互过程中与非主流程业务交互改成异步通讯模块，依赖于成熟的消息中间件，改造成发布订阅模式。目前可以采用消息中间件实现。1.3.2.3 系统架构设计原则整体架构设计图：特殊说明：每个系统都有使用自己独立的数据库。并且工程分为应用端、接口端分别部署。1.3.3 系统数据库架构设计原则1.3.3.1 统一数据视图 保证数据的及时性、一致性、准确性、完整性1.3.3.2 数据、应用分离 应用系统只能依赖逻辑数据库 应用系统不能直接访问其他宿主的数据库，只能通过服务访问1.3.3.3 数据读写分离 访问量大的数据库做读写分离 数据量大的数据库做分库分表 不同业务域数据库做分区隔离1.3.3.4 合理使用缓存 数据库有能力支撑时，尽量不要引入缓存 合理利用缓存做容灾1.3.4 系统部署原则1.3.4.1 N+1原则 确保为故障多搭一套系统，避免单点问题。 功能开发与运维分开。系统开发完成