合同管理系统技术架构（合同管理系统技术架构图）

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服务器，未包含在上面的资源推荐中。