Tag: HIPAA compliance

“幽灵”进程的幽灵：一场由”沉默杀手”引发的系统危机

上午十点半，门诊高峰时段。

XX省第一人民医院的门诊系统开始”莫名其妙”地变慢——不是全瘫，而是”一点点往下沉”：刚开始挂号响应从2秒变成5秒，人们还能接受；半小时后变成15秒，开始有患者抱怨；一小时后变成30秒以上，缴费窗口前排起了长队，护士们在喊”系统太卡了”。

李主任在看监控：CPU使用了45%，内存还有60%可用，网络流量正常，数据库连接池使用率55%——所有指标都在安全范围内。但系统就是越用越慢，像是一辆在平路上慢慢失去动力的车。

1. 指标正常，但业务异常：最诡异的故障

“重启试试？”有人提议。

“不行，”李主任摇头，”现在是高峰，重启会导致所有正在办理的业务中断，患者会更不满。先查原因。”

这个决定很关键。如果当时选择了重启，问题可能暂时消失，但那个”幽灵”会继续存在，下次以更猛烈的方式爆发。

老林建议从进程层面入手。他们用top命令查看系统进程，发现了一个奇怪的进程：java -jar /opt/his/tmp/cleanup.jar，这个进程的CPU占用率只有0.3%，但VIRT（虚拟内存）高达2GB，RES（物理内存）也有800MB，而且已经运行了超过48小时。

“这个进程是干什么的？”李主任问。

小张回忆起来：这是两周前部署的一个”临时清理脚本”，用于清理临时文件。当时 supposed 是运行一次就退出，但似乎它变成了常驻进程。

他们进一步检查这个进程的打开文件：lsof -p ，发现它打开了一个数据库连接，而且这个连接的状态是”Sleep”，但时间已经超过48小时。

“就是这个’ninja’进程，”老林说，”它占着一个数据库连接不放，而且因为它持续存在，连接池的其他连接被它慢慢挤占。”

但仅仅这一个连接，不至于把连接池全部占满。小吴继续排查，又发现了多个类似的”僵尸进程”：有的已经死亡但父进程没回收（orphaned zombie），有的自己创建了大量线程但从未释放，有的在等待某个永远不来的网络响应（I/O wait）。

2. 清理僵尸：一场高风险的手术

“我们必须清理这些僵尸进程，”李主任说，”但不能影响正在进行的业务。”

他们制定了一个计划：

1. 识别所有空闲超过30分钟的数据库连接

2. 找出这些连接关联的进程

3. 对于确认是僵尸的进程，先尝试优雅终止（SIGTERM），如果10秒内不退出，再强制终止（SIGKILL）

4. 清理后密切观察业务日志，确保没有数据丢失或不一致

第一步，他们用SQL查询了数据库的进程列表：

“`sql
SELECT id, user, host, db, command, time, state
FROM information_schema.processlist
WHERE time > 1800 AND command != ‘Sleep’ OR state = ‘Sleep’ AND time > 1800;
“`

（注：此处为示意逻辑，实际更复杂）

结果发现了80多个超时会话。他们逐一对每个会话对应的应用服务器进程进行标记。

小吴编写了一个自动化脚本：

1. 获取所有空闲超过30分钟的数据库连接ID

2. 通过连接信息反查应用服务器上的进程ID

3. 对进程进行优雅终止，等待10秒

4. 如果进程仍在，强制终止

5. 记录清理日志

脚本运行前，李主任要求：”每清理5个连接，就检查一次业务日志，确保没有异常。”

清理开始。前5个连接顺利清理，无异常。10个、15个、20个… 系统响应时间慢慢改善，从30秒降到了18秒。

但清理到第35个时，系统再次出现短暂闪退——所有页面白屏约15秒。

“停！”李主任喊道。

他们检查发现，这个连接关联的是一个正在执行批量数据同步的任务。虽然这个任务已经”空闲”了35分钟，但它处于一个事务中，一旦强制终止，会导致数据同步中断，部分数据不一致。

