如何架构一个新的综合金融交易系统

 

技术产品需求

客户端网站系统(app),业务系统(接口),运维平台

网站系统:

基础系统:

1.用户(帐户)管理系统 2.商品(行情)管理系统 3.订单(交易管理)系统 4.支付系统5.风控系统

增值系统:

客户服务系统,筛选筛选系统,资讯系统。。。

业务系统:

管理系统:

用户管理系统

运营支撑系统

核心系统:

订单交易系统

查询系统

行情系统

增值系统:

数据统计(报表)系统

客户服务系统

 

技术栈选型

1.前端系统

2.后端系统

2.1 负载均衡及http 服务器接入:nginx

2.2 web 应用容器 SOA 服务 Tomcat + dubbo

2.3 文件服务器

        2.3.1 储存方式
        2.3.2 储存容量
        2.3.3 安全性与存取权限控管
        2.3.4 存取效能

2.4 缓存服务器
         2.4.1 分布式Redis缓存
         2.4.2 Memcache缓存

2.5 消息系统
         2.5.1 ActiveMQ
         2.5.2 分布式消息系统Kafka、Rocketmq等

2.6 数据持久层
         2.6.1 关系型数据库
              (1). Mysql

        2.6.2 Nosql
              (1). MongoDB

dubbo系列三—架构

对于架构,我们将从两个层面来理解,一个是屏蔽了细节的使用层面,第二个是关注细节的实现层面。一个外在架构,一个内在的架构,如果我们仅仅是理解下并使用下,那么了解下外在架构就差不多了。而如果需要深入学习使用那么,仅仅了解外在是不够的,我们需要足够多的细节。

外在架构

image

dubbo 主要由三部分组成,服务提供方,服务消费方,注册中心。这是核心的部分,然后是一些外围系统诸如管理,监控等。

Provider :通过容器加载起来服务,然后通过协议将服务注册到注册中心,然后就等待消费方通过预订的协议来调用。

Consumer:消费方也需要向服务注册中心订阅服务,等注册中心将服务信息推送过来之后,消费方就可以透明的通过代理接口通过制定协议及序列化调用服务,并且服务可以是集群的。

Register:注册中心管理服务接口。

更加详细的流程见下图:

image

总结起来dubbo就是个集中管理的分布式服务框架。

架构分层

上述外在架构模型是相对直观,但是其呈现的实现细节较少,现在就来深入的看看其具体实现.

其实不管架构如何变化,其实现目前来说总是脱离不了如下几层:

核心:从上到下依次 1.暴露出来的业务服务接口 2.可选协议的(集群)远程调用3.封装好的网络通讯。

周边:1.服务接口配置管理 2. 服务治理及监控

外在框架其实会把服务接口这一层给讲明白了,同时附带了周边的内容。那么我们就详细看下其具体的分层结构及相互关系:

image

dubbo,框架的10层中分别提供了各自需要关心和扩展的接口,且可灵活的替换对接而不受影响。我们就只将核心的层进行下说明,其他层可以根据官方文档去理解,我们知道核心就是RPC调用及通讯,protocol 就是最核心的那一层,当然我们还要关心集群的实现以及网络通讯。

protocol: 封装了RPC调用,以Invocation和Result为中心,扩展接口为Protocol、Invoker和Exporter。Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠扰,或转换成它,它代表一个可执行体,可向它发起invoke调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。

transport:抽象mina和netty为统一接口,以Message为中心,扩展接口为Channel、Transporter、Client、Server和Codec。可通过hession,dubbo协议进行序列化通信。

然后我们来看下远程调用的详细过程:

image