微服务架构
互联网保险O2O平台微服务架构设计
关于架构，笔者认为并非越复杂越好，而是相反，简单就是硬道理也提如今这里。这也是微服务可以流行的缘由，看看市场上曾经出现的服务架构：EJB、SCA、Dubbo等等，都比微服务先进，都比微服务功能完善，但它们都没有微服务这么深刻民心，就是由于他们过于复杂。简单就是高科技，苹果手机听说专门有个团队研究如何能让用户更加简单的操做。大公司都是由小公司发展起来的，若是小公司在开始技术选型时感受某个框架费时费力就不会选择，而小公司发展到大公司的过程，通常也伴随着系统不断优化的过程，而不断优化每每不会从新选择开发技术和框架，而是在原来基础改进，这也许就是简单框架流行的本质。 html
假设咱们须要为超高业务量的保险代理企业设计一个“互联网+”保险平台。假设这家保险代理企业网上保险注册用户规模为2千万，门店及加盟商销售人员2万，年保单量2亿单（中国平安总用户规模达1.67亿，拥有超过79.8万名寿险销售人员和约24.6万名正式雇员。截至2015年6月30日，集团总资产达4.63万亿元，归属母公司股东权益为3,311.90亿元。而目前互联网保险领头羊众安保险，经营以小额贷款为主，因为背靠阿里巴巴，日保单销售量可达1亿，不过别人很难复制众安保险的模式）。所以咱们取大型互联网企业和众安保险的折衷来考虑这个保险O2O平台。前端
l 需求分析
参考保险业务相关文档（文档不全），得到以下核心需求矩阵（由于涉及功能太多，只取大的功能点）。nginx
| 分类web |
功能redis |
质量spring |
约束数据库 |
| 电子商务（B2C）api |
产品展现（搜索、详情展现等）缓存 |
及时响应、安全性、健壮性、易用性安全 |
多种险种，处理方式可能不一样 |
|
|
产品购买（提交订单、支付） |
及时响应、安全性、健壮性、易用性 |
多种险种，处理方式可能不一样 |
|
|
用户中心（个人保单、个人理赔等） |
及时响应、安全性、健壮性、易用性 |
多种险种，处理方式可能不一样 |
| 代理人管理（加盟商管理） |
车险投保（询价、录单、缴费） |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
|
|
非车险投保（询价、录单、缴费） |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
|
|
保单查询 |
及时响应、健壮性、可扩展性 |
|
|
|
单证管理 |
及时响应、健壮性、可扩展性 |
|
|
|
个人帐户（个人保单、佣金结算等） |
及时响应、安全性、可靠性、易用性 |
多种险种，处理方式可能不一样 |
| 案卷管理 |
案卷录入 |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
|
|
索赔资料收取 |
及时响应、健壮性、可扩展性 |
|
|
|
案卷交接 |
及时响应、健壮性、可扩展性 |
|
|
|
案卷跟踪 |
及时响应、健壮性、可扩展性 |
|
| 客户管理 |
客户信息维护 |
及时响应、健壮性、可扩展性 |
上传大量文件 |
|
|
客户活动管理 |
及时响应、健壮性、可扩展性 |
|
|
|
商机管理 |
及时响应、健壮性、可扩展性 |
|
|
|
个人工做台（消息、活动、商机） |
及时响应、健壮性、可扩展性 |
|
| 保险公估 |
车险定损过程跟踪协助 |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
|
|
人伤出险协助 |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
|
|
法律援助服务 |
及时响应、健壮性、可扩展性 |
多种险种，处理方式可能不一样 |
从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 |
| 报表数据库 |
是 |
|
|
| 日志采集服务数据库 |
|
是 |
日志ID |
除工具数据库外，其它的数据库的划分很容易理解。工具数据库的数据也大都跟客户或说用户有关，好比“产品对接服务”，产品对接服务是指用户在购买了保单后，系统会自动对接到具体的保险公司接口去上传保单信息和下载保单，因此水平切分数据库时能够采用用户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.七、 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