浅谈数据交换技术架构的演进——从SOA到微服务

摘要 

      采用SOA架构实现的ESB类技术型中间件和利用API与云原生技术相结合的微服务架构，对于不同的医疗集成环境下都有各自的长处，而随着新技术逐渐融入医疗信息化行业，医疗机构的系统和应用功能逐渐在云上部署，微服务架构在应对变化多样和快速迭代的集成场景时有着天然的优势。 

      新型的集成中间件从业务级和自身架构两个维度上均实现了微服务化的能力，把集成技术带到了一个全新的高度。 

      近年来随着医疗信息化建设的不断深入，医疗机构的系统和应用功能逐渐在云上部署，医疗业务场景需求的迭代也越来越快，为了适应这些需求变化，作为医疗机构互联互通核心之一的集成技术，其架构风格也在从SOA向着微服务演进。 

      另外，在2020版医院信息互联互通标准化成熟度测评方案中，对于集成平台在信息整合技术的备注中也提到“在总线基础上探索对微服务的环境搭建”。 

      我们通常讨论时，会把SOA和微服务架构放在一个层面，谈的是架构风格和方法； 而对于ESB和微服务网关是另一个层面，谈的是实现工具或组件。 

SOA在医疗HIT中主要是解决 

跨应用的业务协作和数据共享的问题 

      Service-oriented architecture，即面向服务架构，简称SOA。 维基百科上认为SOA“并不特指一种技术，而是一种分布式运算的软件设计方法”。 目前SOA被广泛应用于各类软件工程相关的领域。 

      而在医疗行业中，由于医疗机构内细分业务很多，每个专业领域都有其对应的系统进行支撑，如果站在大HIT角度把整个机构应用作为一个“系统”，那么有的业务或者能力就会存在跨应用，甚至跨机构的协作。 通过SOA的架构设计和建设思路，能够从更高维度进行规划和建构，把原先散乱、无规划的系统间网状结构，梳理成规整、可治理的系统间星形结构。 

SOA一般采用ESB来实现系统间的数据交换 

      Enterprise Service Bus，即企业服务总线，简称ESB。 维基百科上的解释是“由中间件基础设施产品技术实现的、 通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。 企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。 ” 

      在医疗行业中，ESB通常作为集成平台的数据交换技术之一，实现服务共享和调用，对各系统进行解耦。 同时降低因服务过度依赖导致整体交互复杂度过高，在系统升级和迭代时所带来的风险。 

微服务——集成技术架构的演进方向 

