某地医保知识库设计方案

某地医保项目实施方案2017年1月12日

1系统功能

1.1系统功能图

1.2系统功能描述

1.2.1引擎

1.2.1.1系统权限

因为引擎是供其他业务使用的，因此存在着调用和访问关系。那么在引擎中就需要有相应的模块控制那些业务可以访问，那些地址不能访问。而系统权限这里就做为系统访问控制中心存在。

1.2.1.2数据聚合

当数据流过引擎之后是多条数据同时进行处理的，这时审核完成之后，审核结果需要经过聚合处理，才能回写到数据库，这样才能保证回写效率。

在数据进行审核的各个阶段，以及现在所处的阶段，都应该明确。这时就需要监控每条数据所处审核节点。而数据监控模块，就是负责查看数据是否正常流转，流经那个节点。

1.2.1.4规则配置

数据很多并且分属不同类型，那么每种类型的数据都应该流经一批规则。那么那些规则可用，那些规则不可用。都需要在此处作为访问入口进入到配置表中进行配置。这里就是配置页面访问配置中心的访问入口。

1.2.1.5数据分析

此模块主要针对监控统计类规则而产生，主要是针对数据进行一定的智能化分析，从而达到简单的规则审核不能达到的目的，此模块会适当的采用智能化分析手段，具体算法需要根据具体的需求来决定使用。

1.2.1.6数据路由

技术功能点，因为单天处方数据大概在200万左右，数据量教大，我们针对数据在数据预处理时，进行了分表操作。那么在高并发场景下，各个线程在读取数据时，需要明确自己去那张表读取。那么就需要通过数据路由来决定需要读取表以及相应位置。

技术功能点，数据在整个系统流转过程中，都是以对象方式进行传递，而以对象传递时，就会产生对象序列化等问题，对象序列化又是相对比较耗费资源的一种行为，因此这里重点解决对象序列化带来的性能消耗。

1.2.1.8数据审核

数据都需要进行审核，审核模块就是具体发起调用，读取配置文件进行具体审核的中心。他是发起者和调用者。

在审核部分包含的71条规则，参见附件内容：

1.2.1.9审核编排

目前仅支持分类型的编排，能达到不同类型的数据，按照不同的预配置进行流转。而审核编排中心，就是可以通过修改配置文件等方式，来达到准实时的修改不同的数据需要流转的不同规则。

1.2.2数据同步

1.2.2.1数据传递

从中间表获取数据，并且调用分拆和预处理模块进行相应处理后，同步到我们分拆后的表中，以便知识库引擎能高效的处理相应的数据。

数据分拆主要指纵向分拆，从中间表同步数据后，我们会根据一定的业务和计算规则，将数据分别存储在多张表中。

1.2.2.3数据预处理

同步表中的数据是集合数据，拿到这些数据后，我们在写入我们的表中，可能会结合我们的表设计，进行相应的适配，这样讲数据进行适当的预处理后，以方便引擎部分能按照正常的逻辑进行相应规则的审核。

1.2.3规则配置中心

规则配置中心，主要是为了方便用户及时的启用、停用、变更部分业务规则。此中心主要面向用户操作。而规则配置中心需要通过规则引擎来访问配置表，变更相应数据。

1.2.4药品说明、法律法规展示引擎

因为很多药品说明都是以jpg文件的形式存储在磁盘上的，而此类数据又教多时，磁盘物理寻址就会变的缓慢，迟钝。因此在此引擎上主要管理此类小文件，以便快速寻址查找到正确的药品说明文件，以供展示。

2软件架构

2.1软件架构图

2.2软件架构描述

2.2.1用户交互层

引入互联网化界面设计元素，结合动态的后台服务，实现轻量灵活的用户交互展现，实现渠道统一，多屏一致的操作体验。交互层分为展示层与适配层。展

