非常感谢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服务器就搞定了所有事情。另外如果要将互联网金融平台质量特性排个序，很显然最重要的是安全性、可靠性，这毕竟是关系到用户的血汗钱。安全性和可靠性也会直接影响功能的技术实现，但并没有并发性影响性大。深入分析职责后把每一种功能的实现关键技术列出，如下：

　　如上所述，要支持运营目标的陆金所平台，可以分为大小十几个服务和子系统。系统划分的依据一方面是职责，一方面跟实现技术有关，同一职责下实现技术不同会被划分为两个服务，比如购买商品和商品展示原本属于同一个大的领域，但其因为实现技术和质量要求不同需要划分为两个模块。这是因为微服务和传统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作为服务集群发布的载体。