孢子框架-互联网金融平台微服务架构设计

　　按照孢子框架要义对互联网金融理财平台进行微服务架构设计。假设我们设计的目标是5年后的陆金所（https://www.lu.com/）。陆金所简介，平安集团旗下理财平台，是中国最大的网络投融资平台之一，2011年9月在上海注册成立，注册资本金8.37亿元，lufax结合全球金融发展与互联网技术创新，在健全的风险管控体系基础上，为中小企业及个人客户提供专业、可信赖的投融资服务，帮助他们实现财富增值。截至2014年1月末，注册用户已逾570万。

l 需求分析

参照陆金所，获得如下核心需求矩阵。

分类	功能	质量	约束
前端用户首页及其它	产品展示	及时响应、搜索引擎优化
	本周特推	及时响应、搜索引擎优化	根据用户特性推荐
	广告图片	及时响应、搜索引擎优化	可随时更换
	公告	及时响应、搜索引擎优化	可随时发布
	帮助中心	及时响应、搜索引擎优化	可随时发布
	上证指数显示	及时响应	实时同步上证指数
	促销活动	及时响应、搜索引擎优化	可随时发布
	媒体报道	及时响应、搜索引擎优化	可随时发布
	常见问题	及时响应、搜索引擎优化	可随时发布
	产品搜索	及时响应、搜索引擎优化
	投资某产品	及时响应、安全性、可靠性	多种投资品种，某些品种投资流程不一样
	登录、注册	及时响应、安全性	符合国家安全等级标准
分类	功能	质量	约束
前端用户会员中心	账户总览	及时响应、安全性
	我的投资	及时响应、安全性
	我的借款	及时响应、安全性
	资金记录	及时响应、安全性
	充值、取现	及时响应、安全性、可靠性
	账户安全设置	及时响应、安全性
	我的陆金币	及时响应、安全性
	我的商品	及时响应、安全性
	我的消息	及时响应、安全性
	推荐好友	及时响应、安全性

 

分类	功能	质量	约束
前端用户会员俱乐部	商品推荐	及时响应、搜索引擎优化	可随时设置规则，自动推荐商品
	商品详情	及时响应、搜索引擎优化
	购买商品	及时响应、安全性、可靠性
	秒杀购买商品	及时响应、安全性、可靠性
	活动类推荐	及时响应、搜索引擎优化
	活动类详情	及时响应、搜索引擎优化
	活动类玩法	及时响应、搜索引擎优化	目前包括：刮刮乐、抽奖、竞猜、竞拍
	商品、活动搜索	及时响应、搜索引擎优化
	新手指南	及时响应、搜索引擎优化	可随时更新
	登录	及时响应、搜索引擎优化、安全性	会员登录后免登陆
分类	功能	质量	约束
后台运维业务需求	系统管理	及时响应
	不同产品的运维管理	及时响应、可扩展性
	不同产品的发布管理	及时响应、可扩展性
	新闻及公告发布	及时响应
	统计及报表	及时响应

 

　　宏观上讲，陆金所的运营目标是要打造一个互联网金融理财平台。目前产品包括：稳盈-安e、稳盈-变现通、稳盈-鑫保、安盈-票据、点金计划、大数金融等P2P理财产品，包括信托理财、粤股交等专享理财产品，还包括1000多只基金，以及零活宝、保险理财等投资理财产品。所有理财对于前端用户来说目的和操作只有一个，那就是投资，然后获取收益。从需求分析来看，互联网金融理财平台可以看做是一个金融类的电子商务网站，用户在其上选择产品并投资，这和传统电子商务选择产品进行购买操作类似。

       上面的需求我简化了后台运维功能的需求，一方面我不是陆金所的开发人员，也不知道他们具体有哪些需求。另外一方面，金融产品后台运维管理及其复杂，因为涉及到钱，我们也不好去猜，所以就给出了几个简化的大项后台功能需求。 

l 系统分析

       要将需求进行系统分析，还需要有企业的运营目标做支持。我们假设陆金所5年后运营目标是：

       产品方面：继续上线当前没有的理财产品（比如期货、现货投资）

       注册人数：达到3000万

       年营业额：达到1000亿

       网站日访问量：3000万PV

       产品购买并发：1000 QPS