示层是呈现系统内容及形式的管理平台，负责接收用户请求，与适配层进行交互，根据返回结果，将返回结果加工成相应的展示内容。适配层是提供各种访问设备、外部系统接入的接口，它进行展示层与服务层进行协议转换，为系统提供页面加速支持、用户轨迹跟踪、用户访问控制关键操作控制等功能；

2.2.2中心化应用服务层

中心化的应用服务层是对核心服务能力的重新划分，是从服务分类、业务数据对象、业务过程等多角度、多维度进行的拆分。它介于上层用户交互层与下层分布式数据访问层之间，为上层服务编排层提供核心能力的服务，并通过下层分布式数据访问层实现与数据存储的交互。中心化的应用服务层能力由各业务中心的服务组成，并且统一提供给上层用户交互层进行服务注册、服务管理、服务调用、服务监控等；

2.2.3分布式数据访问层

分布式数据访问层是数据进行云化的关键，它介于上层应用服务与下层数据存储之间，是应用与数据进行交互的纽带。引入分布式数据访问层的主要目的是：实现应用与数据的分离、支撑数据层的分布式部署、提升数据处理的效率。分布式数据访问层主要完成对象管理、数据访问服务、数据监控管理三大功能；2.2.4数据分布式存储层

面向互联网化的应用架构和业务开展，使得数据的复杂性不断增加；同时数据呈海量化发展且应用对数据的访问提出了更高的并发要求。因此，为了解决新形势下的这种业务需求，需要对传统的数据层的部署架构进行重新设计，引入数

据的分布式部署架构，对数据按特征，类型等进行分层、分级和分类的分布式部署。数据分布式存储是为了解决数据在单一存储上的效率瓶颈,以提升数据访问效率，缩短应用到数据的访问时延，同时支持数据的海量存储和高并发,从而促进整个业务端到端的性能提升，增强客户体验；

2.2.5系统运行监控

运行监控管理对系统提供资源、服务的监控与管理。

2.2.6系统特点

四层架构在纵向上实现系统的水平扩展，横向上从紧耦合重量级应用，向松耦合弹性扩展的中心化架构演进，实现垂直可拆分，满足云化目标，系统架构体现以下特征：

2.2.6.1两个分离

实现客户交互与业务逻辑分离，界面开发突破以前以功能为中心的离散菜单模式，靠菜单驱动、靠操作人员来贯穿流程的方法，并将界面流的组织和管理下沉实现，界面只负责交互响应，通过页面组件和页面封装等方式实现快速的界面定制，可以实现网营界面合一，引入HTML5等实现界面技术，并实现多屏一致的操作体验。

实现应用与数据的分离，使系统具备水平线性的低成本扩展能力，通过业务分析和业务流程梳理，实现真正的业务流程的灵活编排。

2.2.6.2中心化、服务化、平台化

中心化：具备高内聚、低耦合的特征特点，实现中心和所辖数据的自治，中心化是CRM系统内架构调整的关键手段，不同中心的架构特征是相同的，技术是相似的，目的是为了采用分布式架构，实现水平扩展和X86部署。

平台化：应用与数据分离，实现动态水平扩展；系统核心服务统一治理与管控，实现“可见、可控、可管理、安全”的对内对外服务。

服务化：统一管理并对外提供标准化服务，解决的跨中心和跨系统的集成问题，汇聚了CRM的核心能力，实现了服务的编排和管理，提高了响应效率，为快速迭代开发和能力开放奠定了基础，同时降低了跨中心和跨系统的底层数据复制带来的数据一致性问题，以及直接数据访问带来的信息安全问题，还解决了内部服务开放的一致化和标准化。

2.2.6.3数据分布式

引入分布式数据访问层，实现分布式部署和水平扩展能力；支持多种数据存储技术适配，支持透明访问混搭的异构数据体系。实现低成本的容量平滑扩展。

按照业务数据类型、数据主从关系、一致性要求、数据规模和访问方式规划数据，分布式部署到关系型数据库、可分布部署的非关系型的数据库、内存数据库或内存缓存中。

