基于微服务和中台架构的华宇第三代智慧审判系统架构设计

随着国内社会经济发展以及法院立案登记制的推行，近年法院案件量成几何级暴增，对于智能化审判系统的需求也比以往任何时候都要急切。

背景

伴随着对卷宗深度应用、全流程无纸化的要求，案件相关的电子材料越来越多，单个案件相关电子材料动辄几百兆；然而，随着法官员额制改革的完成，实际办案法官并未随案件量同步增长，法院要切实提高办案效率，必须实行精细化分工，办案系统也必须做得更加专业化、智能化；在面向社会诉讼参与人（当事人、律师等）的诉讼服务方面，最高人民法院也对全国法院提出司法便民，阳光司法等越来越高的要求，法院有越来越多的互联网化和移动化的需求；随着国家信创战略的推行，政法部门首当其冲要进行软硬件系统“信创化”更新改造。

下面是中部某省份近 10 年案件量的一组统计数据，可以看到该省近 10 年来案件量基数已超千万件，近 5 年增长率基本稳定在 30%左右。

图 1 中部某省份近 10 年案件量趋势

图 2 中部某省份近 10 年案件增长率

现状分析

目前，法院审判系统架构，主要有如下两种情形：

情形一常见于不同厂商构建不同场景应用，应用间通过数据导入导出的方式共享业务数据，其数据时效性、准确性都是问题。

情形二常见于同一厂商构建的不同场景应用，应用间通过共享同一个数据库实例共享业务数据，应用间互相影响，业务应用难以独立变更。

以上分析可以看到现状主要有以下三个特点：

• 单体应用服务：业务模块耦合，牵一发动全身

• 单体数据库：压力大、系统运行慢，难以扩容

• 烟囱式：应用间共享数据时效差、容易不一致

随业务发展趋势而来的是对现有系统架构的各种挑战：

单体数据库、单体应用服务性能问题：月底结案高峰期数据库负载高，应用卡死；

性能扩展困难：现有审判系统基本都已有 10 年历史，设计上并没有做太多性能扩展上的考虑，有些系统因为使用内存缓存等有状态特性甚至不支持集群部署；

带宽及存储压力：集中存储性能无法满足业务运转，案件卷宗系统省级集中部署，下级院制卷、阅卷速度慢（网络带宽及延迟），若改为各中级法院分别部署的形式，速度会有提升，但法院间数据共享困难，部署升级等运维工作量大（1 变 10）；

业务扩展困难：场景应用不断增多，个性化需求愈发强烈，单体应用各业务交织在一起，牵一发动全身，无关业务也需要升级，不够灵活，程序修改容易引入新缺陷。随着落实诉前调解、繁简分流、简案速裁、简案快审等新机制的要求，对快速构建新场景新应用的诉求会越来越强烈；

业务复用困难：更多的互联网端和移动端需求，现有架构需要从数据底层开始全新构建应用，无法复用现有业务。

要应对以上挑战，必须在系统架构上做一次大调整了。

华宇第三代审判系统新架构

华宇第三代审判系统（T3）涵盖法院各大核心业务系统，包括立案、办案、执行、庭审、审管、诉讼、卷宗等。

进一步分析业务需求，我们发现：虽然应用场景不断增多，但办案的底层业务逻辑基本是不变的；案件实体信息相对固定，只是操作的人不同和操作方式的增加；案件处理逻辑（分案、审限、信息项校验关系等）基本不变。频繁变化的是面向不同场景的功能组合方式和分工细化后的系统功能深度。于是明确了我们的架构改进方案：

应用方面：业务上纵向拆分，适应细化分工的要求，技术上横向分层，通用业务逻辑下沉为业务服务，供不同场景复用，同时保持场景应用轻薄以快速响应变化。应用服务无状态化，支持集群横向扩容；

数据库方面：随业务服务对数据做纵向切分，分布式部署分散压力；横向上对业务大表执行水平切分，控制表文件的规模。使用数据库分区表特性，根据各表数据的所属法院字段对数据做分区，一个省含 100 家以上法院，此条件可做到将整表数据切为上百个分区，每个分区会存储为单独的文件，可达到水平切分数据目的。根据数据量估算，以最大的民事案件为例，十年内案件表可达约 1500 万拆分后平均 15 万/分区，当事人表约 5000 万，分区后平均 50 万/分区，每个分区数据量不大，在目前主流服务器硬件支撑下完全可以做到对分区高速检索。须注意的是必须在每次访问数据时带上分区检索条件。

文件存储方面：使用分布式存储方案，文件就近存取，分散存储及带宽资源压力。