“我们不能只看’空闲时间’，”老林说，”还要看当前事务状态。”

他们调整了清理策略：只清理那些”不在活动事务中”的空闲连接。

调整后，清理继续。这次顺利多了。下午一点，清理完成，系统响应时间稳定在4秒以内。但李主任心里明白，这只是临时解决了资源占用问题，那个”幽灵”的制造者——那些不该存在的僵尸进程——是怎么来的，才是根本。

3. 为什么会有僵尸进程？

下午业务低峰期，技术团队开始了根因分析。

第一个发现：应用程序异常处理不当

他们检查了那个cleanup.jar的源码（ decompiled ），发现它在捕获到InterruptedException后，只是简单return，没有真正关闭数据库连接和线程资源。这个jar包是由一个外包团队写的，上线时没有做代码评审。

第二个发现：线程池配置不合理

应用服务器的线程池配置是默认值：核心线程数10，最大线程数200，队列容量1000。在门诊高峰，请求并发达到1500时，线程池会创建大量线程来处理，但这些线程在任务完成后不会立即销毁（核心线程不销毁），导致线程数慢慢积累到200的上限。而这些线程如果因为某种原因阻塞，就会变成”僵尸线程”。

第三个发现：数据库连接泄漏

某些业务代码中，数据库连接获取后，在异常分支里没有正确释放。正常情况下，连接会随着方法结束自动关闭（try-with-resources），但一旦发生异常跳过close语句，连接就”悬空”了。

第四个发现：监控盲区

“我们一直以为连接池使用率55%是安全的，”李主任看着监控图表，”但55%指的是’已分配连接’，不包括’僵尸连接’。如果僵尸连接占用了30%，实际可用连接只有25%，早就该告警了。”

老林补充：”我们的监控只采集了’连接池使用率’这个指标，没有采集’活跃连接率’和’空闲超时连接率’。这就是为什么所有指标正常，但业务已经卡住。”

4. 系统性整改：从被动灭火到主动预防

当晚，李主任主持了故障复盘会。他定了三个整改方向：

第一，建立连接泄漏检测机制

在数据库层面，开启performance_schema，监控长时间未关闭的连接。对于超过30分钟的空闲连接，自动记录堆栈信息并告警。这样，即使发生泄漏，也能在影响业务前发现。

同时，应用层面增加连接池的abandoned回收机制：如果一个连接被借出超过10分钟未归还，强制回收并记录日志。虽然强制回收可能导致该连接的业务失败，但比整个系统拖垮要好。

第二，规范进程生命周期管理

所有后台任务进程必须有明确的启动、停止、监控机制。现在，他们要求：

– 任何后台任务必须打包为systemd service，有明确的ExecStart、ExecStop、Restart策略

– service文件必须包含TimeoutStopSec=30，防止进程拒绝退出

– 所有服务必须提供健康检查接口，供监控系统探测

– 禁止使用”nohup java -jar”这种原始方式启动服务

那个运行了48小时的cleanup.jar，就是因为没有systemd管理，一旦启动就不知道如何停止，只能手动kill。

第三，优化线程池配置和监控

根据业务高峰的并发量（约1500），他们将线程池参数调整为：

– corePoolSize=50（避免线程数过少导致排队）

– maxPoolSize=300（允许弹性扩容）

– queueCapacity=1000（缓冲队列）

– keepAliveTime=60（空闲线程60秒后销毁）

同时，增加线程池监控指标：

– 活跃线程数

– 队列等待数

– 任务完成总数

– 拒绝任务数

这些指标接入现有监控系统，设置阈值告警。

第四，强化代码审查和异常处理规范

所有生产环境部署的代码，必须经过至少一人代码审查，重点审查：

– 资源释放（数据库连接、文件句柄、线程）是否在所有异常路径都能正确关闭

– 是否使用了try-with-resources或类似机制

– 线程池任务是否有超时设置

– 是否有无限循环风险

