信息集成平台架构(上)

系统架构

架构选型

服务高并发、高性能

解决高并发、高性能采用方式是采用消息队列来解决，特别是分布式消息队列可以有效的解决业务增长问题，下图是主流的消息队列对比分析图：

上图可以看出，吞吐量比较好的两个消息队列是Kafka与Redis，都达到了10万级量，是比较好的消息队列选型方案。

上图也发现定两种消息队列都有同样的缺陷，不支持消息推送模式，在医疗行业应用时，为了解决实时性问题，接入系统获取平台消息模式采用的是推模式，这个在行业应用将会变成一个很大的问题。

另外，这些消息队列的管理功能其实都不强，只有少数针对开发人员的管理功能，针对业务应用级别人员提供管理功能就更好，如配置发布者能发布的消息类别、配置订阅者能订阅的消息类型、定义订阅订阅消息的过滤规则。

针对以上的情况，在架构设计时，除了考虑到消息队列高吞吐特性外，还要对不足的地方进行补齐，对于消息队列推送及消息队列业务人员的管理功能需要集成Kafka、Redis消息队列时，设计相关的功能与这些消息队列进行高度融合。

平台的消息队列架构选型时，采用Kafka与Redis双消息队列方案，根据业务类型可以选择Kafka或Redis消息队列作为消息队列的存储。

流式计算

消息交换由一系列任务计算驱动完成，主干流程为：接收消息、消息入库、消息订阅计算、消息推迟，在分布式计算中会把这些任务分布到不同的机器上执行，每个任务计算结果放入到消息队列中，等待下一个计算任务进行任务计算。

基于Kafka消息消息队列，采用Flnk流式计算工具实际任务计算是互联网大厂经过验证的方案。

Flnk特点：

1. 集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架，像 Apache Spark 也只能兼顾高吞吐和高性能特性，无法做到低延迟保障，Apache Storm 只能支持低延时和高性能特性，无法满足高吞吐的要求

2. 支持事件时间（Event Time）概念：在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时间。Flink 能够支持基于事件时间（Event Time）语义进行窗口计算，这种基于事件驱动的机制使得事件即使乱序到达，流系统也能够计算出精确的结果，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。

3. 支持有状态计算：所谓状态就是在流式计算过程中将算子的中间结果保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果，计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，极大的提升了系统性能

4. 基于轻量级分布式快照（Snapshot）实现的容错：Flink 能够分布运行在上千个节点上，通过基于分布式快照技术的Checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，Flink 能够从 Checkpoints 中进行任务的自动恢复，以确保数据爱处理过程中的一致性。

5. 基于 JVM 实现的独立的内存管理：Flink 实现了自身管理内存的机制，尽可能减少 JVM GC 对系统的影响。通过序列化/反序列化机制将所有的数据对象转换成二进制在内存中存储，降低数据存储大小的同时，更加有效的利用空间，降低GC带来的性能下降或任务异常的风险。

Kafka+Flink流式计算方案在高可用的情况下需要Hadoop支持，部署成本比较高，这种流式计算方案一般是在超大型医院或集团医院及大型区域部署时采用。

在一般三甲医院、二级医院院或小型区域部署平台时，选择Redis+zookeeper+job这种方案作为流式计算方案：

1、 Redis：Redis接收消息与存储消息；

2、 Zookeeper：任务状态管理与任务状态通知管理；

3、 Job：任务计算实现。

这种方案部署成本比较低、运维方案，也能实现秒级的流式响应速度，是一种经济实惠型的部署方案。

另外，这种方案设计时，考虑到一些特殊情况，zookeeper任务通知失败的情况，可以接合启用任务定时模式来实现任务的计算，这样就把流式模式与批量模式接合起来，实现消息的准确到达。

负载均衡设计

平台通过API服务接口对外提供服务，在高峰期时可以存在大量的并发请求，我们可以通部署大量的应用服务器来响应这些请求，如何分布这些请求到不同的应用服务器上执行，这个需要有做负载均衡器来处理，在方案设计时可采用硬件的方案，也基于软件的方案。

1、软件负载均衡解决方案：

在一台服务器的操作系统上，安装一个附加软件来实现负载均衡，如Nginx负载均衡它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。

2、硬件负载均衡解决方案

直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵，比如最常见的就是F5负载均衡器。

方案优缺点对比：

1、基于硬件的方式（F5）

优点：能够直接通过智能交换机实现，处理能力更强，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用

缺点：成本高，除设备价格高昂，而且配置冗余．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态。

硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）

2、基于软件的方式（Nginx）

优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。

缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。

综述：对平台应用环境来说，由于负载均衡器本身不需要对数据进行处理，性能瓶颈更多的是在于后台服务器，通常采用软负载均衡器已非常够用且其商业友好的软件源码授权使得我们可以非常灵活的设计，无逢的和平台相结合；如果资金允许，采用硬件F5也是可供先择的方案。

分布式任务与状态管理

