医疗行业多层级复杂网络环境下的消息传输(远程会诊)架构与实现
2017-11-09 11:32
337 查看
近期接手一个针对医疗系统远程会诊平台的技术改造工作,这项工作中的一些技术问题颇具代表性,我会在此记录这一工作的过程和技术细节,如果条件允许,会在 GitHub 上开源部分业务无关的纯技术实现,敬请关注。(https://github.com/iccb1013)。
远程会诊平台的应用场景指的是乡镇或县卫生所,在接诊过程中,对疑难问题上报上级医疗机构,由上级医疗机构进行网络诊断并回复诊疗意见,但是这一过程,并不是简单的点对点的关系。
主要特点:
1) 包含多级机构:乡镇、县、区、市、省。由任意一级向上级机构提出远程会诊请求,可以提供远程会诊服务的上级机构可能存在多个。
2) 部署环境复杂,此系统并非统一部署于服务器的云服务,而是在各级别,都可能会部署区域性的服务器(也可以不部署),如县一级部署服务器,服务于县和乡镇,区、市都分别部署各自的服务器。客户端不能跨级别与服务器进行连接。
3) 网络环境复杂,对于医疗机构,其部署服务器和客户端的网络环境可能十分复杂,多层防火墙、专用网络等,同时对于乡镇或县等机构来说,网络质量亦存在十分不稳定的情况。
从我目前收集的问题来,排除BUG和业务逻辑上问题,基础结构上存在的主要问题是:
1)连接不稳定,对网络环境有较大依赖。
2)响应速度慢,容易卡死。
3)主服务重启后下面连接的所有服务都必须跟着重启。
简单分析:
1)既有的远程会诊平台使用的是基于 TCP 长连接的 WebService,现场环境较复杂时,跨过乡镇、区县、市等地的机构时,还需要穿过各内部网络,网络环境较为敏感,依赖性较大。
2)现有的实现方式并没有对多级层的网络消息传输机制进行独立的拆分实现,而是基于 WebService 连接直接实现各业务接口并集成在客户端中进行使用,也就是硬编码。
鉴于以下问题,新的技术架构有以下几点目标:
1)所有连接支持 HTTP 无状态或 TCP 长连接两种方式,由服务端决定采用哪种方式连接。
2)使用 HTTP 方式连接时,消息的向上传输使用 WEB API 接口的方式进行调用,接收回复消息则使用 HTTP 轮循进行。使用 HTTP 方式可最大程度减小整体架构对网络环境的敏感和依赖,同时极为方便系统规模进行横向扩展。
3)使用 TCP 方式连接则可以获得更高的性能,但是对网络环境的要求更为严格,可以在网络环境较好的节点服务器到 Client 端使用。
4)整体结构分为 主服务器、节点服务器、客户端 三层,支持异构的方式连接,如:客户端到节点服务器使用 TCP 方式,节点服务器到主服务器使用 HTTP 方式,或反之,或均采用同样的连接方式都可以,可在现场配置。
5)文件的存储使用独立的文件服务器,可自建或使用公有云服务。独立的文件服务器可避免文件传输对主服务网络带宽的占用,剥离文件存储相关的具体实现,同时独立的 OSS 服务有较低的带宽成本和存储成本优势。
6)对于消息的传输,使用命令封包的方式进行,技术架构不处理任何业务逻辑。命令封包中包括目标节点、目标 Client、要执行的命令和参数等信息,由客户端发出后,经过节点服务器到主服务器,由主服务器分发给指定的目标。支持任意 Client 到任意 Client 的消息传输。在命令的传输中,当发起 Client 和目标 Client 在同一个节点服务器时,支持经过主服务器和不经过主服务器两种方式,可配置需要配置。经过主服务器可实现全局的记录存储审计等功能。
7)所有的消息传输,都使用异步方式,不支持挂起等待的同步方式。当发起端的一条命令发出之后,发起端通过自己的命令接收器处理命令的回复,两者分别运行于不同的线程。
8)与现有服务端实现和客户端的集成,使用提供 SDK 开发包的方式进行,不进行任何代码层面的混合编写,以维持本架构的独立性,便于后期升级维护,以及实有服务和客户端本身在未来重构之后,能够继续无缝兼容本架构。
原文:http://blog.shengxunwei.com/Home/Post/db2c6373-2639-4717-8601-8361d54afbaa
远程会诊平台的应用场景指的是乡镇或县卫生所,在接诊过程中,对疑难问题上报上级医疗机构,由上级医疗机构进行网络诊断并回复诊疗意见,但是这一过程,并不是简单的点对点的关系。
主要特点:
1) 包含多级机构:乡镇、县、区、市、省。由任意一级向上级机构提出远程会诊请求,可以提供远程会诊服务的上级机构可能存在多个。
2) 部署环境复杂,此系统并非统一部署于服务器的云服务,而是在各级别,都可能会部署区域性的服务器(也可以不部署),如县一级部署服务器,服务于县和乡镇,区、市都分别部署各自的服务器。客户端不能跨级别与服务器进行连接。
3) 网络环境复杂,对于医疗机构,其部署服务器和客户端的网络环境可能十分复杂,多层防火墙、专用网络等,同时对于乡镇或县等机构来说,网络质量亦存在十分不稳定的情况。
从我目前收集的问题来,排除BUG和业务逻辑上问题,基础结构上存在的主要问题是:
1)连接不稳定,对网络环境有较大依赖。
2)响应速度慢,容易卡死。
3)主服务重启后下面连接的所有服务都必须跟着重启。
简单分析:
1)既有的远程会诊平台使用的是基于 TCP 长连接的 WebService,现场环境较复杂时,跨过乡镇、区县、市等地的机构时,还需要穿过各内部网络,网络环境较为敏感,依赖性较大。
2)现有的实现方式并没有对多级层的网络消息传输机制进行独立的拆分实现,而是基于 WebService 连接直接实现各业务接口并集成在客户端中进行使用,也就是硬编码。
鉴于以下问题,新的技术架构有以下几点目标:
1)所有连接支持 HTTP 无状态或 TCP 长连接两种方式,由服务端决定采用哪种方式连接。
2)使用 HTTP 方式连接时,消息的向上传输使用 WEB API 接口的方式进行调用,接收回复消息则使用 HTTP 轮循进行。使用 HTTP 方式可最大程度减小整体架构对网络环境的敏感和依赖,同时极为方便系统规模进行横向扩展。
3)使用 TCP 方式连接则可以获得更高的性能,但是对网络环境的要求更为严格,可以在网络环境较好的节点服务器到 Client 端使用。
4)整体结构分为 主服务器、节点服务器、客户端 三层,支持异构的方式连接,如:客户端到节点服务器使用 TCP 方式,节点服务器到主服务器使用 HTTP 方式,或反之,或均采用同样的连接方式都可以,可在现场配置。
5)文件的存储使用独立的文件服务器,可自建或使用公有云服务。独立的文件服务器可避免文件传输对主服务网络带宽的占用,剥离文件存储相关的具体实现,同时独立的 OSS 服务有较低的带宽成本和存储成本优势。
6)对于消息的传输,使用命令封包的方式进行,技术架构不处理任何业务逻辑。命令封包中包括目标节点、目标 Client、要执行的命令和参数等信息,由客户端发出后,经过节点服务器到主服务器,由主服务器分发给指定的目标。支持任意 Client 到任意 Client 的消息传输。在命令的传输中,当发起 Client 和目标 Client 在同一个节点服务器时,支持经过主服务器和不经过主服务器两种方式,可配置需要配置。经过主服务器可实现全局的记录存储审计等功能。
7)所有的消息传输,都使用异步方式,不支持挂起等待的同步方式。当发起端的一条命令发出之后,发起端通过自己的命令接收器处理命令的回复,两者分别运行于不同的线程。
8)与现有服务端实现和客户端的集成,使用提供 SDK 开发包的方式进行,不进行任何代码层面的混合编写,以维持本架构的独立性,便于后期升级维护,以及实有服务和客户端本身在未来重构之后,能够继续无缝兼容本架构。
原文:http://blog.shengxunwei.com/Home/Post/db2c6373-2639-4717-8601-8361d54afbaa
相关文章推荐
- 医疗行业多层级复杂网络环境下的消息传输(远程会诊)架构与实现
- Linux模拟复杂网络环境下的传输(netem和tc)
- [网络广播] SQL Server 主数据管理结合 BizTalk Server SOA 架构实现保险行业 ECIF 解决方案
- 用Java实现基于SOAP的XML文档网络传输及远程过程调用(RPC).doc
- 内网端口映射之80端口映射和全端口映射,在任何网络环境下实现发布网站和访问内网
- 互联网网站架构升级----消息中间件的实现方案
- 复杂网络K-Shell算法及其Python实现
- Water for asp.net 之七:多层架构的实现
- 业务架构平台的技术实现环境
- 第02天多线程网络:(07):MRC环境下实现单例模式
- 简单多层神经网络实现异或XOR
- Zigbee网络架构+ZigBee的体系结构+理解zigbee节点的实现的案例+“51单片机” 和 “zigbee” 、 “cc2530芯片” 之间的关系+芯片cc2530
- 互联网网站架构升级----消息中间件的实现方案
- 用Java实现基于SOAP的XML文档网络传输及远程过程调用(RPC)
- 基于Theano的多层神经网络及其实现(一)
- 移动架构33_网络访问框架与数据库框架实现断点下载
- php模拟飞鸽传输协议,代码实现向飞鸽发送消息
- spark streaming 实现接收网络传输数据进行WordCount功能
- 业务架构平台的技术实现环境
- 如何利用jgroups实现分布式环境下消息的接受和发送