drools规则引擎技术指南_银行核心系统|应用架构与技术栈

f6dc185cc207446c05d5fa16db4015ef.png

软件架构(software architecture)是一系列相关的抽象,用于指导大型软件系统各个方面的设计。

本文将接着上两篇继续聊聊应用架构中的一些抽象的案例。

此文适合人群:

银行从业人员,企业架构师,系统架构师、软件工程师。

此文解决问题:

应用架构的概念、分层、抽象

银行应用架构技术栈

此文分为四部分:

一、产品与服务抽象

二、产品服务分层

三、架构中的一些抽象概念

四、银行应用架构技术栈

1

产品与服务抽象

金融服务是银行业以产品为载体实现企业价值的过程。对银行产品的抽象是为了实现:

  • 通过分层实现对上层应用隐藏其实现细节,当然这一点在很多开发框架也是如此,如:jdbc、spring-mvc、tomcat容器等

  • 通过拆解打破对某一具体实现的依赖,实现系统稳定部分与多变部分分离、关键业务与非关键业务分离

  • 通过内涵和外延方面抽象,将银行产品分为可售产品和基础产品

  • 通过对系统构建过程抽象,实现产品、流程进行标准化、组件化、参数化提升系统的灵活性

  • 通过抽象和接口,减少依赖关系提升业务代码的复用能力。

2

产品服务分层

客户、渠道、产品、团队这四个要素是一个金融服务从创意到交付给客户的4个维度。

95132cbd28b348331f3278b58f3440ae.png

对公客户、个人客户通过场景接到渠道提供金融产品服务。至于为什么像上图一样进行分层,与当下银行内部的组织架构有关,因为组织架构不同导致系统是不同业务部门发起的,建设过程多是相互独立的,因此对公业务和个人业务是分属不同领域的。渠道A和渠道B销售的产品是有区别的,这里的产品是产品工厂中可售产品的概念,是基于基础产品二次封装。

★名词解析

可售产品:银行对外进行销售和经营的产品,是从客户角度看到的产品,也是从经营角度看到的产品。

基础产品:是标准产品,是银行内部视角对一组服务功能和业务处理规则基本相近的可售产品进行共性聚类和去差异化的产物。

当然上面的抽象未考虑组织影响因素,特别是团队的组织形式影响着系统架构的设计,如果想了解组织对架构的影响可以搜索下康维定律,或读一读阿里右军的文章《从康威定律和技术债看研发之痛》

★名词解析

康威定律:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。

通俗一点说就是组织影响着系统设计。

3

架构中的一些抽象概念

在架构设计过程中经常会遇到一些名词:模式、框架、 平台、应用、组件、中间件、服务,有时让人傻傻分不清楚。

  • 设计模式:Design Pattern是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式的目的:为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。

    设计模式是代码级的复用

  • 框架:Framework,是为了实现某个业界标准或完成特定基本任务的软件组件规范,并提供规范所要求基础功能的软件半成品,需要二次开发。框架在架构设计上遵循依赖倒置原则,高层模块不依赖于底层模块。

    框架是具有基础结构和帮助快速构建应用的工具和指南,是一个软件的半成品,是跨团队、跨团公司、跨行业的软件复用,如Spring、MyBatis

  • 组件:Component是一组为了某一目的聚合的功能和数据封装,组件分为应用组件和技术组件,应用组件交付业务功能,技术组件交付与业务无关的基础支撑功能。

    组件是功能级别的复用

  • 服务:Service是为达到某一目标,服务提供方与服务消费方按照约定好的服务规约进行交互。

    服务是基于契约的面向业务服务和数据服务级别的复用用

  • 应用:Application是可执行程序,运行时提供业务功能,应用的数据持久化到持久层如:数据库、文件等,应用和数据是分离的。

    应用是业务功能、流程及其操作角色级别的复用

  • 平台:Platform是一组技术,用作开发其他应用程序,流程或技术的基础。在国内平台掺杂了技术和业务的概念,从技术上看平台是为上层应用提供基础硬件(计算、内存、网络、存储等)或API操作的基础服务,如现在的XaaS可以认为是不同的平台,业务平台概念就比较广泛了,涉及到了对企业业务的封装形成的以解决领域问题为核心逐渐演化的半成品。

    平台是企业级跨组织协同的复用

4

银行应用架构技术栈

553958e7566e8f477dfc9e215d0eb100.png

# 应用架构技术栈

## 基础框架

### Spring

- Spring3/4/5

- Springboot

- SpringCloud

### ORM

- MyBatis

- IBatis

- Hibernate

### JDBC

- Druid

- dbcp

- c3p0

### IO框架

- Netty3/4

- Mina

### RPC

- Dubbo

- grpc

- HttpClient(Restful)

- SpringCloud(算是基于springboot的rpc吧)

### 熔断隔离

- Hystrix

- Sentinel

### 注册中心

- Zookeeper

- redis

### 序列化

- FastJson

- Hessian

- Protobuf

### 日志

- Log4j2

## 技术组件

### API网关

- NGINX

- ZUUL

### API管理

- RAP

- Swagger

### 文件网关

- Ceph

- secGateway

### 规则引擎

- Drools

- FICO blaze 

- IBM iLog

-  Sparkling Logic

### 服务总线

- Oracle OSB

- IBM WebSphere ESB

- Mule

### 日志平台

- EFK

- ELK

### 监控平台

- Zipkin

- SkyWalking

- CAT

### 会话共享

- SpringSession+Redis

### 配置管理

- Apollo

- spring-cloud-config

- disconf

- diamond

### 分布式锁

- Redis

- Zookeeper

## 功能框架

### 消息中间件

- RabbitMQ

- RocketMQ

- Kafka

### 任务调度

- ElasticJob

- Quartz

- Spring Batch

### 缓存

- Redis

- Memcached

### NoSql数据库

- MongoDB

### 关系型数据库

- Oracle

- Mysql

- Postgresql

5

小结

本文是应用架构的第三篇,在后面几篇将以不同的视角、视图来介绍银行应用架构,请关注公众号,新的文字不日即可到达。

参考资料:

《企业信息化总体架构》

《银行信息系统架构》

《产业互联网——构建智能+时代数字生态新图景》

《从康威定律和技术债看研发之痛》

推荐阅读:

  1. 银行核心系统|应用架构与案例介绍(中)

  2. 银行核心系统|应用架构与案例介绍(上)

  3. 银行核心系统|企业架构那些事

  4. 银行业务架构与同业案例(超详细)

  5. 核心银行系统之开放服务、清算、核算体系

  6. 银行核心系统之账户体系

  7. 银行核心系统之互联网开放平台

  8. 每个人都该了解的互联网银行中台

  9. 到底什么才是银行业务架构?

- End -

87c3e7017577db284b62f3dc3218a922.png

若需深度交流,请加入【金融技术架构群】微信群,当前微信群人数较多,请添加群助手微信:zhushou_003

984fa31cae2129af303ee5dba7e2f5e3.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值