平台中有不同的服务，如入库服务服务、订阅计算、推送服务等很多不同的服务，调度服务会把这些服务分布到不同的机器上运行，分布式任务与状态管理是分布式服务中需要解决的核心问题之一，在此领域中zookeeper是分布式任务与状态管理中的佼佼者。

Zookeeper特点：

1、最终一致性：客户端不论连接到哪个Zookeeper的哪一个节点，都会收到同一份状态。这是zookeeper最重要的性能。

2、可靠性：Zookeeper集群具有简单、健壮、良好的性能，如果消息m被到一台server接受，那么它将被所有的server接受。

3、实时性：Zookeeper保证client将在一个时间间隔范围内获得server的更新信息，或者server失效的信息。但由于网络延时等原因，Zookeeper不能保证两个client能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4、等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5、原子性：更新只能成功或者失败，没有中间状态。

6、顺序性：包括全局有序和偏序两种：全局有序是指如果在一台server上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

高可用

根据各种服务的特点，有些服务设计成集群Cluser模式，有些服务需要设计成高可用模式(Master/Slave)，高可用服务如下：

1、负载均衡器：部署两个KeepAlive，通过KeepAlive提供统一的对外服务IP地址。

2、 Redis：通过sentinel提供对外服务,同时通过sentinel选举Redis Master服务节点。

3、 Flink：JobManager要设计成高可用的状态，通过Hadoop部署成standaloneHA或Yarn集群模式，这种高可用依赖于Hadoop，所以Hadoop也需要部署成高可用的模式。

数据库

平台数据中心是一个综合性的概念，它由数据湖与基于数据湖之上的主题应用数据库组成。基于数据湖之上的主题应用的数据存储可由特定领域的数据库进行处理。如检索类应用数据存储可由ElasticSearch承担；基于知识图谱之类的应用可由Noe4J这种数据库处理。数据湖中的数据特点是持续增长的，而且不能把数据转存到别的地方，所以数据库的选型是十分重要的。

数据湖数据库选择由两种方式：基于商业的数据库与基于开源的数据库；数据库从分类来说分为以下三种：

1、传统数据库：Oracle、Mysql、Sql Server；

2、 NoSql指那些非关系型的、分布式的、不保证遵循ACID原则的数据存储系统，比较典型的是Hadoop、MongDB;

3、 NewSQL:这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性，比较典型的代表VoltDB、MemSQL、TiDB、Cosmos DB、Viess、oceanbase。

上面三种数据库分类实际上是三个不同发展年代的数据库产品，如果从传统数据库中选择数据库产品作为数据湖数据存储，从跨平台、组件丰富、体系先进，性能优异、安全性高等特性考虑Oracle由是不一二选；考虑到ACID、OLTP、OLAP、分布式等特征的话，NewSQL中的TiDB成为最优选择，而且TiDB是国产后起之领，在很多大型的互联公司使用，如美团、360金融、小米、知乎、东南亚最大电商Shopee等。

TiDB数据库特点：

1、水平扩展：按需扩展吞吐或存储，轻松应对高并发、海量数据场景；

2、高可用：基于 Raft 的多数派选举协议可以提供100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

3、云生态 SQL 数据库： 100% 的 OLTP 场景和 80% 的 OLAP 场景，对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。

架构概述

企业架构（Enterprise Architecture），简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。下图是信息集成平台的各架构图的之间的关系图。从最下层业务架构我们可以导出平台的逻辑架构，从逻辑架构图导出功能架构、数据架构、标准架构、安全架构，最上面是部署架构图。

业务架构

业务架构核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作。下图从集成业务域来对业务进行分析，形成的业务架构图：

重点观察四种不同的角色在业务上的痛点：

1、业务人员：为业务提供实时、准确、一致的业务数据，通过形成更高效的业务协同模式；同时通过数据的价值发现，提升业务人员决策效率、提高医疗质量、降低医疗风险。

2、 IT管理人员：IT资源的统一管理，如标准化、主数据、数据资源等，为搭建企业级的IT架构，应对当下的各种IT集成问题；同时为将来更复杂的业务实现搭建良好的IT软设施基础。

3、专业软件厂商：让软件厂商更加专注于专业度的实现，让软件更有深度，软件系统与其它软件集成交由平台实现，实现更快速的上线及更低的接入成本，同时降低各软件厂商的运维成本。

4、外部机构：与外部机构的业务协同模式更加简单与高效，同时降低接入成本与运维成本。

总体架构

信息集成平台是集成平台医疗行业的中应用最佳实践，该平台是基于SOA开放式的架构，以服务的方式包装现有各种功能组件，采用统一的接口方式与标准化的协议，实现医院内部各信息系统及外部系统信息的"互联"、"互认"、"互操作"，提供统一的安全保障与无侵入的集成，支持HL7、DICOM、IHE等国际标准与部颁标准，提高流程标准化、自动化；同时达到实用性、可操作性、可靠性、可维护性强的目的，它由由一系列集成产品的组件，如标准化管理组件、消息总线、订阅发布组件、数据适配器组件、数据整合组件、数据共享组件等，具有数据集成、流程集成、应用集成三大职能。下图是对信息集成平台总体架构图：