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

为什么80%的码农都做不了架构师？>>>   

在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的博客。

转载于:https://my.oschina.net/liyuj/blog/806752