此外，统一异常处理规范：捕获异常后，必须记录日志（包括堆栈），必须确保资源释放，必须考虑是否需要向上传递。

5. 一个月后：系统稳定运行

整改后的一周内，他们又发现了两起潜在的连接泄漏——都被自动检测机制捕获并及时处理。一个月后，系统没有出现类似的”缓慢失能”故障。

李主任在月度运维会议上说：”这次故障给我们上了一课。它告诉我们，指标正常不代表系统健康。我们需要监控的不仅仅是CPU、内存这些’传统指标’，更要监控’业务健康度’——比如平均响应时间、错误率、吞吐量。”

他还提出了一个概念：”运维的黄金法则是’在用户感知之前发现问题’。当患者开始抱怨’系统卡’时，其实问题已经存在一段时间了。我们的目标是通过精细监控，让系统在用户感知到异常之前，就自动修复或至少自动告警。”

软佳的客户成功经理在回访时，对这次整改给予了高度评价。她说：”我们服务过上百家医院，XX医院这次故障的复盘深度和整改力度，是前三的水平。很多医院故障后只修bug，不建流程，结果同类问题反复发生。”

6. 给运维人员的建议

老林在内部培训中，总结了”僵尸进程防御三原则”：

原则一：资源必须有归属

每个数据库连接、每个线程、每个文件句柄，都必须有明确的创建者、所有者、销毁时机。不能让它”自然死亡”，必须”主动回收”。

原则二：监控要看趋势，看质量

不要只看”总量是否超过阈值”，要看”活跃占比”、”空闲时长分布”、”异常增长趋势”。一个指标从20%升到45%，虽然没到80%的告警线，但趋势已经说明问题。

原则三：应急要有章法，根治要有流程

遇到故障，先按预案处理恢复业务；恢复后必须进行根因分析，找到流程漏洞；然后整改流程，防止同类问题再发生。不能”好了伤疤忘了疼”。

互动话题

你们医院有没有遇到过”监控正常但业务异常”的情况？是怎么发现并解决的？你觉得最应该监控哪些”非传统”指标来预防这类问题？欢迎在评论区分享你的运维实战经验。

> 基于真实医院场景改编，人物均为化名

立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html


扫码预约

手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）

支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语

说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。

你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。

备份了，然后呢？一次”恢复失败”敲响的警钟

凌晨四点，XX省第一人民医院数据中心。

安全工程师小赵的电话把李主任从梦中拽醒：”李主任，我们发现一个异常——内部账号在过去三个月的非工作时间大量查询患者数据，累计超过5000条记录！”

李主任瞬间清醒。这不是普通的违规查询，而是一次持续数月的内部数据窃取事件。

调查迅速锁定嫌疑人：行政楼文员刘某，因经济压力，被外部黑客利用，导出了大量患者敏感信息。

但更让团队震惊的是后续的追溯——当我们试图核查被窃取的具体数据范围时，却发现最近的增量备份文件已经损坏，无法读取。这意味着我们根本就没有办法准确评估这次泄露的影响范围和严重程度。

那一刻，李主任深深意识到：备份的目的不是存在，而是恢复。 没有经过验证的备份，等同于没有备份。

安全事件处理完后，李主任立刻召集了数据管理专项会议。他提出了一个问题：”我们的备份策略，真的能让我们睡得着觉吗？”

会上，团队的检查结果令人不安：

第一条发现：备份脚本没有任何校验机制。每天凌晨两点，备份任务自动执行，生成一个压缩包放到磁带机上。任务日志只记录”备份完成”，不会验证备份文件是否可读、数据是否完整。那个损坏的文件，已经存在了二十天，但谁都没发现。

第二条发现：异地备份形同虚设。按照”3-2-1″原则，应该有两份异地备份。但实际上，异地备份因为”网络慢、成本高”，被配置成了”每月一次”。而且，那个异地备份存储已经满了三个月没有清理，新数据根本写不进去。