什么是微服务？ 

      先来看看维基百科对微服务的定义： 微服务（英语： Microservices）是一种软体架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程式，各功能区块使用与语言无关 (Language- Independent / Language agnostic）的API集相互通讯。 

微服务架构强调的是服务职责单一化和轻量化 

      随着各类新技术逐渐融入医疗行业的大环境，医疗机构对集成技术的应用逐渐从院内走向院外，部分功能甚至直接面向患者群体，互联网+的应用越来越多，业务中台、数据中台等新兴的构建方式也被许多厂商采纳。 

      从业务层面看，微服务技术更加适合逻辑抽象，能提高服务复用能力，实现功能、版本的快速迭代，小模块的版本升级对医院的影响也非常小，并在服务治理和监控上面更具有优势。 

      而在运行层面上，各个服务之间更加独立，更适合容器化云原生部署，能有效的避免由于单个服务异常造成连锁反应使得整体宕机。 

在医疗行业中，集成技术架构的微服务主要在两个维度得以体现： 

1. 业务级的微服务开发能力——能够构建医疗业务的微服务： 

      集成中间件是一个工具，实现业务级的微服务是他的一个核心功能和能力体现。 集成技术就好比一把刀，最关键的作用就是可以对服务根据需求进行拆分和切割，形成颗粒度更小的微服务。 由于各系统业务场景不同，使用到的集成技术也不一样，有的业务像蛋糕要用刀切，有的业务像纸张要用剪刀剪，有的业务像啤酒瓶要用开瓶器等等。 

      不过只要集成中间件有切割业务和服务制成的功能，最终形成基于API的微服务接口，提高应用对需求的快速响应能力，就意味着集成中间件能构建微服务，具备“业务级微服务”的建设能力； 

2. 架构级的微服务体现——集成中间件自身的微服务架构： 

      实现业务级微服务能力是集成中间件的功能需求和核心能力，那么其自身的技术架构决定这种能力的体现是否能更好的发挥。 

      在面对小规模的集成需求和服务治理时，可以采用类似瑞士军刀这种架构，具有小刀、剪子、开瓶等各种能力在物理上聚合起来，方便携带，在应对一些小规模的集成需求使用起来非常方便，可以快速实现微服务的开发，但在安装部署以及运维上功能的主体仍然合在一起，在应对大规模的集成需求时，就会显得势单力薄，一旦主体损坏，整个刀具都会用不成。 

“瑞士军刀”式的集成技术架构 

      而另一种方式则是采用云原生的微服务架构，把集成中间件的各个组件乃至开发出的业务级微服务进行拆解，利用容器进行打包组合，各组件之间相对独立，通过服务进行交互。 
 

      这种架构下，就好比将刀具放在置物架中，不同刀具器皿之间完全解耦独立，要用哪个功能就能直接用，升级改造或者调整时也不用担心影响到其它功能，出现新功能时也可以通过扩展能力挂在这个置物架上。 

置物架式的自身架构级微服务架构 

      支持架构级微服务的集成中间件，最大的优势在于其开发出来的每个业务级API服务或者集成任务均可独立运行在单个或多个容器中，互相隔离互不影响，所需的计算资源也可以根据需求独立分配。 

SOA和微服务分别适合什么医疗场景？ 

      由于SOA和微服务架构上的差异，可以根据其特性在面对不同医疗集成或数据交换需求时选择使用： 

      当面对生产和消费主体都比较明确，并且业务相对固定的时候，其服务协同或者信息交互的定义变化不大，比如实现机构内系统间互联互通时，可采用“中心化”的ESB作为其能力载体，实现有限计算资源下的服务编排和数据转换。 

SOA的“中心化”系统架构 

      而有些新兴的医疗业务场景，其消费主体不明确的时候，如开放类平台的互联网+的业务或中台型需求时，集成中间件需要快速的服务开发迭代能力。 另外交互流量上也存在较大的弹性和不确定性，需要资源能够动态延展，同时还需要服务治理、监控、调度、限流等功能进行协助，此时集成中间件采用云原生的去中心化微服务架构就是更为合适的选择。 

微服务的“去中心化”系统架构 

Odin对微服务架构的前瞻性支持 

      早在三年多前，Odin就曾在《下一代医疗集成平台的三个特征》一文中强调了微服务会成为未来医疗集成平台的核心特征之一，并推出了“Odin引擎集群版”和“Odin云原生平台Odin NeXT”，实现了在集成技术领域的突破。 

      其中，“Odin引擎集群版”的业务级微服务能力包括业务集成、API网关和RAM在内的全生命周期生产力工具，目前已在国内多家大型三甲医院、医疗集团落地使用。 

      而“Odin云原生平台Odin NeXT”则是基于Kubernetes（K8s）分布式容器化技术，进一步实现了自身架构级的微服务化，目前已作为“全球首个基础医疗数据互操作平台”——ALEX（Application Layer EXchange）的核心数据交换中间件，实现各类医疗数据和记录在多个应用程序、全科医生、患者、保险公司之间的实时、安全的共享和互操作，具有极高的快速响应下的并发能力、极强的业务稳定性以及实时动态扩展能力。 

结语 

      由于历史原因，医院信息系统中存在着大量通过异构方式集成的系统，确实需要通过基于ESB实现的SOA架构对复杂多样业务逻辑进行梳理。 但随着业务不断上云，应用都部署在云环境上，微服务架构的应用范围会越来越广，集成平台的角色也将从仅作为ESB等数据交换能力的承载平台，逐步演进为服务治理、调度、监控、管理的平台，更好地服务于微服务架构下的医疗集成场景。