从软件架构发展谈业务集成技术演进与展望（上）

引言

　　应用集成技术是市场上被广泛使用的，也是充斥着术语和概念的一个技术领域。集成平台、消息引擎、消息中间件、集成引擎、集成中间件、企业服务总线(ESB)、API网关、API管理…...很多概念与名词。到底它们是什么意思?有什么区别?哪种技术适合解决哪种集成问题?

　　业务集成的需求和技术的演进是紧随业务系统的软件架构发展而发展的。通过小结软件架构的发展，我们更容易梳理业务集成技术的演进、更容易看清楚各种集成架构的优势和未来发展方向。

软件架构发展简史

　　01大型机架构：上世纪60-70年代。

　　大型机负责数据存储、业务逻辑处理、数据展现等所有工作;客户端只是一个终端，基本上就是键盘加上显示器，负责输入、输出。大型机架构的优势是简单，但显然可扩展性很差。

　　在大型机时代，几乎没有集成的需求。

　　02客户端/服务器(C/S)架构：上世纪80年代到90年代。

　　服务器负责数据存储和处理，以及服务器端端业务逻辑处理;客户端(PC)负责客户端逻辑处理、数据验证、数据展现等工作。

　　客户端(PC)分担了很多工作，且数量众多，因此它是一个分布式架构，可扩展性提升。但维护客户端应用，例如升级等带来了很大的管理维护成本。现在很多企业核心应用，例如ERP、HIS都是当时在这个架构下开发出来的，基本都是单体架构应用，业务逻辑间耦合度非常高。应用之间需要做业务的共享交换，主要通过点对点方式集成，也催生了集成技术，尤其是以消息交换为基础的、以消息队列技术为载体的集成方式。在这个时期，HL7组织开发了HL7 V2.x的医疗消息交换标准。

　　03三层架构：上世纪90年代中后期至今。

　　三层架构是展现层(用户界面)、应用层(业务逻辑)和数据层(数据)三层架构。

　　这里的三层架构不仅指软件功能的层次，而且指软件运行的基础架构的层次。由于在软件功能和基础架构上的分层和分布式设计，三层架构应用通常有很好的可扩展性和可维护性，虽然仍是单体架构应用，但它降低了业务逻辑的耦合度和基础架构层次间的耦合度。另一方面，三层架构让整体复杂程度上升了。分层架构和不断涌现的技术实现，如.net、java、EJB…...使这些应用间的互相调用变得越来越复杂了，接口引擎或集成引擎应运而生，并在这个时期发展壮大起来。它们要解决这么多技术平台的连接问题，适配器是主要手段。

　　04面向服务架构(SOA)：上世纪90年代末期至今。

　　前面的所有架构，基本都是单体架构模式 – 也就是孤岛模式，业务耦合度高而难以拆分，代码复用性低。不同应用中有大量功能重复的业务逻辑代码和数据，例如医疗行业的患者管理，几乎每个科室系统都有。这不但造成了需要同步的数据越来越多，更造成了数据互相冲突、运行效率降低、运行成本增加。代码跨业务、跨语言、跨平台复用成为快速满足业务发展的需求与趋势。以服务的方式封装和复用软件组件，然后可以敏捷地重新组织这些服务快速形成新的应用，SOA带来了软件架构上的革命。

　　每个服务都封装有数据和逻辑(代码)，以提供独立的功能，服务之间高度松耦合。而采用XML作为数据格式、以WSDL标准描述服务、以SOAP协议作为交互方式，面向服务架构使不同技术栈的差异对服务透明，使服务在任何技术平台上都可以使用。

　　随着SOA架构的逐步采纳，企业环境里有了越来越多的服务，企业服务总线(ESB)发展起来。它是一个中心化的软件组件平台，将企业环境中的服务注册在总线上，并协同这些服务。ESB通常借助消息引擎、业务流程引擎、数据转换引擎，执行服务路由、服务协同和服务间的数据结构转换。

　　更近一步，先进的ESB还融合了接口引擎的技术，有能力将非SOA架构的应用接口封装为服务并注册到总线，使其可以和其它服务一样被调用和协同。这些恰恰都是集成的目的，因此ESB成为一个重要的集成技术。

