合同管理系统技术架构(合同管理系统技术架构图)

合同管理系统技术架构(合同管理系统技术架构图)

HCBM 使用的开源组件

HCBM 完全基于开源产品打造。HCBM 的本身是使用 Spring Cloud 作为微服务架构,并使用了一些主流的开源工具进行DevOps及监控管理等。

合同管理系统技术架构(合同管理系统技术架构图)

1. 应用前端

HCBM 前端使用AntD Pro进行封装拓展。

核心组件有:

React:一个用于构建用户界面的 JavaSCRIPT 库。

AntD Pro:基于React的开箱即用的中台前端/设计解决方案。

Node.js:采用Node打包、构建前端应用

1. 微服务后端

HCBM 的微服务后端采用 Spring Cloud 作为微服务框架,使用 Spring Boot 作为开发脚手架。

核心组件有:

Spring Cloud:Spring Cloud 是一个集成了众多开源的框架,利用 Spring Boot 的开发便利性实现了服务治理、服务注册与发现、负载均衡、数据监控,REST API 发布方式等,基本囊括了分布式框架所需要的所有功能。是一套易开放、易部署、易维护的分布式开发工具包,如下是HCBM用到的一些Spring Cloud的组件:

合同管理系统技术架构(合同管理系统技术架构图)

合同管理系统技术架构(合同管理系统技术架构图)

Spring Boot:Spring Boot 是由 Pivotal 团队提供的全新框架,其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。

Mybatis:一款优秀的持久层框架,它支持定制化 SQL、存储过程以及高级映射。

其他常用工具:

合同管理系统技术架构(合同管理系统技术架构图)

合同管理系统技术架构(合同管理系统技术架构图)

3. 数据服务层

HCBM 采用 Mysql、Oracle、SqlServer 作为关系型数据存储库,Redis 作为缓存库。

核心组件有:

MySQL:Mysql 是最流行的开源关系型数据库管理系统。

Oracle:Oracle 是主流的企业级关系型数据库管理系统。

SqlServer:SqlServer 是主流的企业级关系型数据库管理系统。

Redis:Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。

4. 运行环境

5. HCBM 可运行在 Docker、VM、Server 上。

核心组件有:

Docker:Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。

6. 开发测试

HCBM 采用多个代码检查和测试工具,其中,JUnit、Spock 作为后端 Java 代码的测试工具;Selenium 作为前端测试的工具。

核心组件有:

JUnit:JUnit 是一个 Java 语言的单元测试框架。

Spock: Spock 是一个用于Java或Groovy应用的测试框架。

Selenium:Selenium 是一套完整的 web 应用程序测试系统,包含了测试的录制(selenium IDE),编写及运行(Selenium Remote Control)和测试的并行处理(Selenium Grid)。

系统监控

HCBM 利用主流的开源监控工具,从日志、服务运行环境、调用链等进行全面监控,以便在发生问题时能够快速定位和解决问题。

核心组件有:

Zipkin:Zipkin 为分布式链路调用监控系统,聚合各业务系统调用延迟数据,达到链路调用监控跟踪。

Grafana:Grafana 是一个开箱即用的可视化工具,具有功能齐全的度量仪表盘和图形编辑器,有灵活丰富的图形化选项,可以混合多种风格,支持多个数据源特点。

Promethues:Promethues 是由 SoundCloud 开发的开源监控报警系统和时序列数据库(TSDB)。

Micrometer:Micrometer 是一个监控指标的度量类库。

服务调用链路

基础服务之间的关系以及调用链路。

合同管理系统技术架构(合同管理系统技术架构图)

1. 访问网关、鉴权

API 访问 gateway 网关服务,所有请求都会经过 GateWayHelperFilter 过滤器,在过滤器中,会调用 gateway-helper 鉴权。

进入 gateway-helper,根过滤器RootServletFilter包含了一系列过滤器来对请求进行鉴权,将按图中的过滤器顺序进行校验,其中任何一步返回 false 都会直接返回。一般服务出现403、500等问题可先检查 hzero-gateway-helper 的日志,看是哪一步校验不通过。