第三条发现：没有恢复演练。团队的”恢复预案”文档有三十页，但谁也没真正演练过——文档写的是”从磁带恢复大约需要6小时”，但实际上，没人试过，没人知道具体步骤，也没人知道真实需要多长时间。

刘某的案例像一记重锤。李主任意识到，数据安全的链条上，备份只是第一个环节，真正决定生死的是”恢复能力”。

他制定了全新的备份验证流程：

第一，每次备份完成后，自动触发一次”恢复测试”——不是全量恢复，而是随机抽取一个文件或一个表，尝试从备份中恢复出来，验证文件可读性和数据完整性。这个测试在十分钟内完成，如果失败，立即告警。

第二，异地备份改为每日增量、每周全量，并建立异地备份的传输监控——如果连续三天传输失败，自动升级为P2告警。

第三，每季度举行一次”Recovery Drill”（恢复演练）。不只是IT部门参与，还要邀请业务科室代表见证。演练内容：模拟真实场景（如”磁盘整柜损坏””勒索软件加密数据”），从备份中恢复关键业务数据，并验证恢复后的数据一致性。

第四，建立敏感数据脱敏策略。即使数据被非法导出，如果身份证号、手机号等敏感字段已经脱敏，实际危害也会大幅降低。他们对患者表的敏感字段实施了动态脱敏：非授权查询只能看到后四位，完整信息需要二次认证。

第五，推行权限最小化原则。刘某的账号拥有远超其工作需要的查询权限。现在，每个账号的权限必须由科室主任审批，每季度复盘。临时权限必须有明确期限，到期自动回收。

这些措施中，恢复演练阻力最大——业务科室不理解：”数据中心模拟故障，对我们业务有什么影响？”

李主任用了一个比喻来解释：”这就像消防演习。学校每年都要搞消防演习，学生抱怨’又不是真着火’。但真着火的时候，那些演练过的人知道怎么逃生，没演练的人可能就慌了。”

“我们的恢复演练，就是’数据消防安全演习’。”

第一个季度演练的结果令人震惊：团队原计划4小时完成的恢复，实际花了9小时——因为备份文件太大，磁带读取速度慢；而且，恢复顺序搞错了，先恢复了非关键表，关键表反而因为依赖关系阻塞。

演练结束后，李主任在总结会上说：”这次演练暴露的问题，比没演练更可怕。我们原以为备份策略很完善，但真实情况是，我们根本就没有验证过它是否真的有效。”

“数据安全的底线不是’我们做了备份’，而是’我们能把它找回来’。”

半年后，当软佳的客户成功经理来医院进行数据安全审计时，李主任自信地展示了他的”备份成熟度模型”：

– 级别一：有备份，但没验证（我们曾经在此）

– 级别二：有验证，但不自动（人工抽查）

– 级别三：有自动验证+不演练（我们现在）

– 级别四：有自动验证+定期演练（目标）

“我们现在是三级，”李主任说，”争取两年内达到四级——每次恢复都能在4小时内完成，而且数据零丢失。”

经理问：”如果现在真的发生勒索软件攻击，你们多久能恢复？”

李主任给出了一个具体数字：”核心业务数据，预计6小时；全院系统，预计12小时。但前提是备份磁带都在手边，异地备份可用。”

经理点头：”这个答案比’我们有备份’有价值得多。”

数据泄露事件过去一年后，医院没有再发生类似的安全事件。但李主任知道，真正的考验不是过去，而是未来——只要数据还在增长，风险就在积累。

有一次，审计部门质疑恢复演练的成本：”每季度一次，要占用三天时间，还要协调业务科室，值不值得？”

李主任回答：”刘某的事件，直接损失是患者信息泄露，间接损失是医院声誉受损、患者信任下降。我们算过，如果发生一次大规模数据丢失，恢复成本是演练成本的100倍以上。”

“而且，”他补充道，”病人数据是医院的命根。命根子的事，什么叫’值不值得’？”

互动话题