那么我们按照上面的需求，进行系统分析，首先按大的职责将职责相同的划分为一个服务。并且有了上面这个经营目标，所有功能需求都需要增加一项“质量”特性，那就是“高并发”，高并发会影响到所有设计。如果只有几个用户在使用整个系统，那么显而易见一个应用，也不需要什么微服务，一个web服务器就搞定了所有事情。另外如果要将互联网金融平台质量特性排个序，很显然最重要的是安全性、可靠性，这毕竟是关系到用户的血汗钱。安全性和可靠性也会直接影响功能的技术实现，但并没有并发性影响性大。深入分析职责后把每一种功能的实现关键技术列出，如下：

　　如上所述，要支持运营目标的陆金所平台，可以分为大小十几个服务和子系统。系统划分的依据一方面是职责，一方面跟实现技术有关，同一职责下实现技术不同会被划分为两个服务，比如购买商品和商品展示原本属于同一个大的领域，但其因为实现技术和质量要求不同需要划分为两个模块。这是因为微服务和传统SOA最大的区别就是技术实现的个性化，只有个性化才能做好做专，并节省成本。另外根据系统分析，我们需要将第三方调用的地方抽取为服务，比如支付，将这些第三方调用抽取为一个单独的服务首先也是基于职责考虑，其次是基于稳定性考虑，因为调用第三方的东西通常存在很大的不稳定性，当某一厂商提供的API不能用时，我们的系统需要自动切换到可用的API。用户购买产品产生订单相关数据，订单数据关系到商品和用户两方面，如果是超高并发的系统，用户购买行为需要单独的服务，但限于互联网金融的特殊性-不会在同一时刻产生大量交易，我们将订单服务合并到用户账户服务，因为从数据角度来讲，订单属于每一个用户。

       另外，金融平台和会员俱乐部从大的方面来讲是两个独立的系统。双方不共用任何基础数据，如果需要对方数据通过各自的接口进行交互。总的来说，虽然有十几个服务，但有些服务工作量并不是很大，有一些小的服务比如支付、通知等，一个开发人员可以开发好几个，所以总体上所需的开发成本比传统SOA还是要低很多，而且传统SOA技术门槛过高，对开发工程师要求较高，不像微服务只要定义好接口和规则，普通开发人员都能做。

 

l 逻辑架构

逻辑视图采用以下方法建立。

 　　

按照职责、通用性、技能及工作量综合考虑和计量，平台逻辑架构设计如下图：

　　

　　十几个子系统分别分布在服务层、服务监控与治理、表现层。实体层和接口访问层虽然属于“层”，但它们并不单独发布，而是使用Jar包类库的方式提供给其它服务调用，是逻辑上的层。业务服务模块具有模块化，构件化的特点，并可以以各种不同的协议发布服务，包括SOAP、RMI、REST、JMS等。

 

l 开发架构

系统所需的工程，“[ ]”里面表示工程的名称。

　　

所需公共模块工程：

　　

 

开发环境：

编码：UTF-8                                          

工具：Myeclipse 10

SVN：Site-1.8.22

注释插件：Jautodoc_1.8.0

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

缓存框架：Ehcache 2.6、Redis

日志管理：SLF4J 1.7、Log4j

数据库：MySql 5.5

 

l 运行架构

　　此架构设计视图的关注点是控制流组织。运行架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起－即在哪个控制线程上，对象的操作被实际执行。

　　

主要控制流包括：

l  页面访问控制流

由前端浏览器发起请求，部分请求首先会到缓存里查询，如果缓存里有结果则返回，如果没有缓存内容，则继续请求web服务器。也有部分无需缓存的请求直接访问web服务器获取数据。

l  日志采集

操作日志采集有两条控制流。一条是页面的采集js，直接将用户请求发送至日志采集接口，由日志采集接口提交给消息队列，再由日志采集模块从消息队列里获取数据并保存。另外一条是在web服务器层面拦截访问请求并提交给消息队列，并由日志采集模块获取和处理。

l  自动对账

由接口访问层拦截需要记账的操作，并转换成记账凭证提交到消息队列，由自动对账模块从消息队列中获取数据并保存。自动对账功能是由定时任务触发，由自动对账服务按规则进行对账计算，如果需要预警则产生预警数据。

l  手机APP访问

由手机app发起，部分请求首先会到缓存里查询，如果缓存里有结果则返回，如果没有缓存内容，则继续请求web服务器。也有部分无需缓存的请求直接访问web服务器获取数据。

