在Ignite上运行微服务：第一部分

在Ignite上运行微服务：第一部分

从本文开始，会经过一个系列的篇幅来介绍使用Apache Ignite内存数据组织平台来构建容错、可扩展的基于微服务的解决方案。

介绍

当前，不少公司都会将本身的应用或者解决方案构建于微服务架构之上，这样作的主要好处是，能够将一个解决方案拆分为一组松耦合的软件组件（微服务）。这些软件组件可能有本身的版本以及生命周期，甚至有本身的开发团队。此外，这些软件还可能使用不一样的语言和技术来开发和维护。可是由于全部的微服务都会是更大的构件（软件或者解决方案）的一部分，因此它们至少须要一个机制来进行彼此的交互和数据交换。

同时，基于微服务的解决方案也会用于高负载或者须要处理快速增加的数据的场景，所以和不是基于微服务的应用和解决方案同样，它也会面临一样的问题和困难。

• 面向磁盘的数据库已经没法跟上快速增加的数据量，这些数据须要以并行的方式进行存储和处理，数据库正在成为整个应用或者解决方案的性能瓶颈；
• 软件的高可用性保证做为一个好功能已经成为过去式，当前，应用的高可用性已经成为事实上的标配。

从本文开始，会经过一个系列的篇幅来一步步地介绍使用Apache Ignite内存数据组织平台来构建容错、可扩展的基于微服务的解决方案。

使用Apache Ignite的基于微服务的解决方案

下图会描述整个解决方案的主要构成，以后会深刻，一个一个定义它们的角色。

Ignite集群层

集群有两个做用：

首先，做为主要的数据存储，它直接在内存中保存数据集。由于数据离CPU更近，一个微服务不须要从磁盘上获取数据，这显著地提高了总体的性能。从上图来看，咱们指定了一个特定的集群组（数据节点）来专门处理这个问题。

一个数据节点是一个Ignite服务端节点，它持有数据集的一部分，而且能够执行查询和计算。另外，有赖于基于对象序列化的二进制格式化技术，一个数据节点不须要部署模型对象和计算的支撑类，这个叫作对等类加载机制，它能够管理从应用逻辑节点（服务节点）预加载的计算类。

其次，集群管理微服务的生命周期，而且为微服务配备全部必要的API，好比与其余服务或者数据节点进行通讯的API。要达到这一点，一个基于Ignite集群的解决方案须要包含前述的服务节点，这些节点部署有微服务，而且应用逻辑也在这里执行。一个服务节点能够部署一个或者多个微服务，这个取决于具体的应用以及负载状况。每一个微服务都须要实现Ignite的Service接口，它直接就有了容错和访问其余微服务的能力。

Ignite会处理在服务节点范围内，一个微服务的一个或者多个副本的部署，而且会自动地进行容错和负载平衡。在上述的图1中，这类微服务被命名为MS<N>(MS1,MS2等）。在多个服务和数据节点间传播负载的好处是，若是MS1微服务改变，不须要重启整个集群，全部须要作的就是在部署有MS1微服务的服务节点上更新MS1的相关类，所以只有全部节点的一个子集须要重启。

全部的节点（服务和数据节点）都是相互链接的，这使得部署在一个服务节点上的MS1能够与部署在任何其余的或者自身服务节点上的微服务进行通讯，也能够向任何数据节点获取和发送数据以及计算。

持久化存储层

这一层是可选的，能够用于以下的场景：

• 在内存中持有全部的数据是没必要要或者不可行的；
• 须要从基于磁盘的副本中恢复数据集的能力，这时整个集群须要停机或者须要重启。

要启用持久化存储层，只须要简单地提供一个实现了CacheStore接口的Ignite数据缓存就能够了。在默认支持的实现中，有RDBMS，MongoDB以及Cassandra。

外部应用层

这是微服务架构应用的"用户"，基本上来讲，这是一个触发调用一个一个微服务的各类执行流程的层次。

这个层可使用具体到每一个微服务的外部协议来与微服务进行通讯（而在内部，微服务间相互通讯可使用Ignite服务，或者使用Ignite客户端链接进行链接），这方面都很大的灵活性以及多样化的选择。

未完待续

这个架构具备水平扩展的能力，能够在内存中保存数据集，微服务也具备高可用的特性。在之后的文章中，会经过一个示例来展现如何实现这个设计，敬请期待。

本文译自Denis Magda的博客。