你们医院的备份策略是怎样的？有没有真正演练过恢复流程？如果现在发生数据勒索，你们多久能恢复核心业务？欢迎分享你们的备份和灾备经验，一起探讨如何让数据真正”可恢复”。

> 基于真实医院场景改编，人物均为化名

立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html


扫码预约

手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）

支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语

说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。

你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。

当HIS系统集体”失声”：一场跨越深夜的排障战役

凌晨三点，XX省第一人民医院信息科值班室的电话骤响。李主任从沙发上惊坐而起，屏幕上闪烁着门诊系统的监控告警——挂号、收费、药房三个核心模块同时出现服务不可用，患者滞留大厅的投诉电话如潮水般涌入。

“全部挂了？”李主任的声音很冷静，但手心已经出汗。

“是的，”值班工程师小张的声音带着恐慌，”我们试了自动恢复，没成功。现在系统完全没响应。”

这不是普通的故障。在过去的一个月里，系统已经经历过三次小规模”抽搐”，但每次都被快速”镇压”。这一次，它选择了最不留情面的方式——全面崩溃。

李主任立刻启动应急响应流程。技术总监老林、数据库专家小吴、网络工程师老王，都在十分钟内赶到。他们知道，这次故障不同寻常——普通的服务挂掉，重启就能好；这次，连重启都失败了。

“数据库连接池全部占满，”小吴盯着监控面板，”新的请求根本进不来。”

“CPU使用率只有45%，内存还有60%可用，”老王检查着服务器指标，”硬件没问题。”

“但系统就是没响应，”李主任看着不断涌入的投诉电话，”门诊已经瘫痪了。”

真正的问题开始浮出水面。老林提出了一个假设：”是不是有’僵尸连接’占着资源？”

他们开始深入排查。在数据库层面，他们发现了一些异常：很多连接状态是”Sleep”，但这些会话已经空闲了很长时间——有些甚至超过三十分钟。这些”死而不僵”的连接，像是血管里的血栓，慢慢堵塞了整个血流。

更糟糕的是，这些僵尸连接不是凭空出现的。小张回忆起三天前的一次配置变更——为了提升某个高频查询的性能，他调整了数据库缓存参数，但忘了同步调整连接池上限。这个改动看似微小，却埋下了隐患。

“我们得先恢复服务，”李主任看着时钟，已经凌晨三点半，”医院八点就要开诊，我们必须在天亮前搞定。”

他们制定了一个分步方案：先快速清理僵尸连接，释放资源；同时准备一个紧急回滚脚本，如果清理导致问题扩大，立刻回滚到变更前状态；最后，再永久性调整连接池配置。

清理过程并不顺利。有些连接关联着重要业务，强制断开可能导致数据不一致。他们不得不逐个判断哪些可以安全清理。小吴编写了一个脚本，自动识别空闲超过二十分钟的连接，并标记为”可清理”。

凌晨四点，清理开始。每清理一个连接，小吴都盯着业务日志，确保没有异常。前50个连接顺利清理，系统响应时间从15秒降到了8秒。”有效，”李主任说，”继续。”

但清理到第80个时，系统突然出现短暂的闪退——大约十秒钟内，所有页面都无法访问。团队立刻停止清理，检查原因。发现是一个关键业务进程正在执行一个长查询，它的连接也被标记为”空闲”，但实际上正在处理业务。

“我们的判断逻辑有问题，”老林说，”不能只看空闲时长，还要看当前执行状态。”

他们调整策略：只清理那些”空闲”且”不在事务中”的连接。这次，清理进行得很顺利。凌晨五点，系统响应时间降到3秒以内。但李主任知道，这只是临时恢复，根本问题还没解决。

真正的根因分析要等到业务高峰期之后才能进行。现在，他们需要确保八点门诊顺利开诊。

早上七点，门诊开始。系统运行正常，但李主任没有放松——他还不知道那个”占用资源却不释放”的根本原因是什么。

