以LIS为突破口的全栈信创实践——浙江省人民医院多院区多活架构建设样本

作为浙江省卫健系统信创“领头雁”，浙江省人民医院（下称“浙人医”）从LIS系统切入,实现从单系统突破到全栈国产化的跨越式发展。依托金仓数据库搭建的异构多院区多活数据底座，该院实现4大院区数据互相双向同步，灾容恢复能力达到6级标准，业务连续性达到99.99%，数据调用效率提升60%。浙人医的实践不仅为浙江省卫健行业信创规划提供了可复制的实践样本，更为多院区集团化医院信创建设探索出了一条以点带面、循序渐进的道路。

破局起步——集团化医院的信创突破口选择

浙人医是浙江省规模最大、实力最强的综合性三甲医院，拥有朝晖、望江山、越城、富阳四大已运行院区，滨江、萧山两个在建院区及全面托管的八家分院，横跨杭州绍兴两地。庞大的体量与业务规模，使其成为省内卫健系统信创试点的核心选择。

医院的核心信息系统若长期依赖国外数据库与硬件设备，不仅面临“卡脖子”风险，更难以满足医疗数据隐私保护、业务连续运行的高要求。在政策要求和业务需求的双重推动下，浙人医信息化团队借助越城院区建设启动信创。

相较于单一院区医院的信创改造，浙人医作为多院区集团化医院，其信创建设面临着更为复杂的挑战：各院区、业务系统之间数据兼容互通难度高；信创改造期间各院区需要保持互联互通能力，业务连续性要求高；考虑到跨院区跨城市之间的异地协同需求，数据库还需支持异构同步双写并行、多院区互为灾备、多院区负载均衡等容灾能力。

在反复论证与风险评估后，浙人医最终选择LIS系统作为信创建设的首个攻坚目标，背后有三层考量：

1、业务重要性突出

LIS是医疗核心系统之一，是连接检验科室与临床科室的数据桥梁，其效率高下患者体感明显；

2、数据规模适中可控

LIS系统支撑全院日均2万余个标本的处理需求，业务体量适中，应用场景集中，影响范围可控；

3、可复制性强

LIS业务覆盖面广，与院内其他业务系统和仪器设备均有对接，迁移经验可形成先易后难、逐步推广的良性循环。

金仓赋能——异构多活构建极致容灾

浙人医信息化与人工智能部副主任范玉林介绍，医院将产品成熟度、与原有Oracle数据库的兼容性、易上手、易运维等作为数据库选型重点，最终选定金仓数据库。

医疗行业业务逻辑异常复杂，厂商对于业务场景的理解深度尤为关键。金仓数据库在医疗场景适配经验丰富，已经服务301医院云HIS系统、陕西西京医院PACS系统、常德二院全栈国产化信创等项目，在医疗行业蝉联国产数据库销量榜首。此外金仓数据库作为一款多模、多场景数据库，同时满足多种数据库改造需求，可实现技术栈收敛。依托多语法原生兼容和SQL、PLSQL反向兼容服务，无需大量修改代码。凭借出色的产品力和本地化团队带来的优质服务，浙人医和电科金仓达成合作，开启了浙人医LIS系统信创攻坚。

多院区集团化医院信创改造过程在面临传统医疗机构固有难题的同时，还需满足不同院区之间的数据同步和协同，对于双向双写和灾备能力提出极高的要求。医院信息系统灾难恢复能力6级标准要求医疗机构做到数据零错误丢失（RPO=0），从故障发生到系统完全恢复时间（RTO）小于10分钟，传统的灾备架构很难实现这样的需求。

浙人医在开启LIS系统信创时拥有越城、朝晖、望江山三个院区，此前LIS系统业务均由越城院区主系统承载，系统压力大，院区间如遇网络中断需要手动拉起灾备系统，RTO不可控。在LIS系统的国产数据库迁移过程中，浙人医联合合作伙伴制定技术方案，实现了如下四大技术创新：

1、异构组网

信创完成后，金仓数据库成为新的业务承载主力，原非信创数据库依旧保持活跃，双轨同步运行；

2、多活容灾

引入多活容灾架构，多院区互为灾备，支持多院区间的负载均衡和多活容灾，横向拆分多院区压力，故障发生时无需手动拉起灾备系统，帮助医院实现RTO≤10min、RPO=0的容灾目标；

3、多写同步

基于业务存量数据校验技术和增量数据校验技术，各数据中心通过KFS工具实现环状数据同步，进一步提升容灾能力；

4、卫星方案

