互联网保险O2O平台微服务架构设计
关于架构，笔者认为并不是越复杂越好，而是相反，简单就是硬道理也提现在这里。这也是微服务能够流行的原因，看看市场上曾经出现的服务架 构：EJB、SCA、Dubbo等等，都比微服务先进，都比微服务功能完善，但它们都没有微服务这么深入民心，就是因为他们过于复杂。简单就是高科技，苹 果手机据说专门有个团队研究如何能让用户更加简单的操作。大公司都是由小公司发展起来的，如果小公司在开始技术选型时感觉某个框架费时费力就不会选择，而 小公司发展到大公司的过程，一般也伴随着系统不断优化的过程，而不断优化往往不会重新选择开发技术和框架，而是在原来基础改进，这也许就是简单框架流行的 本质。&
假设我们需要为超高业务量的保险代理企业设计一个&互联网+&保险平台。假设这家保险代理企业网上保险注册用户规模为2千万，门店及加盟商销售 人员2万，年保单量2亿单（中国平安总用户规模达1.67亿，拥有超过79.8万名寿险销售人员和约24.6万名正式雇员。截至日，集 团总资产达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系统时直接设计好数据库就可以开发了。
按照上面划分的业务领域我们设计多个数据库，技术选项包括&是否读写分离&、&是否水平切分&及&路由键&。其中路由键是指在进行水平切分后，我们使用那个&标识&去查询数据库，一般来说会使用该业务领域聚合根对象的主键作为路由键。
是否读写分离
是否水平切分
水平切分路由键
产品数据库
订单数据库
公共数据库（元数据、公共数据）
客户管理数据库
案卷管理数据库
代理人服务数据库
B2C电子商务个人账户数据库
保险公估数据库
工具数据库（短信、支付、文件）
报表数据库
日志采集服务数据库
除工具数据库外，其它的数据库的划分很容易理解。工具数据库的数据也大都跟客户或说用户有关，比如&产品对接服务&，产品对接服务是指用户在购买了保单 后，系统会自动对接到具体的保险公司接口去上传保单信息和下载保单，所以水平切分数据库时可以采用用户ID作为路由键。&在线支付&和&通知服务&也是类 似，都是保存用户相关的数据，在线支付服务保存的是用户在线支付的流水，通知服务保存的是发送给某用户的短信或邮件。
另外在数据架构中我们也可以看到一个规律，就是使用了水平分库的存储结构就不能再使用读写分离，原因是防止存储单元过度泛滥，因为使用了水平分库之后，本 身也要为数据库建立多个备份库，这个时候如果再用读写分离需要建立一套只读库，数据库的数量将增加一倍。使用了分库后我们可以把热点数据存储在分布式缓存 中以起到读写分离类似的作用。
另外缓存也是存储技术的一种，而且非常重要。从日常生活中我们也可以看到这一点。比如你要去购买一台电脑，你会发现二级缓存和内存大的价格高出很 多，如果你的显卡显存巨大，那将是顶级配置，发烧级配置。手机也是一样，内存大的手机速度明显快，价格也高，如果内存和持久化存储都高，那也是顶级配置。 对于web系统也是一样，有些大型web系统只要缓存处理的好，数据库不需要分库就可以承载亿级的用户，比如维基百科、新浪微博等。也因此，不管是电子商 务网站还是互联网+大型应用，都会在它们的架构中看到缓存大量使用的情况。
从整个web系统的架构来看，缓存在两个层面大量使用，分别是展示层和逻辑层，展示层通常使用高速的页面缓存，逻辑层通常使用高并发的分布式缓存。当然有些分布式缓存工具既可以在逻辑层使用也可以在显示层使用。
是否使用CDN
是否使用高速缓存服务器（varnish）
是否使用分布式缓存（redis）
B2C电子商务网站
报表及财务统计Web端
B2C个人账户服务
代理人管理服务
案卷处理管理服务
客户管理服务
保险公估管理服务
B2C个人账户服务
短险公共平台服务
&l 逻辑架构
在给出系统总体的逻辑架构前，我们先看看系统前端和服务层直接的关系。前端是客户端，可以有多个客户端，也可以有多种客户端，比如手机端 （APP、WAP、微信）等。客户端和服务之间的架构是典型的MVC架构，V是客户端，C就是spring
mvc或servlet开发的控制层，对于Web应用V和C在开发角度是一个工程，剩下的M就是服务层。这是对于web系统来说的，对于app或者使用 html直接实现的客户端，或者是.net实现的桌面客户端，由于这些客户端是单独开发的，没有控制层，因此需要增加一层&API
网关&作为这些客户端的控制层。
图中的服务组件就是指各个业务服务，这些服务可以看成是组件的概念。通常前端界面一个界面中需要的数据通常不仅仅来自于同一个服务，即使是来自于同 一个服务，那也来自于很多不同的接口，servlet或api
网关作为控制层，所起到的作用就是组合接口、组合数据，并处理接口间的事务性。另外服务组件也是分层的，图中并没有展现，一般可以分为3层，从低到高依次 是工具性服务组件、基础业务层服务组件、业务层服务组件。前端界面的请求按照从高到底向下传递和处理请求。
按照职责、通用性、技术特性综合考虑和计量，逻辑架构设计如下图：
十几个子系统分别分布在服务层、控制层、表现层（典型的三层架构）。实体层和接口访问层虽然属于&层&，但 它们并不单独发布，而是使用Jar包类库的方式提供给其它服务调用，是逻辑上的层。服务组件的构成大都是按照业务领域划分的，只有一个除外，就是&B2C 网站&，B2C网站由于是面向终端用户的高并发电子商务网站，为了处理高并发，我们将其拆分为两个业务领域（也可以拆分成多个业务领域，看实际并发量）， 分别是用户账户和产品。用户浏览产品并购买，这是电子商务网站最基本的两个领域。其中产品浏览等功能由更底层的产品服务提供，用户账户功能由会员服务提 供。还有一些功能，比如推荐商品可能是由其它服务提供，这些可以在控制层直接组合这些服务。&
l 服务架构
服务框架采用典型的&服务注册表&模式，注册表使用redis。服务组件在启动时将自己注册进服务注册表，web服务器或api 网关在访问服务时查询服务注册表得到服务的uri，然后调用某服务接口。
淘宝的dubbo使用的是zookeeper作为服务注册表，之所以使用zookeeper，主要是使用它的负载均衡的功能。笔者认为restful接口 没有必要使用zookeeper做负载均衡，可以使用nginx（负载均衡服务器都可以），所以没必要选用动态的zookeeper作为注册表，而是使用 &redis+心跳监测&机制（redis也可以换为LDAP等）来完成服务注册和监控失效服务的功能。这个方案至少比dubbo简单几个数量级，简单就 是硬道理。
在注册服务时只需要注册nginx服务器的IP以及服务描述信息即可。反观dubbo还要注册接口进注册表，笔者认为这个没必要，因为调用一个服务 接口的充分必要条件就是知道服务器的IP即可。至于调用什么服务接口，肯定在代码里已经写死，目标服务器必定存在这个服务接口。将服务接口注册进服务注册 表如果是为了监控审计服务的使用情况，那这个功能使用访问日志来实现能做的更好。
总体的分布式拓补结构如下图：
对于服务集群来讲，看上去像是一个大哥（nginx）带有众多小弟的结构。访问某服务群组只需要访问其nginx服务器即可，这里nginx均采用高可用 方案，防止单台nginx出现问题。至于高层服务调用底层服务也是直接访问其服务器组的nginx。这个执行的流程其实和日常生活中的概念很像，如公司内 部的执行流也是如此：老板分配任务给部门经理，部门经理分配任务给主管，主管分配任务给具体的个人（某单台服务器）。领导们起到的作用也是负载均衡和监 控，负载均衡就是把任务可以分配给多个人同时执行（并且某个执行失败自动切换），监控就不必说了就是监控任务完成情况。在我们的方案里，会专门有个服务去 监控所有服务器的执行情况，很简单的服务就可以做到。
l 关于分布式事务
如果研究一下EJB就会发现，EJB和微服务的架构基本相同，甚至所有面向服务（SCA、SOA等等）的架构都相差不大。很多人反对EJB，并 不是EJB不够强大，而是它不够简单，它给项目带来的复杂性甚至超过了项目本身（这也是笔者不建议使用dubbo框架的原因）。曾有人说过：你要么把事情 做的尽可能简单，让人挑不出毛病；要么把事情做的尽可能复杂，让人找不出毛病，EJB就是后者。EJB分布式事务机制实现的很好，可惜的是这种&一刀切& 的事务机制，大大降低了web系统的性能，所以几乎所有面向互联网的应用都极少使用分布式事务，也就不会采用EJB。互联网应用本身事务性操作并不多，一 些新闻、博客之类的网站甚至都不需要事务。另外一个方面，即使出现一个或两个分布式事务应用场景，也可以通过其它手段解决，比如事件机制等等。
在之前的文章中我们也提到过对于分布式事务最佳的策略是尽量避免。如果避免不了将按以下方式实现。
1）& 将分布式事务性操作封装在一个服务中，这个服务使用XA或链式分布式事务管理。
2）& 可以使用事件机制协调事务管理（具体做法就是事务失败后发失败事件到可持久化的消息队列，然后需回滚操作的接口监控此事件并执行回滚）。
3）& 使用自定义分布式事务管理器管理分布式事务。
笔者设想的自定义分布式事务管理器主要是封装了流程及分布式事务相关功能，笔者将在其它文章专门讨论。如图所示，假设有一个事务需要依次调用 ABCDE五个接口，我们首先调用分布式事务管理接口创建这条&流程&的实例，实例中五个接口分别对应五个状态，调用成功后将该接口对应的状态设置为&成 功&，反之就是&失败&，流程处理结束后，分布式事务检查状态，然后按照一定的策略调用失败接口的反向操作接口去回滚数据（前提条件也是参与分布式事务操 作的接口要开发反向操作接口）。这既是一个简单的流程引擎，也是一个分布式事务协调处理装置，具体是否有必要做的复杂（比如处理并行流程），还要看实际环 境下分布式事务的情况，但笔者认为互联网前端应用使用简单流程应该足以应付。
l 开发架构
系统所需的工程，&[ ]&里面表示工程的名称。
从图中不难看出，我们将运维相关前端界面合并为一个前端系统，总体来讲前端只有3种，B2C前端、APP前端、运维前端。把运维前端合并为一个 项目有利于加快前期的开发、部署的效率，在后期如果某子系统功能界面太多，可以将前端系统独立，比如公估系统、客户管理系统等，独立后的系统需要使用单点 登录，这样就可以在各个系统之间免登陆切换。
开发环境：
编码：UTF-8&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
工具：Myeclipse 10
SVN：Site-1.8.22
Web服务器：Tomcat7
JDK: JDK1.7、 Java EE 5
开发环境：Maven 3&
开发技术选型：
表现层：Bootstrap+Html+Jquery
MVC框架：Spring MVC 3.2
安全框架：Spring security 3.2
Rest接口实现：Spring MVC Rest
持久层：Mybatis3.2
分布式缓存：Redis
数据库：MySql 5.6
官方微博/微信
每日头条、业界资讯、热点资讯、八卦爆料，全天跟踪微博播报。各种爆料、内幕、花边、资讯一网打尽。百万互联网粉丝互动参与，TechWeb官方微博期待您的关注。
↑扫描二维码
想在手机上看科技资讯和科技八卦吗？想第一时间看独家爆料和深度报道吗？请关注TechWeb官方微信公众帐号：1.用手机扫左侧二维码；2.在添加朋友里，搜索关注TechWeb。
Copyright (C)
All rights reserved. 京ICP证060517号/京ICP备号 京公网安备76号
TechWeb公众号
机情秀公众号互联网时代，在网上买保险你要注意这4点
随着互联网时代发展的越来越迅速，越来越多的人选择在网上购买保险。不过网上选购保险虽然有诸多优势，但在线投保可并不是敲敲键盘就能解决的事，这“简单”的背后，也隐藏着很多“不简单”，掌握一些线上选购保险的要领很重要。
1.选择一个靠谱的网站
在网上选购保险的第一步、也是很重要的一步，就是选一个靠谱的网站。一般来说，保险公司的官网和官方渠道、第三方网络平台等都是可以选择的网站选购渠道。但是，消费者在此之前一定要先验明网站是否可靠。最近几年，利用网站销售假保单进行保险欺诈的实例时有发生，还有一些山寨的网站窃取消费者信息用作他途。
那么如何辨别山寨网站呢?
一般来说，假冒的保险电子商务网站虽然与正规网站显示的名称版式相同，但域名却不是完全一样的。假域名会夹杂毫无意义的数字或字母，跟保险公司本身的中英文名称都无法对应。而且，山寨的网站通常功能比较单一，而正规保险公司网站或综合网络保险网站的功能比较齐全，产品种类也比较多。
2.看清保险条款是王道
无论是线上还是线下，看清保险条款都很重要。知道自己要买的产品是什么并且了解它的产品特性。尤其是对于网络投保而言，不少消费者可能会只盯着价格高低就选择购买，但是保险产品千差万别，同样的价格也可能有不同的保障，一味以低价为标准，反而有可能购买到并不实惠的产品。
那么看保险条款时主要应该看哪些内容呢?
投保前应该注意查阅简要的产品介绍，包括具体的保险利益、保障责任、除外责任等。投保后拿到电子保单或纸质保单后，还应查看一遍条款，着重看清条款中有关保险利益除外责任免赔天数（免赔比例）等特别重要的部分内容。
3. 查询保单真假
网上投保成功后，消费者最好再多一个步骤——查询保单真假，因为前几年假保单案件频发，意外险的假保单现象尤为严重。
那么保单真假怎么查呢?
消费者在收到保单后应该立即通过保险公司公告的服务电话和门户网站，查询保单是否真实有效。查看是否有保单号、险种名称、保单生效时间、保险期限、保险金额、被保险人姓名及身份证号等关键内容，看清楚保险公司名称，查看保单印章是否清晰，是否印有该公司的客服电话和保单查询方式。
此外，网上投保得到的一般都是电子保单，它与纸质保单具有同等法律效力，如果选择仅仅接收电子保单，不要纸质保单，一样可以致电保险公司客服电话查询真伪。
4. 充分享受网络投保的优势
相比线下投保，网络投保的一大优势就是消费者可选择性很广，可以货比三家、选出相对最优性价比的产品。因为虽然都是网络投保，但由于渠道不一，或者成本不同，或者运营费用的差异等，同一款产品，或者比较接近的两款产品，在不同的网络销售平台上，可能最后的报价也会有所差异。
那么应该怎么对这些产品进行比较呢?
当你决定通过网络投保一份保险后，不妨通过该保险产品所在保险公司的官网分别进行保费测算，或者相似产品比较，尽量找到符合自己需求、性价比又比较高的产品。当然，除了比较产品价格，消费者还可以对比一下各家公司热线电话的接通率和服务水准，来衡量自己是否选择在这家网站投保某一款保险产品。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点线上OR线下，保险，到底在哪买更安全？线上OR线下，保险，到底在哪买更安全？乔妈说说百家号购买保险，是一个特殊的商业行为，买保险，买的是合同，是条款，呈现出来的，只是几张白纸，赌的，是概率，还是一个最好是白花钱才好的概率。保险行业的特殊性，决定了其购买行为的复杂多样性。互联网日新月异的今天，带给人们更多思考，更多选择，也带给人们很多惶恐，更多选择时的无措，今天，我们来看看，购买保险，是不是应该选择互联网。1:首先从流程讲购买互联网保险产品的流程是这样的：1）网上选择一款保险产品2）提交身份证信息，健康告知，进行购买3）由于国内医保社保联网，身份证信息已经可以查到之前的医保社保记录4）一两天的审核5）通过审核之后，电子保单发送到投保人的邮箱线上购买保险，选择产品是比较困难的过程，不仅需要耗费大量的时间找产品，找平台，还需要掌握基本的保险知识抠条款，做对比。找到产品以后购买，购买过程中重要的是核保，这是某款线上保险的健康告知截图选择“全部无”，恭喜你，可以继续投保了，但请你仔仔细细看清楚健康告知问题，真的是全部问题都“无”？据我所知，现在标准体并不多。选择"部分有"，抱歉，这款保险和你无缘了。当然，各款保险健康告知不一样，购买的时候务必仔细阅读，如实汇报，不然如果发生理赔，可能会产生拒保。如果是线下投保，非标准体，可提供病历和检查报告等材料给保险公司审核，很多都可以正常承保的，即便被拒保了，比起交了好多年保费，最后理赔不了，还是好多了吧。2:产品性价比，与线下购保相比，线上购保最明显的区别之一就是“去中介化”，没有保险推销员“步步紧逼”的引导与服务，节省了中间成本，所以费用更便宜，但产品相关的所有信息都需要你自己在网上了解，这对于习惯了保险销售人员线下一对一讲解的消费者来说，是一个使用门槛。不过现在网络销售渠道的客户服务做得也很出色，所以在我看来产品理解这点是不用担心的。跟面对面服务比起来，“便宜”对用户的吸引力或许会更大些。3:服务方面，是线上保险的一大弱势。买保险最重要的其实还是理赔和分红，产品说的天花乱坠，赔了才是真的。相对于服务热线或是在线客服，一个你认识的、了解的保险代理人（假如靠谱的话）能提供的服务肯定是更为及时、贴心和尽责的。当然，遇到好的保险代理人也需要点运气，许多人签单之前服务态度很好，但保险是长期服务，后续的琐碎事情不少，长期跟进的时候，有些代理人的服务质量就不能保证了。在保单签约之后还能保持良好的甚至是朋友一般的关系的保险代理人，会帮助客户节约非常多的时间成本。而且，一个优秀的保险代理人认识的各色人、各类资源，关键时刻还能帮到一些意料之外的忙，比如留学，就医之类。4:承保方面看，在法律意义上来讲，线上和线下，只要如实健康告知，是不存在区别的，但是在实际操作中，就仁者见仁了，保险公司个体差别比较大，很多线上保险公司理赔服务需要自己办理一应理赔手续，线上沟通线上传各种理赔证件，手续繁琐理赔时间长，这都是实际中存在的问题。而线下有代理人协助，比一个人孤军奋战要安全得多。购买保险是一个长期理性行为，其实线上线下都各有优势，没有最好的，只有最合适的，如果你时间精力充沛，线上找到一款适合自己的好产品，自然是很完美。如果你更喜欢得到服务，就找一个靠谱的保险公司靠谱的代理人，毕竟这样你会更安心。本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。乔妈说说百家号最近更新：简介:吾日三省吾身：看脸，看秤，看余额。作者最新文章相关文章}