权限校验通过后,携带 Jwt 返回到 gateway。

2. 获取用户信息

其中,GetUserDetailsFilter会带着 access_token 访问 OAuth 认证服务的 /api/user 接口获取用户信息,并转换成 CustomUserDetails。之后,在AddJwtFilter里将 UserDetails 转成 Jwt。

3. 访问API

权限校验通过后,gateway 会将请求路由到具体的服务上,并带上 Jwt。

在服务内,JwtTokenFilter 将 Jwt 解析成 CustomUserDetails,并放入 SecurityContextHolder,代表用户在这个服务内已经登录,之后的程序中就可以通过 DetailsHelper.getUserDetails() 得到用户信息。若要开启此过滤器,需在启动类上配置 @EnableChoerodonResourceServer 注解开启此功能。

之后返回数据,经过网关,再返回到前端。如果服务响应比较慢,就需要调整网关的超时时间。

4. 服务注册

服务启动时,会向 register 注册中心注册自己。服务注册成功后,hzero-swagger、hzero-config、hzero-iam 都会收到服务注册的消息,swagger 会刷新swagger文档信息,config 刷新服务路由,iam刷新权限。

5. 获取服务文档

swagger、config、iam 收到服务注册成功的消息后,会调用服务的 /v2/choerodon/api-docs 接口获取服务文档信息。

注意:拉取服务文档时,服务可能还未完成启动,默认配置会每隔30秒拉取10次,如果10次后都没拉取到文档,就无法刷新路由等信息了,需手动调用接口刷新。

6. 通知服务刷新配置

config 中,服务路由或配置创建成功后,会调用服务/choerodon/config接口通知服务刷新配置。

7. 服务向配置中心获取配置

服务收到通知后,再向配置中心拉取配置,gateway、gateway-helper 还会拉取路由信息。因此如果路由找不到时,检查表中是否有路由信息,没有可通过配置中心手动添加,再调用通知接口通知服务刷新路由和配置信息。

好未来合同项目相关

1. 对接方法

具体的字段和返回需要之后的接口文档。

之后这边会有一个swagger地址提供测试。

测试阶段,接口调用不涉及权限。但是生产机上会加上权限校验:

通过给定的长时间有效的 token带到请求头上来调用我们合同系统的接口。

合同管理系统技术架构(合同管理系统技术架构图)

a) 与造物神对接

i. 通过造物神现在提供的接口,获取其人员和组织的全量数据,在自己系统内部做比对,得到新增修改的数据(这个操作耗时比较长,所以会是一个定时任务,而且频率会尽量降低)。

b) 与采购系统对接

i. 采购系统将zip包的base64字符串,通过post方式将数据传入我们系统,我们直接将其创建为一份草拟合同。同时当发生错误的时候我们将返回特有的错误代码,这个在之后的接口文档中展现。

ii. 之后通过业务流程之后,将审批最终结果返回给采购系统。同样以json格式的post请求传过去信息。

iii. 采购系统接收到我们最终回传的数据,如果是被拒绝的审批,那么采购可以通过这个状态来判断是否可以修改,修改完毕之后还可以继续推送过来,我们将对这个合同进行修改之后推向OA。

iv. 如果我们返回的是审批通过信息,那么采购系统接收到数据之后,根据最终结果修改掉自身的合同数据。并且修改状态,然后自行向紫光获取扫描件。

v. 从采购过来的数据在我们系统从始至终不能修改,唯一的修改途径是通过我们暴露给采购的合同创建接口(如果存在,我们会修改数据,会有外围系统编号这么一个字段)。

c) 对接拓展系统

i. 暴露一个restful接口给拓展系统,其将合同数据以post请求传给我们,我们直接将其创建为一份草拟合同。所传的字段为合同业务标准字段和自身系统的个别特殊字段。同时当发生错误的时候我们将返回特有的错误代码,这个在之后的接口文档中展现。