小型院区重要工作位置布置轻量化卫星站，通过小型化节点保留核心功能，减少网络依赖，提升应急能力。

在数据迁移阶段，浙人医采用了电科金仓双轨并行、分阶段推进方案保障平滑切换：迁移至金仓数据库之后，原有非信创系统作为备用数据库保持活跃，遇有突发情况可随时切换回原系统。系统上线前浙人医还围绕故障应急进行了多轮演练，模拟Oracle主库故障切换到国产库、国产数据库集群故障自动转移、国产数据库单边故障、Oracle单边故障、院区网络中断国产数据库与Oracle各自独立运行、关闭部分服务器模拟硬件故障等多种场景，确保系统切换万无一失。

在电科金仓的支持下，2023年10月，浙人医完成LIS系统国产化适配；2024年4月同步完成双活+应急方案系统改造并完成程序更新，在越城院区国产数据库实际环境测试应用，5月正式在越城院区上线。目前浙人医LIS系统已经在越城、朝晖、望江山、富阳院区实现互相双向同步，成为国内首个LIS国产化异构数据多院区多活改造案例。

以点带面——全栈信创的浙江样本

LIS系统在多院区的成功落地，为浙人医信创建设的全面推进奠定了基础，其信创版图持续扩张。走进今年新启用的浙人医富阳院区，这个全省首个医疗全栈信创样板间集中展现国产生态的成熟度：服务器操作系统涵盖麒麟、统信、龙蜥、欧拉等；桌面操作系统以中科方德、统信为主；金仓数据库作为国产生态的重要一环，为富阳院区核心业务系统提供数据底座支撑。

浙人医的信创实践并非单点作战，而是深度契合浙江省健康云建设规划。在富阳院区的建设中，浙人医和浙江省健康云有限公司达成深度合作，富阳院区信息机房在本地建设，作为健康云的计算节点和容灾中心之一；医院按需从健康云购买服务。依托富阳院区的原生云生态，院区HIS、EMR、LIS、PACS等业务系统均已实现云化部署。

富阳院区试运行以来，系统每小时访问量达40多万次，数据库IOPS（每秒读写操作数）达到1万以上。与原系统相比，数据调用时间平均缩短了0.8秒，效率提升了60%。业务高峰时，系统响应延迟时间≤0.3秒，为患者和医护人员提供了更高效、更快速的服务体验。

项目介绍——浙江省人民医院LIS系统

基本情况

浙江省人民医院是浙江省卫生健康委直属的大型综合三甲医院，是国家区域医疗中心综合类别共建单位，作为浙江省内规模最大，集医疗、科研、预防、保健等为一体的大型综合性三甲医院，连续多年名列全国综合性医院前列，年门急诊220万人次+、住院近13万人次、手术近7万台

业务情况

该院LIS系统主要面向多个院区，提供智能采集、智能常规检验、智能前处理、智能质控管理、报告查询、BI数据分析等功能模块

用户痛点

痛点一

用户担心国产数据库难以兼容Oracle语法及主要功能

痛点二

原LIS系统采用Oracle数据库支撑所有院区服务，用户担心一旦发生故障将造成所有应用停止服务，存在故障风险

痛点三

用户反馈原Oracle数据库灾备方案不完善，一旦发生故障需要手工切换网络和应用，RTO恢复时间不可控

解决方案

1、KES数据库原生兼容Oralce数据库语法及功能
2、KES主备高可用集群提供高可用保障，分担望江山和越城院区业务负载，降低整体系统压力
3、KES+KFS的多活容灾方案提供灾备能力的同时，保证在异构数据库之间的数据实时一致，一旦发生故障，应用无感切换

KES + KFS 多活容灾：代码示例与自动化脚本

1) 兼容性扫描 & 简单 SQL 方言翻译器（Python）

