臭氧插件_臭氧-多实例状态管理系统

臭氧插件

我还没有准备好为Ozone提供电梯音调（因为它仍处于起步阶段），但是下面是一个更实际的示例：

一个更好的例子

假设您有多个并行运行的并发Node实例。 一个Node实例可能负责处理和执行文件系统“事物” ，而另一个则负责获取天气信息。 这两个服务需要相互通信才能完成其工作，但是如果没有委派，这些服务将无法以结构化和组织化的方式进行通信。

当您有多个实例试图将信息传达给单个节点实例时，这成为一个实际问题。 您如何防止冲突/em> 如果 络条件阻止您先到达另一个实例，该怎么办/em>

这些是我在自己的实验中面临的确切问题，我需要一种异步处理此问题而不引起紧密耦合的方法。 臭氧充当桥梁，负责安全和异步地委派动作。

保护子系统

核心文件（及其目录中的所有文件）都被递归锁定。 结果，任何影响核心，初始服务，甚至服务目录（甚至是自定义目录）的SHA完整性的未经授权的更改都将导致严重的过早故障，以防止潜在的代码注入或损坏的文件运行。

这就是为什么默认情况下， Ozone不具有依赖关系以维持预期行为并防止不必要的安全风险的原因。

国家管理和意图

我提到的另一个目标是一种有效地共享状态并将数据以有组织的方式发送到其他服务的方法。

在services.json中定义的services.json可以访问名为state的特殊属性，该属性在授权服务可操作的状态上指定唯一键。 每当修改全局状态时，每个服务便会得到通知，并可以执行所需的事件。

其目的是使每个服务都可以访问共享的信息结构。 这通常意味着含糊但潜在有用的数据，例如传感器读数，设备的当前方向或当前的天空颜色。

另一方面， 意图是我制造臭氧的全部原因。 从理论上讲 ，基于意图的模型意味着服务是松散耦合的，并且本质上是可互换的。 这对我的需求很有用，因为它允许减少服务之间的相互依赖性，因此，如果一项服务被捕获并刻录，整个系统将不会崩溃。

将来，我计划添加冗余功能，以在出现较高故障时自动将服务恢复到工作状态。

服务的notify属性允许它接收一般意图以及附加到它的任何数据。 例如，发出MAKE_ME_A_PENCIL意图的服务会将其发送给在notify属性下具有该意图的所有匹配服务。 包括的信息可能包括所需的颜色，制成的木材类型以及其他服务可能会解释的任何偏好。

因此，这些服务中的每一个都会收到一条消息MAKE_ME_A_PENCIL ，其中包含一些包含相关数据的JSON对象。 由特定服务决定如何处理收到的意图。 如果服务的逻辑允许，它将更新其状态，而不是发送对每个服务的响应。 因此，如果pencil-maker服务收到MAKE_ME_A_PENCIL意图，则可以渲染铅笔，然后更新状态以增加当前铅笔数。

这是我对理想系统的看法。 如果仔细检查所有抽象，则单个服务本质上应该做的一件事情一件事情都做好 。 服务需要抽象数据的任何额外部分，就是这样。 但是就其他服务而言，它们只关心基本数据。

在结束时

尽管核心本身是用Node编写的，但从技术上讲，任何能够与规范交互的语言或软件包都可以利用状态和意图API。 我仍在积极改进系统，以便它可以利用多主机服务（用于集群），以及使规范文档更加连贯和有用。

可以在GitHub上签出我的代码 ，它是BSD-2子句。 这项工作仍在进行中，但是一定欢迎人们来看看。

弗林纳姆/臭氧
臭氧-基于异步Node.js的 络引擎 github.com

我很期待看到我能够从事这个项目的程度，以及 区如何选择使用或适应它。 到目前为止，我的目标是嵌入式系统，但就我而言，它可以走得更远。

翻译自: https://hackernoon.com/ozone-the-multi-instance-state-management-system-59ed2d7a104b

臭氧插件

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91437 人正在系统学习中 相关资源：iZotope Ozone VST (臭氧) V4.0.3.274 绿色汉化版.zip-制造工具类…