医疗信息化中台技术架构方案优质PPT.pptx
- 文档编号:14089469
- 上传时间:2022-10-18
- 格式:PPTX
- 页数:46
- 大小:3.53MB
医疗信息化中台技术架构方案优质PPT.pptx
《医疗信息化中台技术架构方案优质PPT.pptx》由会员分享,可在线阅读,更多相关《医疗信息化中台技术架构方案优质PPT.pptx(46页珍藏版)》请在冰豆网上搜索。
按照技术架构的层次分解固化下来的技术层次调用编码,可以在抽象层面上实现技术调用闭环,它是应用编程的基础核心代码,应用系统在框架代码的基础上扩展出业务逻辑,形成应用系统。
总体架构思路-我们要统一什么?
视图层,业务层,数据层,控制层(技术框架)代码来保证,技术架构与技术框架的关系技术架构分层结构、层次间调用关系(规范来保证),总体架构思路-国家局实现什么?
国家局软件版本适配型框架适配阿里云适配腾讯云适配一款第三方主流分布式技术,总体架构思路-地方适配,地方要提供PAAS、IAAS,国家局下发版本已经适配的PAAS+适配框架,国家局下发软件版本,总体架构思路-地方适配,地方要具备:
技术架构中要求的PAAS层能力,地方需按照统一标准规范构建云平台的平台服务(Platform-as-a-Service,PAAS)能力,应包括分布式服务、消息队列服务、分布式缓存服务、分布式日志服务、分布式数据访问服务、关系型数据库、非结构化存储服务、离线计算引擎、实时计算引擎、流计算引擎等。
能够支撑PAAS层服务的IAAS层基础设施,技术架构的变化,全面使用分布式架构云的技术本质:
分布式计算云上的技术:
横向扩展,性能线性提升,VS,技术架构的变化,从单体架构到微服务架构,单体架构的可维护性及复杂度随着系统规模的增加变得越来越难以控制水平扩展性的成本较高,要整体克隆出一个系统来,通过负载均衡的技术来分担计算压力对压力大的模块,无法分拆出来进行单独扩展过去我们把应用的业务逻辑大量写在数据库中,中间层的压力不大,这种架构还可以应付。
如今大量的业务会在中间层完成,中间层的不同的业务模块对硬件的需求并不一样,有的是CPU计算密集型,有的是内存使用密集型,有的是IO密集型,这样在做横向扩展时我们如果克隆出一个应用,那么硬件就要CPU密集、内存够大、IO够强,成本很高。
单体架构,技术架构的变化,从单体架构到微服务架构,微服务架构(通过服务的方式解耦、隔离业务变化)微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。
服务与服务之间采用轻量级的通信机制互相沟通,每个服务都能独立的部署到生产环境之中。
单体架构,微服务架构,技术架构的变化,从中心化架构到去中心化架构,传统”中心化”系统架构,服务调用者服务调用者,企业服务总线,服务提供者,服务提供者,服务调用者,服务提供者,服务调用者,服务提供者,服务提供者,服务调用者,“去中心化”系统架构,从集中式走向分布式,小型机为中心,X86架构虚拟化可扩展,关系型数据库集中存储,分布式存储多种存储策略,单体应用大量使用存储过程,中台化微服务化应用可弹性伸缩,基础资源层,数据资源层,应用层,目录contents,1,2,3,总体技术架构思路,中台设计,总体技术架构设计,总体技术架构设计-概念图,医疗保障业务系统:
所有业务应用都必须基于医疗保障应用框架(HealthcareSecurityApplicationFramework,简称:
HSAF)支撑下,完成业务应用。
HSAF框架:
包含核心框架和适配框架两部分。
核心框架采用分布式云架构,封装核心云支撑服务适配接口,用于实现云产品适配设计。
总体技术架构设计-概念图,适配层:
基于HSAF的适配框架技术,将应用层依赖的分布式技术与具体厂商的分布式技术进行适配,实现应用层可以适配多家厂商的分布式技术。
云支撑服务层:
基于云基础设施,为应用层提供通用的技术支撑服务,包括分布式服务、分布式缓存、分布式数据访问、分布式日志服务、非结构化存储和消息队列、离线计算、实时计算啊、流计算等。
云基础设施层:
采用云架构,在物理设备基础上,实现计算资源、存储资源、网络资源的动态管理和资源调配。
总体技术架构设计-概念图,云基础设施层:
采用云架构,在物理设备基础上,实现计算资源、存储资源、网络资源的虚拟化及动态管理和资源调配。
总体技术架构设计逻辑图,适配层,前端展现层,移动设备,UI组件,其他客户端,控制层(SpringMVC),SpringAOP拦截器,安编全码过过滤滤器器,控制器,Controller,业务处理逻辑层,分布式服务层(微服务),业务模型层(事务控制),业务处理层,BO,数据访问层,DAO,数据访问层,Mybatis,持久化层,ORMapping,数据访问代理层,DAAL,分布式数据库层SQLDBSQLDBNOSQLDB,分布式缓存,分布式消息队列,分布式服务注册中心,分布式中间件服务,分布式对象存储,服务网关,分布式配置中心,分布式任务调度,分布式数据库数据传输服中间件务,服务接口,本地服务Service,远程服务Service,.分布式日志,http,json,操权访会装作限问话载日校统过上志验计滤下拦拦拦器文截截截器器器,xxxPAAS,业务中台,SessionCurrentUser,.,ThreadLocalH.safContext,异常统一处理,总体技术架构设计逻辑图,HSAF-COREMVC框架,过滤器,分布式服控制器务接口,基础技术服务缓存框架安全框架框架,HSAF-ALI,HSAF-Tencent,HSAF-Uni,目录contents,1,2,3,总体技术架构思路,中台设计,总体技术架构设计,业务中台与数据中台,业务场景交易处理数据生成用户触点,全域数据存储数据萃取数据处理面向场景算法迭代,什么是中台?
中台是由业务中台和数据中台构建起的数据闭环的业务体系,实现以数字化资产的形态提升政府快速服务能力。
什么是业务中台?
共享业务中心:
按照高内聚、低耦合原则,把共享的业务服务和依赖的数据资源进行聚合,构建共享业务中心。
共享业务中心拥有独立数据资源,对外提供业务服务,有独立运营能力,能独立部署,可通过不断的迭代进行自我完善。
将医疗保障信息平台上各个子系统之间可共享(复用,统一)的业务能力抽取出来,形成不同的“共享业务中心”,如:
认证中心,负责共享的系统认证相关服务。
业务中台:
医疗保障信息平台上所有的“共享业务中心”的集合称为“业务中台”,支撑全领域业务能力复用(共享、统一)。
新系统建设不用从头开始,可以从业务中台选择适用的共享业务中心的服务,即可实现复用又可以避免“烟囱”式系统的建设。
业务中台通过核心能力沉淀支撑上层应用系统的快速迭代和创新,从而解决系统扩展能力低,业务功能重复建设、系统稳定性差、无法支撑高并发等问题。
业务中台的本质,共性与个性分离,业务中台是一个复合体,组织,业务,技术,业务能力中心需要分布式架构支撑思想,方法论,保障业务稳定复用应对数据不一致性激活服务创新活力,中台不是平台,业务中台的技术支撑,功能需求,高可靠性,可扩展性,高可用性高性能安全性可管理性,高性能:
高并发,低响应时间、高吞吐量、高资源利用率等等;
比如HSF协议比Dubbo协议序列化性能提升30%。
MQ支持高性能毫秒级消息通知系统,海量消息堆积能力;
可扩展性:
垂直扩展及横向扩展的能力,线性扩展边际效应不衰减;
非功能需求,分布式消息能力:
支持分布式队列模型,如RMQ,阿里MQ;
分布式服务能力:
服务RPC协议调用能力,服务注册和发布的基本功能,如Dubbo,EDAS;
分布式数据能力:
实现数据的分布式存储能力,分库分表,读写分离等功能,如Mycat,DRDS;
服务支持应用容器,应用全生命周期管理和弹性伸缩。
分库分表支持分布式事务,分布式复杂查询,MySQL兼容,平滑线性水平伸缩,MQ支持分布式事务消息服务;
可管理性:
具备规模化的运维及管理的能力,线上管控;
服务框架支持数字化运营,链路监控、服务降级、限流等;
分库分表工具,支持优秀的数据库运维体验,MQ支持消息全息排查。
安全性:
针对金融行业安全需求,完善安全,支持等保相应级别;
高可用/高可靠:
高可用,容灾能力,单元化及异地多活能力;
分布式架构需求,中台的高可用架构,链路负责人,服务提供者,谁调用了我的服务?
在什么链路下调用,调用是否合理?
调用趋势怎样?
产生的瞬间峰值有多少?
我的系统是否能支撑,是否要扩容?
我依赖了哪些应用、哪些服务?
整个链路的依赖路径是怎样的?
哪些容易出错,哪些是链路的处理瓶颈?
这些依赖如果出错,会有什么影响?
分组:
业务差异化对待限流:
不超过系统限定水位鉴权:
对服务权限控制压测:
系统能力的估算,治理手段,治理手段,弱化:
容忍异常,业务不中断降级:
对故障分支进行短路引流:
分流或切换到其他通路,优化:
提高瓶颈点和毛刺的性能,分布式服务治理,分布式高可用,分布式事务,分布式服务,总体应用架构设计,页面访问,APP,互联网区,负载均衡,服务网,关,分布式应用运行环境,业务专网区,网,闸,负载均衡,EDAS运行环境前端业务应用,服务网关,.,.,业务经办,互联网,医保专网,省级系统,宏观决策大数据应用系统,运行监测子系统,大数据运行环境,政务外网,政务外围系统,业务中台,统一认证中心,用户中心,政策中心,结算中心,机构中心,支付中心,险种中心,电子档案中心,商品中心,风控中心,消息中心,账务中心,报表中心,.,边,界,网,关,边,界,网,关,药品和医用耗材招采管理子系统,公共服务子系统,内部统一门户子系统,内部控制子系统,基础信息管理子系统,医保业务基础子系统,跨省异地就医管理子系统,医疗服务价格管理子系统,基金运行及审计监管子系统,医疗保障智能监管子系统,信用评级管理子系统,支付方式管理子系统,业务中台,统一认证中心,用户中心,商品中心,.,数据中台,大数据离线大数据实时计算计算,数据集成,数据治理,数据服务,前台,中台,公共服务区,核心业务区,如何建设业务中台,业务分析,领域模型设计,中心划分,应用划分,库表设计,开发,业务分析,明确需求领域模型设计,明确实体关系中心划分应用划分库表设计,分库分表应用开发,服务化松耦合原则服务设计原则服务颗粒度原则服务的无状态原则服务高可用建设原则,方法,原则,业务中台的总体设计,内部统一门户系统,运行监测系统,医疗保障智能监管系统,内部控制系统,基础信息管理系统,药品和医用耗材采购一体化管理系统,宏观决策大数据应用系统,医疗服务价格管理系统,基金运行及审计监管系统,支付方式管理系统,跨省异地就医管理系统,信用评价管理系统,公共服务系统,医保业务基础系统,电子档案中心,统一认证中心,用户中心,政策中心,支付中心,风控中心,险种中心,商品中心,机构中心,工作流中心,账务中心,结算中心,消息中心,对14个应用系统服务能力进行提炼,抽取出60多个共用服务。
基于业务内聚性形成15个业务中心,业务中台的总体设计,业务中台的总体设计,核心业务区核心业务区包括15个业务中
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 医疗 信息化 技术 架构 方案