臭氧插件
根据我在Raspberry Pi上所做的一些实验，我致力于创建一种在服务之间共享信息的方式。 我需要轻巧，最小，最灵活的东西。
臭氧基本上就是这样。 简而言之， 这是 一个共享的最小Node.js API，用于在多个Node实例之间共享状态和意图。 其目标是在封闭的内部网络上安全地允许实例彼此通信，这对于共享状态信息和处理特定操作非常有用。
等等...什么？
我还没有准备好为Ozone提供电梯音调（因为它仍处于起步阶段），但是下面是一个更实际的示例：
一个更好的例子
假设您有多个并行运行的并发Node实例。 一个Node实例可能负责处理和执行文件系统“事物” ，而另一个则负责获取天气信息。 这两个服务需要相互通信才能完成其工作，但是如果没有委派，这些服务将无法以结构化和组织化的方式进行通信。
当您有多个实例试图将信息传达给单个节点实例时，这成为一个实际问题。 您如何防止冲突？ 如果网络条件阻止您先到达另一个实例，该怎么办？
这些是我在自己的实验中面临的确切问题，我需要一种异步处理此问题而不引起紧密耦合的方法。 臭氧充当桥梁，负责安全和异步地委派动作。
保护子系统
无论如何，我都不是经验丰富的系统架构师，尽管我已经知道选择JavaScript会让那些会就职的人成为可能。 如何使JavaScript系统运行核心任务而又不损害底层系统？
我很高兴你问。
臭氧要求子系统（主要是运行该目录的系统）拥有并只能由root用户在引导之前进行编辑。
如果它检测到子系统可能已受到威胁，或者在启动序列之间检测到未经授权的文件系统更改，则会抛出该异常并告诉您具体情况。
核心文件（及其目录中的所有文件）都被递归锁定。 结果，任何影响核心，初始服务，甚至服务目录（甚至是自定义目录）的SHA完整性的未经授权的更改都将导致严重的过早故障，以防止潜在的代码注入或损坏的文件运行。
这就是为什么默认情况下， Ozone不具有依赖关系以维持预期行为并防止不必要的安全风险的原因。
国家管理和意图
我提到的另一个目标是一种有效地共享状态并将数据以有组织的方式发送到其他服务的方法。
在services.json中定义的services.json可以访问名为state的特殊属性，该属性在授权服务可操作的状态上指定唯一键。 每当修改全局状态时，每个服务便会得到通知，并可以执行所需的事件。
其目的是使每个服务都可以访问共享的信息结构。 这通常意味着含糊但潜在有用的数据，例如传感器读数，设备的当前方向或当前的天空颜色。
另一方面， 意图是我制造臭氧的全部原因。 从理论上讲 ，基于意图的模型意味着服务是松散耦合的，并且本质上是可互换的。 这对我的需求很有用，因为它允许减少服务之间的相互依赖性，因此，如果一项服务被捕获并刻录，整个系统将不会崩溃。
将来，我计划添加冗余功能，以在出现较高故障时自动将服务恢复到工作状态。
服务的notify属性允许它接收一般意图以及附加到它的任何数据。 例如，发出MAKE_ME_A_PENCIL意图的服务会将其发送给在notify属性下具有该意图的所有匹配服务。 包括的信息可能包括所需的颜色，制成的木材类型以及其他服务可能会解释的任何偏好。
if it was an actual robotic function... The global state could represent the physical world.
因此，这些服务中的每一个都会收到一条消息MAKE_ME_A_PENCIL ，其中包含一些包含相关数据的JSON对象。 由特定服务决定如何处理收到的意图。 如果服务的逻辑允许，它将更新其状态，而不是发送对每个服务的响应。 因此，如果pencil-maker服务收到MAKE_ME_A_PENCIL意图，则可以渲染铅笔，然后更新状态以增加当前铅笔数。
这是我对理想系统的看法。 如果仔细检查所有抽象，则单个服务本质上应该做的一件事情一件事情都做好 。 服务需要抽象数据的任何额外部分，就是这样。 但是就其他服务而言，它们只关心基本数据。
在结束时
尽管核心本身是用Node编写的，但从技术上讲，任何能够与规范交互的语言或软件包都可以利用状态和意图API。 我仍在积极改进系统，以便它可以利用多主机服务（用于集群），以及使规范文档更加连贯和有用。
可以在GitHub上签出我的代码 ，它是BSD-2子句。 这项工作仍在进行中，但是一定欢迎人们来看看。
我很期待看到我能够从事这个项目的程度，以及社区如何选择使用或适应它。 到目前为止，我的目标是嵌入式系统，但就我而言，它可以走得更远。
翻译自: https://hackernoon.com/ozone-the-multi-instance-state-management-system-59ed2d7a104b
臭氧插件
718
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
