微服务架构设计

互联网金融平台微服务架构设计

　　按照孢子框架要义对互联网金融理财平台进行微服务架构设计。假设我们设计的目标是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.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)    使用zookeeper实现业务服务的负载均衡。

l  缓存

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

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

l  文件存储

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

l  消息队列

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

l  Docker集群

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