SD erlang 项目有多成熟?

how mature is SD erlang project?

您有使用 SD Erlang 项目的经验吗?

关于通信网格优化似乎实施了许多有趣的概念,我很好奇你们中的一些人是否已经在生产中或至少在一些实际项目中使用过这些概念。

SD erlang repo

谢谢!

该项目已在一周前完成。 SD Erlang 背后的主要思想是减少 Erlang 节点维护的连接数,同时保持节点组的传递性和公共命名空间。我们使用的基准测试(Orbit、蚁群优化 (ACO) 和 Instant Messenger)显示出非常有希望的结果。不幸的是,我们没有足够的人力资源来重构 Sim-Diasca 模拟引擎。所以,不,SD Erlang 还没有在实际应用中使用过。

目前我们正在编写最后一个可交付成果,它将概述已取得的成就。它会在几周后出现 here (D6.2)。总的来说,我们对使用 SD Erlang 获得的结果感到满意,因此我们计划继续开展后续项目,但目前正在进行中。

这不是一个直接的答案,但我将在需要扩展到数百个节点(小型嵌入式 CPU)的嵌入式应用程序中使用 SD-Erlang。据我所知,它已准备好在实际应用程序中进行试用。为了进一步评估,让我们考虑替代方案:

  • 你只有几个分布式节点:那么你可能不需要它并且可以连接所有节点并且对于名称注册使用 global 模块(缓慢但坚固) 或 gproc 与新的 locks_leader branch 避免了相当破损的 gen_leader ,后者目前阻止在生产中以分布式模式使用 gproc

  • 您需要很多节点(多少取决于您的硬件和要求,但您开始进入具有 > 70 个节点的有趣领域)

    • 使用 SD-Erlang 并修复您在生产中遇到的任何问题,或者至少报告它们。它确实解决了你在正常的 Erlang 分布中遇到的很多问题

    • 使用不同的 cookie 值或隐藏节点来推出您自己的解决方案:提示您可以为不同的对等节点设置不同的 cookie 值。但是随后您需要推出自己的全局名称注册表和管理代码:看起来像 Greenspuns 10th rule or closer to Erlang Virdings 1st rule 的变体:您可能会自己实现一半的 SD Erlang。

    • 根本不要使用 Erlang 发行版。这似乎是行业标准,对于涉及更多节点或跨数据中心的任何事物,您根本不应该使用 Erlang 分布,而是 运行 您自己的协议。我个人的意见是解决 Erlang Distributions 的问题而不是抛弃它。当它适用于一个用例而放弃它时,它太有用且节省时间了。我认为 SD-Erlang 是解决 "too many nodes" 问题的方法,它至少是正确的起点。