通过图 8 可以看到，最终形成的架构是微服务化的，从业务角度对服务做分层，实现通用业务逻辑的服务（红框部分）恰好符合近两年炒的火热的“业务中台”概念。

T3 最终采用的即是微服务+中台架构，使用 spring cloud 技术栈实现。整体架构从上至下依次划分为四层：场景应用层、法院业务中台（业务服务层）、基础支撑层、基础设施层。

图 9 总体架构

场景应用层：采用前后端分离开发模式，前端为静态页面，独立部署，与后台通过 HTTP(S)接口通信，保证前端可以按不同客户的喜好定制，独立演化。后端服务不保存用户在线状态，采用基于 JWT 的身份验证技术。前端应用基于 Vue 框架配合公司自研的 Artery6UI 控件集开发。

业务中台（业务服务层）：沉淀通用业务逻辑的所有业务服务，按照业务维度进行服务拆分，目前有大量的业务微服务（目前 40+），所有服务由服务治理平台管理。

基础支撑层：一些法院业务无关的、偏通用技术的服务，为上层业务服务提供通用技术支撑。

基础设施层：使用华宇容器云平台（ArteryDocker，基于 K8S）作为系统运行基础设施，对上层屏蔽服务器硬件设备和操作系统等运行环境差异，同时为 CI/CD 提供基础能力。

这里再介绍一下服务治理平台的实现，平台包含对微服务的注册与发现、接口网关、调用跟踪（Sleuth+zipkin）、限流熔断、服务间负载均衡等多方位治理。线上可以通过统计图表来分析应用的实际压力和慢请求等情况。通过服务治理平台的服务依赖分析功能可识别服务间依赖关系，控制服务之间的耦合度，可以查询任意一个服务依赖调用的服务已经它被调用的情况，可以精确到接口路径上。接口网关具备 RESTful 接口字段级授权能力、内部 MQ 消息可转 Webhook。

图 10 服务间依赖关系

图 11 接口网关授权

分布式文件存储服务技术选型为 minio，以每个部署地为一个节点，即每个中院+高院各放一个存储节点，存取文件时走前端路由组件指向不同存储节点。

图 12 分布式存储架构

针对智能化、移动化、信创等需求，分别形成智能化底层（睿元、睿核、智核、智链）、移动平台（移动开发框架 HAPP、移动门户宇雀）和信创支撑平台等技术平台（技术中台）。

图 13 技术中台

随着服务数量增多，研发及生产环境部署、运维成本大增，仍然使用纯人工操作成本太高，于是我们适时引入了 CI/CD、服务监控、日志收集、自动伸缩等 DevOps 自动化技术。

CI/CD 使用 jenkins 流水线驱动。

图 14 CI/CD 流水线

日志收集使用 ELK 技术栈，每个服务在编排中都内置一个 filebeat sidecar，用于服务日志文件读取，然后将应用的日志数据推送到 ES 中。在 kibana 中可以通过应用名称、日志级别、时间、线程信息、日志内容等属性去高效的检索日志，还可以通过图表直接分析各个服务的错误日志以定位问题。

服务监控使用 SpringBootAdmin 和 Prometheus+Grafana，收集微服务多维度监控指标收集微服务多维度监控指标，监控主机资源使用情况并且在资源到达阀值时预警，读取微服务健康状态指标并且在微服务异常时预警。

微服务使用华宇容器云平台的水平伸缩控制器（HPA）可弹性伸缩，通过设置 CPU、内存伸缩阈值和服务伸缩的最大、最小数量，当达到阈值时触发自动扩容，当压力下降到阈值范围一定时间后触发自动收缩。

新架构的落地实践效果

2020 年初，使用新架构构建的华宇第三代智慧审判系统（T3）在南方某省份正式落地运行。我们对近 4 个月的 400+条新需求实际交付效果作了一些分析了并和旧架构系统作了对比，虽然上线时间不算太长，但已经能看到新架构的实际成效有很大提高。

进一步对需求点按涉及修改服务层次进行分类，可以从另一个角度发现需求响应效率提升的原因：可以看到涉及到业务中台修改的需求只占 1/3，即，有 2/3 的情况是不需要中台服务修改发布更新的，这有效缩小了程序修改范围，同时可以保证已有业务的稳定性。

图 15 用户需求分布

另外，客户现场的实施部署工作也有了质的提升，截止当前，最多一次升级涉及 20+款应用，实施工程师 3 人在 30 分钟内升级完成，达到了预计效果（旧架构下升级 1 款应用就可能需要 30 分钟）。

作者介绍：

安玉兴，华宇软件大连公司软件架构专家，10 余年法律科技行业从业经验，8 年软件架构设计经验，华宇第三代核心审判系统总架构师。