八点刚过，投诉电话又响了。这次的问题不同：某些挂号操作异常缓慢。

“我就知道没那么简单，”李主任对老林说，”临时清理只是治标，不治本。”

他们决定在当天业务低峰期进行一次彻底的深度分析。下午三点，团队聚集在会议室。小吴展示了他的发现：问题根源是某个门诊排班查询功能中的一个bug。这个功能在上周上线，它使用了一个临时的缓存机制来加速访问，但缓存的键设计有缺陷——使用了”排班日期+科室”作为键，却没有考虑”医生”这个维度。

结果，当某个科室的医生排班发生变更时，缓存无法准确失效，导致查询走缓存返回的是过时数据。更糟糕的是，这个过时数据会触发一次全量重新计算，而这个计算会长时间占用数据库连接。

“这就是为什么连接池会被慢慢掏空，”小吴说，”每个过时的缓存命中都会触发一个长时间运行的查询，这个查询占着一个连接不放，而新请求进不来。”

找到了问题，修复就快了。他们调整了缓存键的设计，增加了医生ID的维度，确保每次排班变更都能准确失效相关缓存。同时，他们优化了查询逻辑，避免了不必要的全量重新计算。

修复上线后，系统恢复了稳定。但李主任召集的复盘会，却充满了紧张的气氛。

老林首先发言：”这次故障的直接原因是缓存键设计缺陷。但深层原因是什么？是我们变更管理流程的漏洞。”

“上周五下午，这个功能上线时，只有一个人在操作。没有代码评审，没有测试验证，没有备份回滚方案。’小变更’ mentality——觉得这个改动小，不会出事。”

“但所有大事故，都是由’小变更’引发的。”

“如果我们有变更评审流程，这个缺陷可能在测试阶段就被发现。如果我们有分支发布流程，这个改动可以通过灰度发布，影响范围不会这么大。如果我们有更完善的监控，能在缓存查询变慢时及时发现…”

李主任总结：”这次故障，暴露的不是技术能力问题，是流程成熟度问题。我们需要建立变更管理规范：任何生产环境变更，必须经过至少一人评审；关键功能变更，必须先在测试环境充分验证；变更必须有快速回滚方案；变更后必须密切监控至少二十四小时。”

会议结束时，天已经黑了。李主任站在办公室窗前，看着外面安静的街道。他知道，这次故障给医院业务带来了不小的影响——患者投诉增加，门诊效率下降，信息科的信任度受损。

但他也知道，这次故障是团队成长的一次机会。只有真正经历过危机，才能体会到规范流程的重要性。

一周后，软佳的技术总监来医院做回访。李主任和他聊起了这次故障。总监说：”我们经历过类似的案例。XX市第一人民医院也曾因为一个缓存bug导致系统缓慢。但那次之后，他们建立了非常严格的变更管理流程，现在已经两年没出过重大故障了。”

“你们现在的整改措施，我们看了很欣慰——不只是修bug，更是建流程。”

李主任点头：”我们希望，这成为最后一个因为’小变更’引发的大故障。”

三个月后，当软佳再次来医院巡检时，李主任主动分享了一个好消息：自那次整改以来，医院HIS系统实现了连续九十九天的稳定运行，没有发生任何P1级故障。

“现在我们每次做变更，都会问自己三个问题：这个变更真的必要吗？如果出了问题，我们能在多长时间内回滚？我们怎么证明这个变更不会引入新的问题？”

老林笑着说：”这三次’小变更’三个问题，比任何监控工具都管用。”

李主任说：”运维的最高境界，不是不出故障，而是让故障越来越少，越来越小。而要做到这一点，唯一的办法是把每个’小变更’都当成’大事件’来对待。”

互动话题

你们医院发生过因为”小变更”引发的大故障吗？后来是怎么整改的？你在变更管理上吃过最大的亏是什么？欢迎在评论区分享你的经验和教训。

> 基于真实医院场景改编，人物均为化名

立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html


扫码预约

手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）

支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语

说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。

你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。