医疗保障信息平台应用系统技术架构规范版.docx
《医疗保障信息平台应用系统技术架构规范版.docx》由会员分享，可在线阅读，更多相关《医疗保障信息平台应用系统技术架构规范版.docx（43页珍藏版）》请在冰豆网上搜索。
医疗保障信息平台应用系统技术架构规范版
医疗保障信息平台应用系统技术架构规范
1范围
本规范规定了医疗保障信息平台建设总体技术架构，给出了业务子系统应用架构分层设计、核心服务框架和云平台适配框架设计说明，提出了框架相关技术选型、框架总体应用要求，明确了框架版本更新机制等方面内容。
本规范适用于医疗保障信息平台相关业务应用子系统和业务中台的建设。
2术语和定义
2.1
架构architecture
有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
2.2
医疗保障应用框架HealthcareSecurityApplicationFramework（HSAF）
为了实现医保信息化统一技术架构标准目标，为业务子系统提供技术架构标准所要求的
基础功能软件产品和服务。
采用分布式云架构，封装核心云支撑服务适配接口，用于实现云产品解耦设计。
3缩略语
下列英文缩略语适用于本文件。
HSAF医疗保障应用框架（HealthcareSecurityApplicationFramework）IaaS基础设施即服务（Infrastructure-as-a-Service）
PaaS平台即服务（Platform-as-a-Service）Web全球广域网（WorldWideWeb）
API应用程序编程接口（ApplicationProgrammingInterface）SDK软件开发工具包（SoftwareDevelopmentKit）
SQL结构化查询语言（StructuredQueryLanguage）TCP传输控制协议（TransmissionControlProtocol）HTTP超文本传输协议（HyperTextTransferProtocol）
HTTPS超文本传输安全协议（HyperTextTransferProtocolSecure）XML可扩展标记语言（ExtensibleMarkupLanguage）
JSONJava脚本对象简谱（JavaScriptObjectNotation）ORM对象关系映射（ObjectRelationalMapping）JWTJSONWeb令牌（JSONWebToken）
IoC控制反转（InversionofControl）DI依赖注入（DependencyInjection）
AOP面向切面编程（AspectOrientedProgramming）
OLTP联机事务处理过程（On-LineTransactionProcessing）HA高可用（HighAvailable）
ECS阿里云服务器（ElasticComputeService）
HSF阿里云淘宝服务框架（High-speedServiceFramework）
EDAS阿里云企业级分布式应用服务（EnterpriseDistributedApplicationService）
DRDS阿里云分布式关系型数据库服务（DistributedRelationalDatabaseService）OSS阿里云对象存储服务（ObjectStorageService）
TSF腾讯微服务平台（TencentServiceFramework）CMQ腾讯云消息队列（CloudMessageQueue）
TDSQL腾讯云分布式数据库服务（TencentDBforTDSQL）CLS腾讯云的日志服务（CloudLogService）
ELKElasticsearch、Logstash和Kibana简称RPC远程过程调用（RemoteProcedureCall）
4总体技术架构
4.1总体技术架构
总体技术架构参见图1及图2。
系统总体技术架构采用分布式云架构，在基础设施层上，结合云平台，提供分布式服务支撑。
通过业务中台构建业务中心，支持实时交易型应用；通过数据中台实现数据汇聚、数据治理等，开展大数据应用。
基于统一的应用分层架构建设经办管理类、公共服务类、智能监管类、宏观决策类业务子系统应用。
图1总体技术架构——概念图
图2总体技术架构——逻辑图
总体技术架构描述如下：
a）业务系统：
基于医疗保障应用框架（HealthcareSecurityApplicationFramework，简称：
HSAF）开发的支撑医疗保障业务运行的应用子系统；
b）HSAF框架：
采用分布式云架构，封装核心云支撑服务适配接口，用于实现云产品解耦设计，详见4.3；
c）适配层：
基于HSAF的适配技术，将应用层依赖的分布式技术与具体厂商的分布式技术进行适配，实现应用层可以适配多家厂商的分布式技术；
d）云支撑服务层：
基于云基础设施，为应用层提供通用的技术支撑服务，包括分布式服务、分布式缓存、分布式数据访问、日志服务、非结构化存储和消息队列等；
e）云基础设施层：
采用云架构，在物理设备基础上，实现计算资源、存储资源、网络资源的动态管理和资源调配。
4.2架构设计思路
为满足全国医疗保障信息系统部署模式的可灵活选择要求，相对传统系统技术架构，医疗保障信息平台在架构中增加了“适配层”，将应用层依赖的分布式技术与具体厂商的分布式技术进行适配，实现应用层可以适配多家厂商的分布式技术。
地方可根据实际情况向各个云资源提供商（包括政务云和专有云等）租用或申请资源使用，也可自建数据中心。
云基础设施建设参见图3。
图3云基础设施建设
在总体技术架构设计和代码开发时，应遵循一个重要原则：
框架需满足技术扩展性的要求，当前框架能适配至少三种云平台分布式技术，新的分布式技术的加入可以通过框架的扩展实现。
4.3应用技术分层架构
为了保证业务子系统应用具有良好的横向扩展能力，以应对未来业务的快速发展，整个应用架构采用分布式云架构设计，业务能力通过微服务框架基于高内聚低耦合的思路实现。
所有服务均为无状态服务，实现在线应用的扩缩容能力。
应用分层架构参见图4。
图4应用技术分层架构
业务应用子系统分为客户端和服务器端两大部分：
a）客户端：
前端展现层；
b）服务器端：
——控制层；
——业务逻辑层；
——数据访问层；
——分布式数据库层。
业务应用子系统需严格按照该分层架构和调用层次进行应用程序开发和服务调用。
4.4HSAF框架
4.4.1概述
HSAF框架设计采用1+N模式，即1套核心框架，多套云支撑服务技术平台适配。
HSAF框架中包含控制层、业务层和持久化层接口抽象，定义了分布式服务框架、分布式缓存、分布式消息队列、非结构化存储、日志服务等分布式中间件服务的接口。
基于4.2架构设计思路，HSAF框架分为两部分：
a）HSAF核心框架，提供业务子系统运行相关的基础框架和服务支撑；
b）HSAF适配框架，提供对不同云支撑服务技术平台的适配和可移植支撑。
HSAF框架总体结构参见图5。
图5HSAF框架结构
4.4.2HSAF核心框架
HSAF核心框架，统一封装了Spring框架相关组件、ORM持久化框架、数据库连接池组件、会话上下文、异常统一拦截器、操作日志拦截器、权限认证拦截器、安全过滤拦截器等开发基础服务，能使业务系统开发人员尽可能只关注业务逻辑，而无需过多关注技术细节。
它主要提供了以下功能和服务：
a）统一认证服务（详见6.1）；
b）单点登录服务（详见6.2）；
c）全局ID序列服务（详见6.3）；
d）事务管理（详见6.4）；
e）异常管理（详见6.5）；
f）定时任务（详见6.6）；
g）持久化服务（详见6.7）；
h）数据库连接池服务（详见6.8）；
i）报表服务（详见6.9）。
4.4.3HSAF适配框架
4.4.3.1适配抽象层
适配抽象层是对适配层中的分布式服务的具体技术实现进行抽象，提供了分布式缓存、远程服务调用、非结构化存储、消息队列等PaaS层服务的抽象接口。
在代码中，应基于抽象接口层进行开发，而不能直接使用具体的扩展派生类，否则代码将绑定某种具体技术方案。
适配抽象层设计详见7.1。
4.4.3.2适配实现层
适配实现层基于适配抽象层，扩展了分布式服务的具体技术实现。
医疗保障信息平台适配的技术实现，已预设提供以下三套方案：
阿里云专有云产品（详见7.2）、腾讯云专有云产品（详见7.3）、开源产品中的一种选型（详见7.4）。
各地医保系统做技术合规选型时，如采用HSAF框架预设适配实现技术之外的技术，应做相应适配、开发工作。
4.5远程服务调用
远程服务调用是分布式服务框架的基础和核心功能。
目前主流的分布式服务框架使用两种远程服务调用协议：
a）RPC协议，以Dubbo、Thrift、gRPC、rpcx、Motan为代表的框架使用的协议；
b）HTTP协议，以SpringCloud为代表的框架使用的协议。
两种协议在不同的分层上提供服务，RPC协议是在Service层提供服务，HTTP协议是在Controller层提供服务。
为了兼容两种不同的服务提供方式，实现一套业务代码适配不同的分布式服务框架所使用的远程服务调用协议，如图6所示，架构要求如下：
a）对于RPC协议，通过提供不同的服务注册发现配置文件来实现协议的切换；
b）对于HTTP协议，Service服务需要额外包装一层Controller层来实现服务的协议转换。
图6远程服务调用不同协议适配方案
5应用技术分层架构
5.1客户端
5.1.1概述
客户端包含PC端、移动端、大屏幕端等类型。
客户端与服务器端之间的通讯协议为HTTP协议，交互的数据格式为JSON格式。
5.1.2前端展现层
前端展现层泛指一切在客户端直接与用户交互的客户界面（UI），本层是MVC架构中的视图层（V）。
各类型客户端使用各自的组件作为前端展现层的UI实现方式。
前端展现层将用户对UI的操作转化成基于HTTP协议的JSON格式的字符串去访问服务器，并将服务器返回的数据通过各自的组件展现给用户。
服务器端能响应符合HTTP/JSON的业务请求，客户端应发出符合业务要求的HTTP/JSON请求，由服务器端处理和响应。
HSAF框架在浏览器上的前端展现层实现是参考实现。
HSAF框架提供了基于PC端的前端展现层实现，其他类型客户端部分需要开发商自行实现。
5.2服务器端
5.2.1概述
服务器端包含控制层、业务处理逻辑层、数据访问层和分布式数据库层四部分。
5.2.2控制层
控制层包含过滤器拦截器层、控制器层（Controller）两部分。
过滤器拦截器层主要处理全局性问题，一切访问都会经过过滤器拦截器层处理，不会绕过过滤器拦截器直接访问控制层。
本层次提供的能力包括：
a）分布式会话管理：
用户会话信息统一写入分布式缓存中；
b）装载上下文信息；
c）记录操作日志；
d）安全管理：
通过一个过滤器链拦截进入的请求，并将这些请求转给认证和访问决策管理器处理，从而增强安全性。
控制器层负责请求的全生命周期处理，包含接收——分发——调用业务——视图展现的全过程。
HSAF的核心控制框架是围绕前端控制器（DispatcherServlet）展开的，前端控制器负责将请求派发到特定的控制器。
当控制器类接收到一个请求时，它会在自己内部寻找一个合适的处理方法来处理请求。
控制器在选择好适合处理请求的方法时，传入收到的请求（根据方法参数类型，可能以不同的类型传入），并且调用该方法中的逻辑来进行处理。
方法逻辑会调用业务逻辑。
业务逻辑运行完毕之后，会委派给一个视图，由该视图来处理方法的返回值。
返回的视图名称会返回给前端控制器，它会根据一个视图解析器将视图名称解析为一个具体的视图实现。
5.2.3业务逻辑层
业务逻辑层包含Service、BO两个子层次。
在View、Controller、Service、BO这三个层次之间通过DTO进行业务对象的传递，在BO与DAO之间通过DO进行数据对象的传递。
Service是服务的发布层，提供对外服务的接口，并调用BO完成接口任务。
BO层实现具体的业务逻辑。
DAO层书写数据库访问逻辑，调用持久化层实现数据库的访问工作。
5.2.4数据访问层
数据访问层分为持久化层和数据访问代理层两部分。
持久化层实现O/RMapping的工作并调用分布式数据库。
数据访问代理层统一接收数据访问层的请求并对请求进行解析、优化、路由、分发给分布式数据库，提供对分库分表、读写分离的透明支持，并且提供对跨库信息进行合并等操作，将数据库结果返回给数据访问层。
5.2.5分布式数据库层
分布式数据库层通过分布式数据访问代理服务，访问分布式关系型数据库，能使多个关系型数据库工作如在同一个关系型数据库一样。
5.3框架层次调用
5.3.1对象模型定义
分层中涉及的对象模型定义如下：
a）DTO（DataTransferObject）:
数据传输对象，Service或Manager向外传输的对象；
b）BO（BusinessObject）:
业务对象，由Service层输出的封装业务逻辑的对象；
c）DO（DataObject）:
数据对象，此对象与数据库表结构一一对应，可扩展虚拟字段（如一些查询条件、计算字段、汇总信息等），通过DAO层向上传输数据源对象。
5.3.2调用顺序
框架层次调用参见图4，框架层次调用顺序如下：
a）客户端浏览器发起HTTP/JSON请求；
b）服务器端过滤器过滤请求，做安全、编码、session管理等处理，拦截器拦截请求做记录日志、访问统计等操作，并装载上下文信息；
c）控制器接收前端传过来的DTO对象，并调用本地服务或者远程服务；
d）Service分为接口与实现两部分。
Service服务接口接受控制层的远程或本地调用，接收DTO对象，调用本地BO中的业务逻辑，并将BO返回的业务结果（DTO对象）返回给控制层（远程或本地客户端）；
e）BO分为接口与实现两部分。
BO服务接口接受Service的本地调用，接收DTO对象，实现业务逻辑，使用DO对象调用DAO来访问数据库，将DAO返回DO对象转换为DTO对象，返回给Service；
f）DAO层接受BO层的调用，接收DO对象，实现具体的SQL逻辑，访问数据库，并将返回的数据模型返回给BO；
g）数据访问层实现数据持久化工作，将数据库的库表结构与java对象做映射；
h）数据访问代理层接受持久化层的数据访问，对数据访问进行数据操作的解析和执行，包括会话管理、分库分表策略、语义解析、请求路由、数据合并、切换控制等，数据访问代理层将数据操作处理后分派到具体的分布式数据库；
i）分布式数据库层接受数据访问代理层的访问，进行数据库处理，将数据返回给数据访问代理层。
5.3.3调用要求
各层次的调用顺序及对象模型的传输，应遵循5.3.2所述。
对象模型传输示意参见图7。
图7对象模型传输示意图
6核心框架设计
6.1统一认证服务
6.1.1概述
用户认证指验证某个用户是否为系统中的合法主体，即判断用户能否访问该系统。
用户认证一般要求用户提供用户名和密码。
系统通过校验用户名和密码来完成认证过程。
6.1.2认证技术
HSAF框架中采用OAuth2.0标准、JWT（JSONWebToken）进行登录认证，使用SpringSecurity框架完成相关的认证和授权验证。
6.1.2.1OAuth
OAuth是一种开放的协议，为桌面、手机或Web应用提供了一种简单的、标准的方式去访问需要用户授权的API服务。
OAuth2.0具有以下特点：
a）简单：
不管是OAuth服务提供者还是应用开发者，都很容易于理解与使用；
b）安全：
没有涉及到用户密钥等信息，更安全更灵活；
c）开放：
任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth。
OAuth2.0定义了四种授权方式：
a）授权码模式（AuthorizationCode）；
b）简化模式（Implicit）；
c）密码模式（Password）；
d）客户端模式（ClientCredentials）。
OAuth2.0定义了以下几种角色：
a）ResourceOwner：
资源拥有者；
b）ResourceServer：
资源服务器；
c）Client：
第三方应用客户端；
d）AuthorizationServer：
授权服务器。
6.1.2.2JWT
JWT是一个开放标准（RFC7519），它定义了一种紧凑且独立的方式，用于在各方之间作为JSON对象安全地传输信息。
此信息可以通过数字签名进行验证和信任。
JWT可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。
6.1.2.3SpringSecurity
SpringSecurity是一个能够为基于Spring的企业应用系统，提供声明式的安全访问控制解决方案的安全框架。
它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了SpringIoC，DI和AOP功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
6.1.3认证服务
6.1.3.1认证服务场景
认证服务提供以下三种场景的认证能力：
a）内部统一门户认证；
b）客户端应用认证；
c）开放授权认证。
6.1.3.2内部统一门户认证
内部统一门户子系统为医保局业务经办工作人员提供统一登录入口，认证服务能提供统一的身份认证能力和单点登录服务（详见6.2）。
6.1.3.3客户端应用认证
公共服务子系统涉及移动APP、网厅、短信、微信/小程序、自助终端等客户端，认证服务提供客户端统一身份认证能力。
如图8所示，认证服务提供的客户端统一身份认证流程如下：
a）用户登录客户端；
b）客户端向认证服务请求认证；
c）认证服务使用密码模式进行认证；
d）认证服务认证通过，生成JWT格式的access_token，返回给客户端；
e）客户端存储JWT，返回登录成功；
f）用户在客户端进行后续操作；
g）客户端携带JWT向API服务请求API接口；
h）API服务验证JWT的有效性，验证通过则执行后续逻辑，返回结果；
i）客户端向用户展示结果。
图8客户端应用认证流程
6.1.3.4开放授权认证
基于OAuth标准，认证服务能提供开放开发授权认证的能力。
如图9所示，开放授权认证流程如下：
a）用户（ResourceOwner角色）向第三方系统发起请求；
b）第三方系统（Client角色）向用户返回用户授权认证操作；
c）用户输入平台认证信息，向认证服务（AuthorizationServer角色）请求授权认证；
d）认证服务认证通过，生成code，并跳转到授权确认页面；
e）用户同意授权；
f）认证服务生成code并跳转到重定向页面；
g）第三方系统使用code请求认证服务的token接口；
h）认证服务生成JWT格式的access_token并返回；
i）第三方系统本地存储access_token；
j）第三方系统后续使用access_token向开放资源服务（ResourceServer角色）请求开放资源，并经过处理后展现给用户。
图9开放授权认证场景
6.2单点登录服务
6.2.1实现方式
单点登录（SingleSignOn）服务是指在多个相互信任的应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的服务。
系统采用Session共享方案来实现单点登录。
共享Session可谓是实现单点登录最直接、最简单的方式。
将用户认证信息保存于Session中，即以Session内存储的值为用户凭证，这在单个站点内使用是很正常也很容易实现的，而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题，在应用体系简单，子系统很少的情况下，可以考虑采用Session共享的方法来处理这个问题。
Session服务用于存储与用户相关的数据，默认由Web容器进行管理。
单机情况下，所有用户的Session数据由一台服务器持有，不存在Session数据不一致的情况，但在分布式情况下，用户的前后两次请求可能会转发到不同的后端服务器上，如果不进行Session共享会出现Session数据不一致的情况。
因此打造一个高可用的分布式系统，应将Session管理从容器中独立出来成为统一的脱离容器的Session存储机制。
HSAF框架的Session管理通
过基于Redis服务器的方案来实现Session的共享存储。
6.2.2单点登录流程
如图10所示，单点登录流程如下：
a）接收用户认证信息；
b）将用户认证信息提交认证中心进行认证；
c）认证成功生成有效凭证并通过用户中心获取对应用户详细信息；
d）将用户信息写入Session对象，保存至Session共享服务中；
e）通过Session共享服务获取认证服务共享的Session信息，完成单点登录；
f）
通过用户过滤器获取当前登录用户，并将用户信息及所属机构信息写入线程对象HsafContextHolder中。
图10单点登录流程
6.2.3应用要求
为保证医疗保障信息平台各个业务子系统Web应用的Session共享，避免出现因跨域导致的Session不能共享问题，各业务子系统Web应用应配置相同的域名。
Session共享服务应使用独立的缓存服务器进行存储，与业务使用的缓存服务器完全分离，互不影响。
6.3全局ID序列服务
全局唯一序列号生成是在设计一个分布式系统时常常会遇见的需求。
在分布式系统架构
下，尤其是数据库使用分库分表的时候，数据库自增主键已无法保证全局唯一。
HSAF框架提供了统一的组件，实现全局ID序列生成服务，可被直接调用生成全局序列
ID。
6.4事务管理
6.4.1实现方式
HSAF框架使用了Spring框架的事务管理机制。
Spring支持编程式事务管理和声明式事务管理两种方式。
声明式事务管理是非代码侵入式的开发方式，这是Spring所倡导的开发方式。
声明式事务管理也有两种常用的方式，一种是基于tx和AOP命名空间的XML配置文件，另一种就是基于@Transactional注解。
6.4.2应用要求
为了方便系统灵活地进行事务隔离等级、事务传播行为、事务超时、事务回滚规则等参数的控制，应使用基于XML配置文件的声明式事务管理方式，不应使用基于@Transactional注解的方式。
另外，根据分层设计，Service是服务的发布层，BO层是具体的业务逻辑实现层，Service层提供对外服务的接口，并调用BO层完成接口任务。
架构要求事务只能声明在BO层。
升级会员 