根据数据特征，对数据进行垂直切分和分类管理。除安全级别高，上下游系统有持久化访问要求的核心数据仍采用传统RDB模式，其他数据均采用低成本实现与部署的数据管理技术。

3 应用集成

3.1 集成方案

3.1.1 部署架构图 数据库

Oracle

nginx,静态缓存静态服务器A portal Redis 集群/兼FTP 集群

redis_a

物理主机1静态服务器B

nginx,静态缓存

防火墙/交换机/硬件负载均衡设备

负载均衡

portal

redis_b 物理主机2

同步DMZ 域

核心域

3.1.2部署架构描述

系统在综合考虑用户并发及访问速度、数据安全、后期扩展等方面后，采用三层架构设计，保证无单点故障。包括：

A. 静态化展现层，该层将图片、文本等静态资源独立出来，在减轻后端动态服务器的压力的同时，也极大的提高了用户的访问速度。

B. 动态请求处理层，该层用来处理系统的动态请求，为系统的核心层。

C. 数据库，数据采用oracle高可用方案构建

3.2负载均衡

部署radware负载均衡器，负责对公网访问进行负载分发。

3.3静态化展示层

该层由两台或两台以上且应用部署完全一致的主机构成，由该层前端的负载均衡设备实现请求的均衡分发。该层不存在单点隐患，且可在不停服的前提下方便的进行横向扩容。

该层部署的应用包括：

A.Nginx，用作静态服务器，同时可兼做反向代理服务器。拥有极佳的稳

定性和高并发承载能力。静态化资源同步，使用rsync进行同步。3.4动态请求处理层

该层分为两部分，一部分为核心应用服务器集群，采用负载均衡模式构建；另一部分为其他应用服务器集群，采用HA模式构建。

A.核心应用服务器集群，由两台或两台以上且应用部署完全一致的主机构

成，具有部署方便、管理统一、便于扩展的优点。

B.其他应用服务器集群，这部分应用主要包括FTP、统一session管理、静

态化资源发布等应用，这类应用同时只能由一个实例对外提供服务，但

又需要对外提供高可用的服务，所以采用HA模式构建。多个应用共同

组成一个或多个应用包，然后对外通过浮动ip提供服务。

C.FTP资源，使用防篡改进行数据同步。

D.数据缓存使用redis服务，redis集群内各服务器间采用主从模式在热备

的同时实现数据同步。

3.5数据库

数据库依赖中心内部的oracle配置，这里不做要求。

3.6应用部署方案

静态化展示层和动态请求处理层，使用rsync进行文件同步，在后续部署方案中，不做特别说明。

3.6.1静态化展示层

静态化展示层需要进行两类配置：

A.配置加载静态资源文件路径。

B.配置反向代理数据请求url。

3.6.2动态请求处理层

动态请求处理层规划两台服务器，均需要安装jdk1.7。

A.负载由硬件负载均衡器完成请求分发。

B.Redis做主从配置，完成数据同步等工作。

3.7扩展方案

静态化展示层：nginx可直接支持横向扩展，扩展中只需要对新服务进行应用安装即可。

动态请求处理层：采用统一session管控。因此动态处理请求层可支持横向扩展。其中只需要新的服务器进行应用发布，负载均衡添加配置即可。

数据库层：依赖中心oracle管控

3.8应用监控

主要监控内容包括数据库、应用服务的可用性、对外交互接口的可用性、业务数据及时性和完整性等。

4系统要求

4.1所需服务器列表

序号数量用途备注

1 1 Oracle数据库服务

2 4 中间件服务

（weblogic）

部署系统，要求每个实例

都能分配2G运存

3 2 nginx静态资源服务部署网站静态资源，以及上传的，用药说明的图片内容。

4 2 两个redis服务用于缓存知识库中部分内容，以及配置共享锁