某金服银行存管分布式架构设计

 

1架构总览

此架构支撑的业务是  一天10G的日志处理，100个左右的QPS

##业务流

业务订单表设计

CREATE TABLE `biz_order` (
  `tid` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `biz_id` varchar(100) NOT NULL DEFAULT '' COMMENT '业务订单编号',
  `type_no` varchar(50) NOT NULL COMMENT '业务类型',
  `user_id` bigint(20) NOT NULL COMMENT '用户userId',
  `object_id` int(11) NOT NULL COMMENT '业务对象ID',
  `request_status` tinyint(4) DEFAULT NULL COMMENT '存管通状态1.待发起指令 2.发起指令 3.委托成功 4.不需要调用存管通  5.处理成功 6.处理失败 ',
  `biz_is_success` tinyint(4) NOT NULL DEFAULT '1' COMMENT '业务处理结果 1.等待处理 2.处理中  3.处理成功   4.处理失败  5.已取消',
  `in_json` text NOT NULL COMMENT '传入参数json传',
  `out_json` text COMMENT '输出参数json传',
  `version_no` tinyint(4) NOT NULL DEFAULT '1' COMMENT '版本号',
  `biz_level` tinyint(4) NOT NULL COMMENT '业务级别',
  `sort_no` tinyint(4) NOT NULL COMMENT '骤编号，顶级为-1',
  `parent_tid` bigint(20) DEFAULT NULL COMMENT '父级业务ID',
  `request_id` varchar(100) DEFAULT NULL COMMENT '存管接口订单号',
  `date_seriano` int(11) NOT NULL COMMENT '日期字符串',
  `redirect_url` varchar(100) NOT NULL COMMENT '回调地址',
  `create_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后更新时间',
  PRIMARY KEY (`tid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='业务订单表';

存管订单表设计

CREATE TABLE `cgt_request_order` (
  `tid` bigint(20) NOT NULL DEFAULT '0' COMMENT '主键',
  `request_id` varchar(100) NOT NULL COMMENT '存管接口订单号',
  `biz_id` int(11) NOT NULL COMMENT '业务对象ID',
  `type_no` varchar(50) NOT NULL COMMENT '业务类型',
  `request_is_success` tinyint(4) NOT NULL DEFAULT '1' COMMENT '存管通状态 1.发起指令 2.委托成功 3.处理成功 4.处理失败 5.已取消',
  `key_value` text NOT NULL COMMENT '输入参数json传',
  `return_value` text COMMENT '输出参数json传',
  `version_no` tinyint(4) NOT NULL DEFAULT '1' COMMENT '版本号',
  `bank_no` tinyint(4) NOT NULL COMMENT '存管银行1.厦门银行',
  `date_seriano` tinyint(4) NOT NULL COMMENT '日期字符串',
  `row_num_sum` int(11) DEFAULT NULL COMMENT '数据行数',
  `redirect_url` varchar(100) NOT NULL COMMENT '回调地址',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后更新时间',
  PRIMARY KEY (`biz_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='存管订单表';

2 日志纪录

Flume+elastic-search-----

3 密钥管理

放入DB中，缓存redis----ok

4 外部api接口管理

切换银行,接口升级-----ok

放入db中，缓存redis。

5 数据一致性保证

异步补偿,定时补偿,增加事务纪录表

6 异步通知接口需保持幂等

接收外部的异步通知接口必须支持幂等

通过数据库唯一性约束保证。

7 定时对账-业务补偿

走任务调度中心

一般来说是实时，如果业务处理速度跟不上，业务量大的功能10分钟补一次单，业务量小的1分钟补一次单

7 外部接口监控

定时探针测试。-----测试环节

 

架构演进

单体架构
SOA
微服务

 

单体架构

一个归档包包含了应用所有功能的应用程序， 我们通常称之为单体应用。 
架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风格。

 

单体架构的缺点

  复杂性逐渐变高
  技术债务逐渐上升
  部署速度逐渐变慢
  阻碍技术创新
  无法按需伸缩

 

SOA

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

 

##分布式系统优点

- 1:把模块拆分,使用接口通信,降低模块之间的耦合度.

- 2:把项目拆分成若干个子项目,不同的团队负责不同的子项目.

- 3:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

- 4:可以灵活的进行分布式部署.　　

- 5:提高代码的复用性,比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android，ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

##分布式系统缺点
系统之间的交互要使用远程通信,接口开发增大工作量

 

微服务

 

  微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。

  其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。

  这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。

  这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。

  对这些微服务我们仅做最低限度的集中管理

 

 

微服务特点：

 

  1. 每个微服务可独立运行在自己的进程里；
  2. 一系列独立运行的微服务共同构建起了整个系统；
  3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
  4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

 

微服务优点：

 

  易于开发和维护
  启动较快
  局部修改容易部署
  技术栈不受限
  按需伸缩
  DevOps

 

 

微服务挑战

 

  运维要求较高
  分布式的复杂性
  接口调整成本高
  重复劳动

 

 

微服务设计原则

  单一职责原则
  服务自治原则
  轻量级通信原则
  接口明确原则