l  运维管理

由浏览器发起请求，考虑到并发情况并不是很大，可不经过缓存服务器，直接与web服务器运维服务交互。

 

l 物理架构

此架构设计视图的关注点是物理节点（Node）分布，以及软件到硬件的具体映射关系。

　　

主要关键技术：

l  负载均衡

1）采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载均衡。并通过nginx实现反向代理服务器集群。

2)  接口如果使用rest使用nginx作为负载均衡器，如果使用dubbo\netty\thrift\Mina则使用zookeeper实现业务服务的负载均衡。

l  缓存

1）系统使用Varnish 集群以作为静态页面和图片的高速缓存。

2）使用Redis集群作为业务层的高速缓存，Redis具有高并发、高可用等特性。

l  文件存储

鉴于平台文件存储业务并不复杂，通过NFS实现文件存储集群。

l  消息队列

系统使用高并发、高稳定性消息队列rabbitmq实现异步消息处理。

l  Docker集群

系统采用最新的虚拟机技术docker作为服务集群发布的载体。

 

14楼有一点难

楼主开源么？怎么在开源地址，没找到代码，谢谢。

13楼lzhou666

孢子框架把数据路由放到了业务层就是解决这个问题的，可以不考虑接口间的事务了，只要规划的好，是可以避免的，如果实在无法避免，特殊情况特殊处理，靠类似try catch结构处理，就是如果某个接口调用出错，就执行catch里面的代码

12楼Treenew Lyn

文章写的不错！

11楼kevin0227

此Web框架对于大中型的互联网够用了，但对于京东、淘宝这类并发量很大的网站，这个架构不满足了。

Re: lzhou666

@kevin0227，引用此Web框架对于大中型的互联网够用了，但对于京东、淘宝这类并发量很大的网站，这个架构不满足了。，那是的，京东、淘宝是超高并发，按照本文需求没涉及到超高并发

10楼其实我不笨

mark

9楼轮回

没干过实际大项目的，肯定写不出这样一套方案，楼主大牛啊

Re: lzhou666

@轮回，引用没干过实际大项目的，肯定写不出这样一套方案，楼主大牛啊，最近闲的蛋疼，见笑了

8楼kevin0227

框架中的接口层主要是干什么用的，不是特别理解，难道只是通过接口调用服务层的服务吗？

7楼youknow

请问您这些图都是用什么工具画的

Re: lzhou666

@youknow，引用请问您这些图都是用什么工具画的，画图工具 亿图

6楼s3

微服务之间的事务如何保证的？

5楼s3

你这个框架算是一个通用性的，对于金融系统更关键的资金这块没提到。，我是觉得这个框架是好的web框架，不是金融系统的框架

Re: lzhou666

@s3，引用你这个框架算是一个通用性的，对于金融系统更关键的资金这块没提到。，我是觉得这个框架是好的web框架，不是金融系统的框架，金融这块多了凭证记录，就是记账凭证，因为并发量不大，其它的也没什么，如果是高并发可能要搞消息队列、撮合计算之类的，使用了这些后类似于股票交易了，用户第一时间成交不了，这个网上理财还没有先例，所以没有设计。

4楼lzhou666

框架的确很普通，基本上就是web架构入门级的，但入门级的很多中小公司也做不到的，所以贴出来大家共享

3楼lzhou666

金融的并发量不大的，假设1秒钟1000次，1000次*60秒*10000元=6亿，，一分钟可以产生6亿资金流了。

2楼T~T

为什么起一个这么名字呢--孢子。

Re: lzhou666

@T~T，引用为什么起一个这么名字呢--孢子。，随便起的，总的有个名字好说话，以前有个游戏叫孢子，孢子很像微服务，另外炒期货有个孢子理论，呵呵。

1楼kevin0227

对于分布事事务，楼主你们是怎么做的及服务之间的调用！

Re: lzhou666

@kevin0227，引用对于分布事事务，楼主你们是怎么做的及服务之间的调用！，后台服务通信也是rest，也通过nginx，不过国内用的多的是thrift加zookeeper，至于分布式事务，用到极少接口，分别实现了回滚接口，调用端出异常，就调回滚接口。或者，发回滚事件给消息队列，服务提供端监听消息队列并执行回滚方法。