# file: sql_compat_checker.py
# 目的：扫描 SQL/PLSQL 文件，检测可能的 Oracle 专有特性，并尝试做简单的语法替换。
import re
import json
from pathlib import PathORACLE_PATTERNS = {
'SYSDATE': r'\bSYSDATE\b',
'SYSTIMESTAMP': r'\bSYSTIMESTAMP\b',
'NVL': r'\bNVL\s*\(',
'DECODE': r'\bDECODE\s*\(',
'ROWNUM': r'\bROWNUM\b',
'SEQUENCE_NEXTVAL': r'\b(\w+)\.NEXTVAL\b',
}REPLACEMENTS = {
r'\bNVL\s*\(': 'COALESCE(',
r'\bSYSDATE\b': 'CURRENT_DATE',
r'\bSYSTIMESTAMP\b': 'CURRENT_TIMESTAMP',
}def scan_file(path: Path):
text = path.read_text(encoding='utf-8', errors='ignore')
findings = []
for name, pat in ORACLE_PATTERNS.items():
if re.search(pat, text, re.IGNORECASE):
findings.append(name)
return findings, textdef attempt_translate(text: str):
for pat, repl in REPLACEMENTS.items():
text = re.sub(pat, repl, text, flags=re.IGNORECASE)
return textif __name__ == '__main__':
root = Path('sql_sources')
report = {}
for p in root.rglob('*.sql'):
finds, txt = scan_file(p)
translated = attempt_translate(txt)
report[str(p)] = {'issues': finds, 'translated_snippet': translated[:800]}
print(json.dumps(report, indent=2, ensure_ascii=False))

说明：该脚本用于 PoC 阶段快速识别 Oracle 关键语法并尝试自动替换。正式迁移需扩展规则库并加入语法解析（推荐使用 ANTLR / sqlparse）以及人工审核流程。

2) PL/SQL 特性检测脚本（shell + Python）

# file: detect_plsql_features.sh
# 目的：快速列出包含 PL/SQL 区块的文件，便于迁移优先级排序
find sql_sources -type f -name "*.sql" | while read f; do
if grep -qi "PROCEDURE\|FUNCTION\|PACKAGE\|TRIGGER\|BEGIN\|EXCEPTION" "$f"; then
echo "PLSQL_BLOCK: $f"
fi
done

可配合上面的 Python 脚本，输出到 CSV，供 DBA 审核。

3) CDC 消费与幂等应用示例（Python，伪代码）

# file: cdc_consumer.py
# 假设 KES 提供 binlog/redo 订阅接口，或通过 Kafka/消息队列输出变更。
import json
import requests# 伪函数：从 KFS 或消息队列消费变更事件
def consume_events():
# production: 通过 Kafka consumer 或直接通过 KFS gRPC/HTTP API
yield from []# 应用变更（幂等）
def apply_change_to_local(db_conn, event):
# event example: {gtrid, lsn, op, schema, table, pk, data}
# 1) 去重
if already_applied(db_conn, event['gtrid']):
return
# 2) 按 op 执行
if event['op'] == 'INSERT':
# 使用 upsert 来保证幂等
upsert(db_conn, event)
elif event['op'] == 'UPDATE':
update(db_conn, event)
elif event['op'] == 'DELETE':
delete(db_conn, event)
# 3) 记录应用事务 id
mark_applied(db_conn, event['gtrid'])# 伪实现def already_applied(db_conn, gtrid):
# 查询本地变更表
return False# 主循环
if __name__ == '__main__':
for ev in consume_events():
# 事务边界保证：按 gtrid 顺序处理
apply_change_to_local(None, ev)

要点：消费端必须实现去重（基于全局事务ID）、幂等的 upsert 操作、事务边界处理，以及失败重试/幂等回放。

4) KFS 同步应用伪代码（冲突检测策略示例）

# file: kfs_conflict_resolver.py# 简单策略：按 (last_write_ts, source_priority) 决定胜者def resolve_conflict(local_row, incoming_row):
if incoming_row['last_write_ts'] > local_row['last_write_ts']:
return incoming_row
# 若时间相同，按源优先级（配置化）
if incoming_row['source_priority'] > local_row['source_priority']:
return incoming_row
return local_row

实际生产环境建议：提供可插拔的冲突策略引擎（业务规则、字段级合并、人工仲裁回调）。

5) 主备监控与自动切换（思路 + 示例脚本）

# file: ha_monitor.sh
# 目的：周期性检测本节点健康，触发选主 API（示例）
API_ENDPOINT="http://127.0.0.1:8080/health"
LEADER_API="http://cluster-control.local/elect"status=$(curl -sS --max-time 2 $API_ENDPOINT || echo "DOWN")
if [ "$status" != "ok" ]; then
# 通知集群控制平面发起重新选主
curl -s -X POST $LEADER_API -d '{"failed":"$(hostname)"}'
fi

**注意：**生产环境建议使用成熟选主协议（etcd/consul/raft）或数据库内置的选主机制，并配合 L4/L7 代理（如 HAProxy、ProxySQL）做流量切换。

6) KES Kubernetes StatefulSet（示例）

