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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:



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

  按照孢子框架要义对互联网金融理财平台进行微服务架构设计。假设我们设计的目标是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作为服务集群发布的载体。

 


本文转自 msj0905 51CTO博客,原文链接:http://blog.51cto.com/sky66/1936416


相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
1月前
|
SQL NoSQL 前端开发
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
|
1月前
|
负载均衡 监控 Dubbo
Java微服务架构设计与实践:构建可伸缩的分布式系统
【4月更文挑战第2天】微服务架构响应现代业务需求,通过拆分大型应用为独立服务实现模块化和可扩展性。Java中的Spring Boot和Dubbo等框架支持服务注册、负载均衡等功能。遵循单一职责、自治性和面向接口原则,每个服务专注特定逻辑,独立部署运行。实际项目中,如电商系统,服务按功能拆分,提升可维护性和扩展性。还需考虑服务通信、数据一致性和监控等复杂话题。Java微服务架构助力构建高效、灵活的应用,应对未来挑战。
Java微服务架构设计与实践:构建可伸缩的分布式系统
|
1月前
|
监控 Java 测试技术
现代化软件开发中的微服务架构设计与实践
随着软件开发的发展,传统的单体应用架构已经无法满足现代化应用的需求。微服务架构作为一种新的设计理念,为软件开发提供了更灵活、可扩展的解决方案。本文将介绍微服务架构的设计原则、实践方法以及相关技术工具,并结合实例展示其在现代化软件开发中的应用。
|
3天前
|
设计模式 负载均衡 安全
探索微服务架构下的API网关设计模式
【6月更文挑战第14天】本文将深入探讨在微服务架构中,API网关的设计模式及其对系统性能和安全性的影响。通过分析不同的设计模式,我们将了解如何在保障服务高可用性和可扩展性的同时,确保系统的灵活性和响应速度。
|
6天前
|
负载均衡 搜索推荐 应用服务中间件
后端开发中的微服务架构设计与实践
传统的单一应用架构已经无法满足当今快速变化的业务需求,微服务架构因其灵活性和扩展性逐渐成为后端开发的主流选择。本文将探讨微服务架构设计与实践,包括微服务架构的概念、优势以及在后端开发中的应用。同时,将结合实际案例分析微服务架构的设计原则和最佳实践,以帮助开发者更好地理解和应用微服务架构。
|
22天前
|
负载均衡 监控 API
探索后端开发中的微服务架构设计与实践
在当今快速发展的互联网时代,后端开发领域的微服务架构设计和实践变得愈发重要。本文将从微服务架构的概念、优势,以及设计和实施过程中的关键问题等方面展开探讨,带您深入了解后端开发中微服务架构的精髓。
19 0
|
29天前
|
监控 负载均衡 Java
【阿里云云原生专栏】微服务架构在阿里云云原生平台上的应用实例与优化策略
【5月更文挑战第20天】本文介绍了在阿里云云原生平台实现微服务架构的步骤,包括基于Spring Cloud的Docker化部署、使用ACK部署微服务,以及优化策略:服务发现与负载均衡(借助Istio)和监控日志管理。通过这种方式,企业能提升应用的可扩展性、可维护性和敏捷性。
211 5
|
1月前
|
消息中间件 Go API
Golang深入浅出之-Go语言中的微服务架构设计与实践
【5月更文挑战第4天】本文探讨了Go语言在微服务架构中的应用,强调了单一职责、标准化API、服务自治和容错设计等原则。同时,指出了过度拆分、服务通信复杂性、数据一致性和部署复杂性等常见问题,并提出了DDD拆分、使用成熟框架、事件驱动和配置管理与CI/CD的解决方案。文中还提供了使用Gin构建HTTP服务和gRPC进行服务间通信的示例。
53 0
|
1月前
|
存储 运维 监控
|
1月前
|
前端开发 NoSQL 数据库
切图仔做全栈:React&Nest.js社区平台(一)——基础架构与邮箱注册、JWT登录实现
切图仔做全栈:React&Nest.js社区平台(一)——基础架构与邮箱注册、JWT登录实现