　　HL7在此期间，也推出了基于参考信息模型(RIM)的HL7 CDA临床文档标准用于文档交换和HL7 V3消息标准用于消息交换，它们都是基于XML的。IHE也推出了基于SOA架构的业务协同服务标准。

　　ESB中心化的部署模式意味着低维护成本和高一致性，但敏捷性不够。

　　05微服务架构(MSA)：2010年代开始至今。

　　微服务架构类似SOA，强调业务封装和复用、业务解耦，往往和SOA发生混淆。但今天的业务环境已经和10多年前不可同日而语了：

　　业务迭代进化速度上，越来越快;

　　业务范围上，传统的企业内部服务的围墙被突破了，越来越多的业务需要直接和上下游供应链打通，服务延伸到企业之外，直接面向客户。例如以前患者只能去医疗机构看病，医疗机构也只有患者的院中数据，现在不但有互联网医院，医院也需要院前、院后的患者数据和例如基因测序公司来的组学数据来支撑精准医学;

　　业务量上，随着传统业务围墙的打破，业务量越来越大，例如互联网医院和医疗物联网带来了大量的业务和数据。传统可扩展性已经难于满足，需要提供更灵活的、更细颗粒度的业务弹性;

　　部署模式上，云部署、容器化部署越来越主流。

　　而SOA架构技术上很重：复杂啰嗦的XML、沉重的SOAP协议、中心化的ESB架构，在当今追求敏捷性的今天显得力不从心，甚至从“赋能者”变成了“拖累者”。

　　微服务架构站在SOA的肩膀上，并且具有如下特点：

　　轻巧的JSON、轻量化的Restful API帮助微服务架构获得更好的性能，值得注意的是，API不等于微服务，API有可能是单体架构的API;

　　不同于严格分工、各司其职的的需求分析-设计-开发-测试-部署的瀑布模式(Waterfall)，微服务架构允许团队合作的持续开发、持续部署模式(CI/CD)，可以更快的响应业务需求，具有更好的敏捷性;

　　而云原生、容器化的特性又帮助微服务架构获得了去中心、高度的伸缩性和适应互联网时代的快速迭代能力;

　　重新组合微服务可以快速构建新的应用、满足新的业务;

　　适合打造软件即服务(SaaS)类型的应用。

　　因此越来越多的企业采用微服务架构战略支撑他们业务创新和数字化转型。HL7 在2014年推出了采用微服务架构的FHIR标准，并参考持续开发持续部署的方式，以成熟度模型为依据不断产生、优化FHIR资源和API。

　　微服务架构构建了一个跨业务域的、跨企业的、去中心的或多中心的架构，其中的API提供分子级的服务独立性， 快速增加、快速迭代、分布部署。不过，这让API的发现、访问、版本管理、安全管理、流量管理、测试等变得很复杂，例如应用访问这么多不同服务端点的微服务，如果后台微服务的端点改了怎么办?如果微服务升级怎么办?因此API网关应运而生。

　　API网关为API提供全生命周期的管理：

　　API的创建、发现与测试

　　API版本管理

　　API安全管理

　　协议和数据转换管理

　　API流量管理

　　API统计分析

　　API管理器在API网关基础上提供开发、管理、运维门户， 进而成为基于API集成的集成架构。它不需要中心化的消息引擎或服务总线，本质上是一个去中心化、应用于更紧密业务集成度的互操作方式。

　　(未完待续)

　　作者简介

　　乔鹏，InterSystems技术总监。自2004年加入InterSystems(系联软件)，历任售前工程师、技术经理、技术总监等职务，精通公司旗下Caché数据库，Ensemble集成平台，HealthShare统一健康档案，IRIS数据平台等明星产品，对于数据库、互操作性平台、数据中台、医疗相关标准以及集成平台解决方案，有着深刻的理解和十多年的行业经验，参与主导过百余家医院或者区域平台的信息化建设;同时他能够对CDR、临床决策支持、商业智能、机器学习等数据利用产品和方案有广泛的认识和丰富的实践经验。