ii. 之后通过业务流程之后,将审批最终结果返回给拓展系统。同样以json格式的post请求传过去信息。

iii. 拓展系统接收到我们最终回传的数据,如果是被拒绝的审批,那么拓展系统可以通过这个状态来判断是否可以修改,修改完毕之后还可以继续推送过来,我们将对这个合同进行修改之后推向OA。

iv. 如果我们返回的是审批通过信息,那么拓展系统接收到数据之后,根据最终结果修改掉自身的合同数据。并且修改状态,然后自行向紫光获取扫描件。

v. 从拓展过来的数据在我们系统从始至终不能修改,唯一的修改途径是通过我们暴露给拓展的合同创建接口(如果存在,我们会修改数据,会有外围系统编号这么一个字段)。

d) 与OA对接

i. 业务人员在前台点击按钮触发合同的审批操作。

ii. OA目前有已经有创建流程的接口,所以我们通过目前OA已有接口推送合同信息给OA,OA返回相应的请求状态。

iii. OA在每一个节点审批完毕之后,通过我们发布的接口,以post的方式以json格式,将每个节点的审批结果推送过来。包含合同表单信息,审批备注,审批人,审批操作(同意或者拒绝),是否结束,审批时间。

iv. 每个节点审批完毕之后我们会记录审批日志。全部节点完毕之后,我们会将信息推送给采购和拓展。

e) 与钉钉对接

i. 与钉钉对接是通过造物神提供的钉钉消息推送接口来发送消息。

ii. 这方便主要是向其推送预警信息。

f) 与天眼查对接

i. 与天眼查对接,通过天眼查提供的工商信息和司法信息接口,根据公司名称查找其信息,然后展示成一个弹框给用户看。

ii. 字段信息由法务需求人员提供,但是我们目前只能展示一些重点信息。

iii. 然后在框中会有一个详情按钮,在点击详情按钮的时候会在浏览器打开一个新建的标签页,这样可以更仔细的查看信息。但是这个需要用户事先登录好天眼查系统。

2. 统一认证

合同系统将接入造物神的统一认证,不再与另外的系统单独做单点登录。

合同管理系统技术架构(合同管理系统技术架构图)

4. 高可用方案

合同管理系统技术架构(合同管理系统技术架构图)

a) 使用SpringCloud的zuul网关,可以通过部署多个网关服务集群 nginx反向代理来实现高可用。

b) eureka服务注册中心可以注册多个同名服务,这时zuul中通过路由的配置取得服务名,通过服务注册中心可以找到一个当前可用的服务。EurekaServer支持建立集群,来实现注册中心的高可用。

c) 数据库层面,我们可以通过配置多台数据库服务器来做互为主从,可以采用keepalive来实现高可用,当一台服务器挂了之后,另外一台检测不到心跳就会接管虚拟IP的请求。同时建议提供异地冷备机器,定期做好数据备份。

d) 如果考虑到高可用,那么正式环境服务器建议参考如下配置

合同管理系统技术架构(合同管理系统技术架构图)

5. 备注

a) 部署方式可为jar部署或者容器部署,如果直接使用jar包部署,则猪齿鱼不需要安装

b) 服务器与服务器之间为快速提供扩容能力,建议不做精确端口管控,尽量可以暴露一段端口;外部到服务端口限制根据实际需求而定

c) 正式环境配置只是建议,具体可能需要根据实际使用情况和部署要求调整

d) CPU、内存、硬盘等,只要综合资源满足要求即可,服务器数量没有限制。如用户量增加,可以通过增加同名服务的方式来增强并发能力。

如果要重启某个服务,可以通过Jenkins,或者使用后台脚本自行启动

合同管理系统技术架构(合同管理系统技术架构图)

e) Jenkins建议使用目前已有的jenkins服务器,未包含在上面的资源推荐中。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年11月24日 上午8:37
下一篇 2022年11月24日 上午8:40

相关推荐