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

很是感谢http://www.cnblogs.com/skyblog/p/4915383.html

 

对互联网金融理财平台进行微服务架构设计。假设咱们设计的目标是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服务器就搞定了全部事情。另外若是要将互联网金融平台质量特性排个序，很显然最重要的是安全性、可靠性，这毕竟是关系到用户的血汗钱。安全性和可靠性也会直接影响功能的技术实现，但并无并发性影响性大。深刻分析职责后把每一种功能的实现关键技术列出，以下：

分类	需求	实现子系统及服务	实现技术（软硬件结合）
前端用户首页及其它	产品展现、产品搜索、促销活动、推荐服务	平台商品服务	集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化
	广告图片、公告、帮助中心、媒体报道、常见问题	平台商品服务	集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化
	投资某产品	平台会员服务	集群部署、消息队列、实时计算
用户会员中心	帐户总览、个人投资、个人借款资金记录、帐户安全设置、个人陆金币、个人商品、个人消息、推荐好友、充值	平台会员服务	集群部署
前端用户会员俱乐部	商品推荐、商品详情、活动类推荐、活动类详情、商品、活动搜索	俱乐部商品服务	集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化
	购买商品、秒杀购买商品、活动类玩法	俱乐部会员服务	集群部署、消息队列、实时计算
新增系统服务需求	商品推荐	日志采集系统	集群部署
	充值、支付	第三方支付服务	集群部署
	短信、邮件通知	通知服务	集群部署、调用多家第三方短信接口
	安全性	服务受权及审计服务	集群部署
	数据可靠性	自动对帐服务	集群部署
前端页面	网站前端页面	平台网站WEB、WAP端	集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化
	网站前端页面	会员俱乐部WEB、WAP端	集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化
运维管理	系统管理、不一样产品的运维管理、不一样产品的发布管理、新闻及公告发布、统计及报表	运维管理服务	集群部署
	运维管理前端	运维管理WEB端	集群部署
手机客户端	手机客户端	Andriod APP及苹果APP

　　如上所述，要支持运营目标的陆金所平台，能够分为大小十几个服务和子系统。系统划分的依据一方面是职责，一方面跟实现技术有关，同一职责下实现技术不一样会被划分为两个服务，好比购买商品和商品展现本来属于同一个大的领域，但其由于实现技术和质量要求不一样须要划分为两个模块。这是由于微服务和传统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.七、 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.六、Redis

日志管理：SLF4J 1.七、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做为服务集群发布的载体。