某地医保知识库设计方案

某地医保项目实施方案2017年1月12日1系统功能1.1系统功能图1.2系统功能描述1.2.1引擎1.2.1.1系统权限因为引擎是供其他业务使用的，因此存在着调用和访问关系。那么在引擎中就需要有相应的模块控制那些业务可以访问，那些地址不能访问。而系统权限这里就做为系统访问控制中心存在。1.2.1.2数据聚合当数据流过引擎之后是多条数据同时进行处理的，这时审核完成之后，审核结果需要经过聚合处理，才能回写到数据库，这样才能保证回写效率。1.2.1.3数据监控在数据进行审核的各个阶段，以及现在所处的阶段，都应该明确。这时就需要监控每条数据所处审核节点。而数据监控模块，就是负责查看数据是否正常流转，流经那个节点。1.2.1.4规则配置数据很多并且分属不同类型，那么每种类型的数据都应该流经一批规则。那么那些规则可用，那些规则不可用。都需要在此处作为访问入口进入到配置表中进行配置。这里就是配置页面访问配置中心的访问入口。1.2.1.5数据分析此模块主要针对监控统计类规则而产生，主要是针对数据进行一定的智能化分析，从而达到简单的规则审核不能达到的目的，此模块会适当的采用智能化分析手段，具体算法需要根据具体的需求来决定使用。1.2.1.6数据路由技术功能点，因为单天处方数据大概在200万左右，数据量教大，我们针对数据在数据预处理时，进行了分表操作。那么在高并发场景下，各个线程在读取数据时，需要明确自己去那张表读取。那么就需要通过数据路由来决定需要读取表以及相应位置。1.2.1.7数据对象化技术功能点，数据在整个系统流转过程中，都是以对象方式进行传递，而以对象传递时，就会产生对象序列化等问题，对象序列化又是相对比较耗费资源的一种行为，因此这里重点解决对象序列化带来的性能消耗。1.2.1.8数据审核数据都需要进行审核，审核模块就是具体发起调用，读取配置文件进行具体审核的中心。他是发起者和调用者。在审核部分包含的71条规则，参见附件内容：1.2.1.9审核编排目前仅支持分类型的编排，能达到不同类型的数据，按照不同的预配置进行流转。而审核编排中心，就是可以通过修改配置文件等方式，来达到准实时的修改不同的数据需要流转的不同规则。1.2.2数据同步1.2.2.1数据传递从中间表获取数据，并且调用分拆和预处理模块进行相应处理后，同步到我们分拆后的表中，以便知识库引擎能高效的处理相应的数据。1.2.2.2数据分拆数据分拆主要指纵向分拆，从中间表同步数据后，我们会根据一定的业务和计算规则，将数据分别存储在多张表中。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部署架构图数据库Oraclenginx,静态缓存静态服务器AportalRedis集群/兼FTP集群redis_a物理主机1静态服务器Bnginx,静态缓存防火墙/交换机/硬件负载均衡设备负载均衡portalredis_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所需服务器列表序号数量用途备注11Oracle数据库服务24中间件服务（weblogic）部署系统，要求每个实例都能分配2G运存32nginx静态资源服务部署网站静态资源，以及上传的，用药说明的图片内容。42两个redis服务用于缓存知识库中部分内容，以及配置共享锁