2月26日，我们举行了Apache Ignite GreenSource mitap大会，开源
Apache Ignite项目的贡献者在这里进行了表演。 这个社区生活中的一个重要事件是
Ignite Service Grid组件的重组，它使您可以直接在Ignite群集中部署自定义微服务。 Yandex高级开发人员和Apache Ignite贡献者两年多的
Vyacheslav Daradur在会议上谈到了这一困难的过程。
首先，什么是Apache Ignite。 这是一个分布式的键/值存储库，支持SQL，事务和缓存。 此外，Ignite允许您直接在Ignite群集中部署用户服务。 开发人员可以使用Ignite提供的所有工具-分布式数据结构，消息传递，流传输，计算和数据网格。 例如，当使用数据网格时，为数据仓库管理单独的基础结构的问题以及由此产生的开销消失了。
使用服务网格API，您可以通过简单地在配置中指定部署方案以及相应的服务本身来部署服务。
通常，部署模式表示应该部署到群集节点的实例数。 有两种典型的部署模式。 第一个是集群单例：在集群中的任何时候，都将保证一个用户服务实例可用。 第二个是节点单例节点：服务的一个实例部署在群集的每个节点上。
用户还可以指定整个集群中服务实例的数量，并定义用于过滤合适节点的谓词。 在这种情况下，服务网格本身将为服务部署计算最佳分配。
另外，还有诸如“亲和性服务”之类的功能。 相似性是一种功能，用于定义键与分区的关系以及各方与拓扑中的节点的关系。 使用该键，您可以确定存储数据的主节点。 因此，您可以将自己的服务与关联函数的键和缓存关联。 如果亲和力功能发生变化，将发生自动重新操作。 因此，该服务将始终置于应处理的数据旁边，从而减少了访问信息的开销。 这种方案可以称为一种并置计算。
现在我们已经弄清了Service Grid的美丽之处，我们将向您介绍其发展历史。
以前是什么
Service Grid的先前实现基于Ignite事务复制系统缓存。 Ignite中的“缓存”一词表示存储。 也就是说，这不是您可能想到的临时的东西。 尽管高速缓存是可复制的，并且每个节点都包含整个数据集，但在高速缓存内部仍具有分区视图。 这是由于存储优化。
当用户想要部署服务时会发生什么？
- 群集中的所有节点都使用内置的“连续查询”机制订阅了更新存储库中的数据的操作。
- 读已提交事务下的启动节点在数据库中记录了包含服务配置（包括序列化实例）的记录。
- 收到新记录的通知后，协调器将根据配置计算出分布。 结果对象被写回到数据库。
- 节点将有关新分发和已部署服务的信息读取到
如有必要。
什么不适合我们
在某个时候，我们得出了结论：使用服务是不可能的。 有几个原因。
如果在部署过程中发生某种错误，那么您只能从发生所有事情的节点的日志中找到它。 只有异步部署，因此在将控制从部署方法返回给用户之后，花费了一些额外的时间来启动服务-那时用户无法控制任何东西。 为了进一步开发Service Grid，看到新功能，吸引新用户并使所有人的生活更轻松，您需要进行一些更改。
在设计新的服务网格时，我们首先要提供同步部署保证：用户一旦从API返回控制权，他就可以立即使用服务。 我还想给发起者一个处理部署错误的机会。
另外，我想促进实施，即摆脱交易和再平衡。 尽管高速缓存是可复制的并且没有平衡的事实，但是在具有许多节点的大型部署期间仍然存在问题。 更改拓扑时，节点需要交换信息，并且在大型部署中，此数据可能会很重。
当拓扑不稳定时，协调器需要重新计算服务的分布。 通常，当您必须在不稳定的拓扑上处理事务时，这可能会导致难以预测的错误。
问题所在
哪些全球变化没有伴随问题？ 首先是拓扑的变化。 您需要了解，即使在服务部署时，节点也可以随时进入或退出集群。 此外，如果在部署时节点进入群集，则必须将有关服务的所有信息一致地传输到新节点。 我们不仅在谈论已经部署了什么，还在谈论当前和将来的部署。
这只是可以放在单独列表中的问题之一：
- 启动节点时如何部署静态配置的服务？
- 节点退出集群-如果主机托管服务怎么办？
- 如果协调员已更改该怎么办？
- 如果客户端重新连接到集群怎么办？
- 我需要处理激活/停用请求吗？如何处理？
- 但是，如果他们称之为“销毁”缓存，并且我们绑定了亲和力服务，该怎么办？
不仅如此。
解决方案
作为目标，我们选择了事件驱动方法，以实现使用消息的通信过程。 Ignite已经实现了两个组件，它们允许节点在它们之间转发消息：communication-spi和discovery-spi。
Communication-spi允许节点直接通信和转发消息。 它非常适合发送大量数据。 Discovery-spi允许您将消息发送到群集中的所有节点。 在标准实现中，这是根据环形拓扑完成的。 还与Zookeeper集成在一起，在这种情况下使用星型拓扑。 另一个值得注意的重要点是：discovery-spi保证消息将以正确的顺序传递到所有节点。
考虑部署协议。 所有有关部署和分发的用户请求均通过Discovery-spi发送。 这提供了以下
保证 ：
- 该请求将被集群中的所有节点接收。 这将允许您在更改协调器时继续处理请求。 这也意味着在一条消息中，每个节点将具有所有必需的元数据，例如服务的配置及其序列化实例。
- 严格的消息传递顺序使您能够解决配置冲突和竞争请求。
- 由于节点对拓扑的输入也由Discovery-spi处理，因此使用服务所需的所有数据都将到达新节点。
收到请求后，集群中的节点将对其进行验证并形成要处理的任务。 这些任务排队，然后由单独的工作人员在另一个线程中处理。 这是通过这种方式实现的，因为部署可能会花费大量时间并延迟昂贵的发现流，这是不可接受的。
队列中的所有请求均由Deployment Manager处理。 他有一个特殊的工作人员，他从此队列中拉出一个任务并将其初始化以开始部署。 此后，将发生以下操作：
- 每个节点都借助新的确定性分配函数独立计算分布。
- 节点形成带有部署结果的消息，并将其发送给协调器。
- 协调器聚合所有消息并生成整个部署过程的结果，该结果通过Discovery-spi发送到集群中的所有节点。
- 收到结果后，将完成部署过程，然后将任务从队列中删除。
新的事件驱动设计：org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java如果在部署时发生错误，则节点会立即将此错误包括在消息中，然后将其发送给协调器。 消息聚合之后，协调器将获得有关部署期间所有错误的信息，并将通过Discovery-spi发送此消息。 错误信息将在群集中的任何节点上可用。
根据此算法，将处理服务网格中的所有重要事件。 例如，拓扑更改也是Discovery-spi消息。 通常，与实际协议相比，该协议非常轻巧且可靠。 足以应付部署期间的任何情况。
接下来会发生什么
现在来看看计划。 Ignite项目的任何重大发展都是作为改进Ignite（即所谓的IEP）的一项举措而进行的。 重新设计的服务网格还具有IEP-
IEP No. 17 ，取笑的名称是“服务网格中的机油更换”。 但实际上，我们更换的不是引擎中的机油，而是整个引擎。
我们将IEP中的任务分为两个阶段。 第一阶段是主要阶段，其中包括更改部署协议。 它已经注入到向导中，您可以尝试新的Service Grid，它将出现在2.8版中。 第二阶段包括许多其他任务：
- 热重读
- 服务版本控制
- 增强弹性
- 瘦客户端
- 监视和统计各种指标的工具
最后，我们可以建议您使用服务网格来构建容错高可用性系统。 我们还邀请您在
开发人员列表和
用户列表中分享您的经验。 您的经验对于社区确实很重要，它将帮助您了解下一步的发展，将来如何开发该组件。