# file: kes-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: kes
spec:
serviceName: "kes"
replicas: 3
selector:
matchLabels:
app: kes
template:
metadata:
labels:
app: kes
spec:
containers:
- name: kes
image: kesdb/kes:stable
ports:
- containerPort: 1521
env:
- name: KES_NODE_ROLE
valueFrom:
fieldRef:
fieldPath: metadata.name
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
volumeMounts:
- name: kes-data
mountPath: /var/lib/kes
volumeClaimTemplates:
- metadata:
name: kes-data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 200Gi

**建议：**为不同院区部署 nodeAffinity、podAntiAffinity、并使用网络策略与专线互联以降低跨机房复制延迟。

7) Prometheus AlertRules 示例（复制延迟 & 选主时间）

# file: prometheus_alerts.yaml
groups:
- name: kes.rules
rules:
- alert: KES_Replication_Lag_High
expr: kes_replication_lag_seconds > 5
for: 30s
labels:
severity: critical
annotations:
summary: "KES 复制延迟过高"
description: "复制延迟 {{ $value }} 秒，可能影响 RPO。"- alert: KES_Leader_Election_Slow
expr: kes_last_election_seconds > 60
for: 10s
labels:
severity: warning
annotations:
summary: "KES 选主耗时过长"

8) 故障演练（Chaos）脚本示例

# file: chaos_drill.sh
# 模拟主节点进程挂掉 -> 观察自动选主与应用无感切换
set -e
TARGET_NODE=${1:-kes-0}
# 在 k8s 中杀掉 pod
kubectl delete pod $TARGET_NODE
# 监控选主完成
watch -n 1 kubectl get pods -l app=kes -o wide
# 在真实机房，可关掉网卡或停止进程

运行前请在测试环境验证脚本的安全性，生产环境须经审批。

9) 迁移自动化（Ansible Playbook 样例）

# file: migrate_kes.yml
- hosts: db_app
tasks:
- name: 抽取近期常用 SQL（示例）
shell: "grep -R \"SELECT\|INSERT\|UPDATE\" /var/app/sqls | head -n 100 > /tmp/top_sqls.txt"
register: top_sql- name: 上传 SQL 至 PoC 环境
copy:
src: /tmp/top_sqls.txt
dest: /tmp/top_sqls.txt- name: 调用兼容性检测工具
shell: "python3 /opt/migration/sql_compat_checker.py"
register: compat_report- name: 收集兼容性报告
fetch:
src: /opt/migration/report.json
dest: ./reports/

10) 验收自动化（pytest + SQL 比对示例）

# file: tests/test_data_consistency.py
import pytest
import cx_Oracle
import psycopg2# 对比示例：按主键比对两侧行数据def fetch_rows_oracle(conn_str, sql):
# placeholder
return []def fetch_rows_kes(conn_str, sql):
return []def test_table_checksum():
sql = 'SELECT id, MD5(CONCAT_WS("|", col1, col2)) as cs FROM lab_results WHERE updated_at > SYSDATE - 1'
a = fetch_rows_oracle('oracle_conn', sql)
b = fetch_rows_kes('kes_conn', sql)
assert set(a) == set(b)

总结

这篇文章以浙江省人民医院的信创实践为核心案例，系统介绍了其从LIS系统切入，逐步实现全栈国产化的过程。作为浙江省卫健系统的“领头雁”，浙人医通过金仓数据库构建异构多院区多活的数据底座，实现了四大院区间数据的双向同步与高等级灾备能力，系统可用性达99.99%，数据调用效率提升60%。这一实践为全省乃至全国集团化医院的信创建设提供了可复制的样板。

在选取突破口时，医院基于LIS系统业务重要性高、数据规模适中、可复制性强等因素，率先展开信创改造。项目中，金仓数据库凭借对Oracle的高兼容性、易迁移与成熟的医疗场景适配能力，成为关键支撑。通过异构组网、多活容灾、多写同步及卫星方案等技术创新，医院实现了RTO≤10分钟、RPO=0的极致容灾目标，保障了多院区业务的连续稳定运行。

随着LIS系统的成功上线，浙人医信创体系全面铺开，富阳院区成为全省首个全栈信创医疗样板间，实现了服务器、操作系统、数据库全国产化和业务系统云化部署。新系统性能显著提升，访问量高峰时延低至0.3秒。文章最后还展示了从SQL语法兼容检测、CDC同步、容灾监控到自动化迁移、测试的技术脚本示例，为信创项目的工程落地提供了实操参考。整体来看，浙人医以“点带面”的路径探索出一条可推广的国产化创新发展之路。