o2o业务架构图解析 o2o企业内部架构
关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里。这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB、SCA、Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂。简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作。大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而小公司发展到大公司的过程,一般也伴随着系统不断优化的过程,而不断优化往往不会重新选择开发技术和框架,而是在原来基础改进,这也许就是简单框架流行的本质。
假设我们需要为超高业务量的保险代理企业设计一个“互联网+”保险平台。假设这家保险代理企业网上保险注册用户规模为2千万,门店及加盟商销售人员2万,年保单量2亿单(中国平安总用户规模达1.67亿,拥有超过79.8万名寿险销售人员和约24.6万名正式雇员。截至2015年6月30日,集团总资产达4.63万亿元,归属母公司股东权益为3,311.90亿元。而目前互联网保险领头羊众安保险,经营以小额贷款为主,由于背靠阿里巴巴,日保单销售量可达1亿,不过别人很难复制众安保险的模式)。因此我们取大型互联网企业和众安保险的折衷来考虑这个保险O2O平台。
l 需求分析
参考保险业务相关文档(文档不全),获得如下核心需求矩阵(因为涉及功能太多,只取大的功能点)。
分类 |
功能 |
质量 |
约束 |
电子商务(B2C) |
产品展示(搜索、详情展示等) |
及时响应、安全性、健壮性、易用性 |
多种险种,处理方式可能不同 |
|
产品购买(提交订单、支付) |
及时响应、安全性、健壮性、易用性 |
多种险种,处理方式可能不同 |
|
用户中心(我的保单、我的理赔等) |
及时响应、安全性、健壮性、易用性 |
多种险种,处理方式可能不同 |
代理人管理(加盟商管理) |
车险投保(询价、录单、缴费) |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
|
非车险投保(询价、录单、缴费) |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
|
保单查询 |
及时响应、健壮性、可扩展性 |
|
|
单证管理 |
及时响应、健壮性、可扩展性 |
|
|
我的账户(我的保单、佣金结算等) |
及时响应、安全性、可靠性、易用性 |
多种险种,处理方式可能不同 |
案卷管理 |
案卷录入 |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
|
索赔资料收取 |
及时响应、健壮性、可扩展性 |
|
|
案卷交接 |
及时响应、健壮性、可扩展性 |
|
|
案卷跟踪 |
及时响应、健壮性、可扩展性 |
|
客户管理 |
客户信息维护 |
及时响应、健壮性、可扩展性 |
上传大量文件 |
|
客户活动管理 |
及时响应、健壮性、可扩展性 |
|
|
商机管理 |
及时响应、健壮性、可扩展性 |
|
|
我的工作台(消息、活动、商机) |
及时响应、健壮性、可扩展性 |
|
保险公估 |
车险定损过程跟踪协助 |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
|
人伤出险协助 |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
|
法律援助服务 |
及时响应、健壮性、可扩展性 |
多种险种,处理方式可能不同 |
从O2O的概念来看:“O2O即Online To Offline,也即将线下商务的机会与互联网结合在了一起,让互联网成为线下交易的前台。这样线下服务就可以用线上来揽客,消费者可以用线上来筛选服务,还有成交可以在线结算,很快达到规模。该模式最重要的特点是:推广效果可查,每笔交易可跟踪(百度百科)”,不是每一种服务都适合O2O。商品类的销售不适合O2O,因为你直接从网店就可以购买根本不需要线下店。但保险类服务的确需要线下和线上结合,如果是纯线上将不能满足客户的服务需求。O2O的线下服务可以是加盟商、代理人,也可以是直营店。
上面的需求是按照用户角度提出的,虽然使用“系统”一词,但这里的系统是一个抽象概念,可能包括软件系统以及人事、制度等在内。上面的需求可以分为三大类,一类是针对终端用户纯线上服务:电子商务网站(B2C);一类是专门针对代理人服务的:代理人系统;剩下的是一些公共服务,有可能电子商务网站和代理人系统都会用到的一些服务。另外保险业务最大的一个问题是多个险种,不同险种处理方式有很大不同,这跟普通电子商务网站区别很大,比如天猫,所有商品都是同样的下单方式,同样售后服务(主要就是快递这块),而保险产品即使是线上B2C网站下单操作,短险、寿险、车险等也是不同的,更何况保险有一大堆售后服务,这些售后服务更加不相同。传统保险公司在处理这方面时,一般会做多个系统,比如寿险系统,车险系统等等。
l 系统分析
安装之前提到的业务规模我们分析(假设)出一些比较重要的性能需求:
a)产品方面:继续上线当前没有的保险产品
b)B2C网站日访问量:5000万PV
c)B2C产品购买并发高峰:2000 TPS
d)运维系统同时在线:1万(共有2万销售员或代理人)
e)运维系统并发高峰:2000 TPS
f)短险订单:每年1.85亿单
g)长险订单:每年500万
h)车险订单:每年1000万
i)案卷信息:每年新增100万单
日访问量5000万和产品并发2000 TPS是我们假设的,客户信息和案卷信息是随订单数据量变化而变化,在前面我们虽然假设了总共每年产生2亿个订单,但是根据保险种类,短险(旅游险、伤残险)明显产生了90%的订单量,这一点需要特殊处理。除此之外车险和长险(主要指寿险等)无论是投保还是售后服务都有明显不同,所以也需要特殊处理。
那么我们按照上面的需求,进行系统分析,首先按大的职责将职责相同的划分为一个服务。并且有了上面这个性能需求,所有功能需求都需要增加一项“质量”特性,那就是“高并发”,高并发会影响到所有设计。另外如果要将互联网保险平台质量特性排个序,最重要的是可扩展性、安全性,因为保险的种类多而且处理方式不同,除此之外,高并发和可靠性也会直接影响功能的实现,但并没有可扩展性影响大。深入分析职责后把每一种功能的实现关键技术列出,如下:
需求分类 |
实现需求 |
实现子系统及服务 |
软硬件实现技术 |
客户端 |
B2C电子商务网站 |
B2C Web客户端 |
集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化 |
B2C电子商务网站手机客户端 |
B2C App客户端 |
|
|
代理人管理 |
代理人Web客户端 |
集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化 |
|
代理人管理手机客户端 |
代理人App客户端 |
|
|
案卷处理管理 |
案卷处理Web客户端 |
集群部署、分布式缓存 |
|
客户管理管理 |
客户管理Web客户端 |
集群部署、分布式缓存 |
|
保险公估管理 |
保险公估Web客户端 |
集群部署、分布式缓存 |
|
运维产品管理 |
产品管理Web客户端 |
集群部署、分布式缓存 |
|
报表及财务统计 |
报表及财务统计Web客户端 |
集群部署、分布式缓存 |
|
公共服务 |
运维产品管理、Web前端产品访问 |
产品服务 |
集群部署、分布式缓存 |
电子商务或代理人订单管理 |
订单服务 |
集群部署、分布式缓存 |
|
电子商务或代理人等涉及财务操作 |
总账服务 |
集群部署、分布式缓存 |
|
报表及财务统计 |
报表服务 |
集群部署、分布式缓存 |
|
业务服务 |
B2C电子商务网站及手机客户端个人账户 |
B2C个人账户服务 |
集群部署、分布式缓存 |
代理人管理 |
代理人管理服务 |
集群部署、分布式缓存 |
|
案卷处理管理 |
案卷处理管理服务 |
集群部署、分布式缓存 |
|
客户管理 |
客户管理服务 |
集群部署、分布式缓存 |
|
保险公估管理 |
保险公估管理服务 |
集群部署、分布式缓存 |
|
短险开放式接入 |
开放式接入平台服务 |
集群部署、分布式缓存 |
|
工具性服务 |
保险公司产品对接 |
产品对接服务 |
集群部署、消息队列 |
在线支付 |
第三方支付服务 |
集群部署 |
|
短信邮件通知 |
通知服务 |
集群部署、消息队列 |
|
性能监控 |
日志采集服务 |
集群部署、消息队列 |
|
文件服务器 |
文件服务 |
集群部署、消息队列 |
|
服务授权与审计 |
服务授权与审计服务 |
集群部署 |
|
分布式事务管理 |
分布式事务管理服务 |
集群部署 |
|
定时任务管理 |
定时任务服务 |
集群部署 |
各个子系统及模块的关系如下图。
其中订单服务、产品服务、财务服务、工具服务为基础服务,其它各个业务模块的服务会调用这些基础服务。各个业务模块的服务都是根据业务领域进行划分的,同一业务领域下实现技术不同会被划分为两个服务,比如产品展示和订单原本属于同一个大的领域,但其因为实现技术和质量要求不同需要划分为两个服务。因为短险接入量大,而且大部分是跟第三方合作接入,因此设计短险接入公共接口服务平台处理大量短险订单。
l 存储及缓存架构
对于大型的高并发系统来讲,最重要的当属数据的架构。我们在前面也提到过,web系统业务处理模块本身就可以集群部署,当用户出现高并发时最先遇到的瓶颈就是数据库访问的瓶颈。这也是我们说数据架构最为重要的原因。其实web系统是典型的“计算机信息系统”,也就是说一切以数据(信息)为基础,所有的功能都是围绕着数据来的。这也是我们在这里说数据是web系统最重要的,很多公司在做少用户量web系统时直接设计好数据库就可以开发了。
按照上面划分的业务领域我们设计多个数据库,技术选项包括“是否读写分离”、“是否水平切分”及“路由键”。其中路由键是指在进行水平切分后,我们使用那个“标识”去查询数据库,一般来说会使用该业务领域聚合根对象的主键作为路由键。
数据库 |
是否读写分离 |
是否水平切分 |
水平切分路由键 |
产品数据库 |
是 |
|
|
订单数据库 |
|
是 |
客户ID |
公共数据库(元数据、公共数据) |
是 |
|
|
客户管理数据库 |
|
是 |
客户ID |
案卷管理数据库 |
|
是 |
客户ID |
代理人服务数据库 |
|
是 |
代理人ID |
B2C电子商务个人账户数据库 |
|
是 |
客户ID |
保险公估数据库 |
|
是 |
客户ID |
工具数据库(短信、支付、文件) |
|
是 |
客户ID |
报表数据库 |
是 |
|
|
日志采集服务数据库 |
上一篇: o2o平台技术架构 o2o概述-不同点 |