ESB_API中心_微服务架构

Q：

为什么医院要从集成平台架构切换到微服务架构？为什么医院要选择微服务架构？

A：

首先从产品的本质上来说，ESB和微服务架构解决的是同一个问题：功能和业务的解耦。甚至在解决的思路上都是相同的，将接口从原有的产品功能中剥离出来，进行单独的通信和管理。两者的差距是技术架构的实现。

ESB的历史角色

从医院信息化的发展角度来看，集成平台(ESB)的出现实质上是对单体应用在开发、运维、运行进入瓶颈，无法满足医院发展需求下出现的产物。

在此之前，医院首先是以HIS为单体应用满足医院信息化，HIS的架构进入瓶颈无法满足医院业务需求后，医院通过增加新的软件产品来满足自身发展需求，从而形成了HIS、EMR、LIS、NIS、PACS为主体的业务系统，而系统之间同样通过接口进行交互。随着互联网和IT技术的整体发展，医院的信息系统与日俱增，缺乏总体设计，通过系统间点对点接口进行通信，导致了医院信息化管理的巨大隐患。在这样的大背景下，ESB作为总体架构的承载物登上历史舞台。无论是MQ、Ensemble还是Orin等，ESB的出现实质上是将点对点的通信转移到了ESB的身上，由ESB统一完成医疗信息系统之间数据的传递和转发。

医院ESB的局限

在医院使用的ESB(以MQ为例)，完成的是消息提供方和消费方之间的传递，消息的提供方会将服务注册和发布在ESB中，而消息的消费方则根据实际业务需要调用和消费所需的消息。而考虑到医院的业务量，ESB并不想成为业务的瓶颈，因此在实际应用中，ESB上的服务编排一般

只完成基于数据，供需双方的简单传递，而并不实际通过服务编排来完成基于业务流程的设计。这也导致现阶段的集成平台“鸡肋说”：集成平台只完成了业务转发的工作，而接入MQ带来的开发成本，与业务间的接口改造成本也并无大量减少，似乎只完成了互联互通测评这一需求，并没实现系统架构的统一管理，并不能实现医院信息化的“精简”。

API中心

为了解决ESB鸡肋问题，出现了API中心的概念。API中心的目的在于激活集成平台中已经完成注册的服务，通过以“业务”为流程的服务编排设计，实现有业务意义的服务“复用”。ESB本身能解决不同格式、不同标准、不同语言的数据传递，因此API中心的核心在与服务网关的构建。服务网关的核心价值在于能够通过对已注册服务的“复杂”调用，让集成平台扮演服务提供者和服务消费者的角色。

但是，API中心的建立会使得集成平台快速成为业务瓶颈，因为有大量业务会通过集成平台完成服务的重排和发布，这并不符合现有集成平台的建设初衷。而随着医院业务的快速扩展，完全依赖业务组装和简单开发形成的服务，非常依赖业务系统服务的稳定性和健壮性，而这部分并不在集成平台现有的管控范围内，集成平台极有可能成为医院业务发展的瓶颈。

微服务架构

微服务架构和集成平台都是在解决相同的问题，但有别于集成平台的“中心化”解决思路，微服务架构采用的“去中心化”。而即使“去中心化”，微服务架构仍然需要“服务注册中心”这一“中心化”产品，只是在微服务架构下，服务注册中心采用类似“透明代理”的解决方案，以轻量化的方式完成了服务的转发。随着ServiceMesh模式的推广，可以理解为将“ESB”的相关功能打散拆分成每一个节点中的"ServiceMesh”模块，每一个节点各自完成原本由ESB完成的转化、通信等工作。

在微服务架构下，服务编排和服务的增加都是由“节点”提供运算和处理，因此服务注册中心不会成为业务的瓶颈，同时由于容器化及容器治理的存在，“节点”的稳定性可以得到较好的保障。而服务的发布、注册和调用都由服务注册中心完成调度，因此服务的编排和扩展都显得更为简单，理论上不存在业务瓶颈的出现。

结论

通过比较，从医院业务的发展和技术发展的趋势上来看，微服务架构是未来的必然选择。首先，医院业务的快速发展，注定信息化的需求会不断膨胀，而最终超过现有架构（单体或集成平台）的承受能力，其次，微服务技术作为当前整体技术的发展趋势，也将成为IT领域的下一个常态，这两点的满足仅仅是时间问题。因而，在当下阶段，选择微服务或者不选，其核心在与当前医院愿意投入的成本。微服务架构在启动的初期，需要大量的经济成本和专业培训成本，而到了后期，整体产品的扩展的成本则大幅下降，以“服务”计。启动资金决定医院当下阶段的选择。

API中心可以作为医院微服务化的过度阶段解决方案，完成“微服务理念”的建立和技术架构差异带来的业务隔阂，但是从整体情况来看，API中心并不能改变ESB的整体运行模式和瓶颈，并不能作为长期方案使用，应当尽快完成微服务架构的迁移，否则极易成为医院发展的瓶颈