我希望使用Erlang / Elixir在金融市场中创建一个平台即服务。我将在金融市场中提供AWS lambda风格的功能，但我不打算通过web / rest / http访问，我计划将自己的基于ARM的硬件终端分发给客户端（基于Nvidia Jetson TX2或类似的，如此不错的硬件） 。他们将从这些终端访问这些功能。我希望所说的终端是系统中的完整节点。因此，他们将使用actor模型将消息传递给我的中央服务器，实际上，如果终端用户决定将他们自己的功能放在网上，终端可能会相互通信。
这是一个可行的模型吗？我可以像这样运行1000个终端吗？ 10万？我可能会遇到哪些限制？ Erlang的消息路由是否具有足够的可扩展性，如果我们有软实时金融市场流数据流动，那么这个网络仍然具有高性能？ （主要是从中央服务器到终端，但很可能直接从终端到终端移动）。我们可以拥有一个系统，其中有多达100k或更多不同的“订阅”数据通道进程可用，其中许多进程每秒都在输入并产生输出。
基本上我想要一个像上面这样的Erlang系统的可伸缩性功能的规范指南。理想情况下，我也想要一些指导这种系统的安全隐患，即。流氓终端用户是否可以破解全局路由表或系统的任何其他部分，或者边缘节点是否可以与Erlang网络其余部分的敏感部分“封锁”？
请注意，我希望大量使用端口/ NIF来实现高计算进程。
答案 0 :(得分：6)
我不会出于各种原因追求这条道路，所有这些都归功于Erlang的分配机制所开发的那种系统 - 无源背板上的一组电路板：“免费”本地带宽和整个机器所在在同一安全域中。 Erlang分发协议可能过于繁琐，无法在广泛传播的大型网络上运行良好，而且肯定太不安全了。除非您希望节点能够彼此执行:os.cmd("rm -rf /")，否则。
将中央系统中的Erlang分发协议用于您的内容，并让这些终端通过SSL向该系统和彼此讲述仅数据的内容。最重要的是，你可以简单地构建一种覆盖网络来做你想做的任何事情。
答案 1 :(得分：2)
我建议您仔细阅读this，我建议您将服务划分给小微服务
另一个基准是Investigating the Scalability Limits of
Distributed Erlang
在Joe Armstorng的书“编程Erlang ”中，他说：
“几年前，当我戴上研究帽时，我正在使用PlanetLab。我可以访问PlanetLab网络，所以我在所有PlanetLab机器上安装了空的Erlang服务器（大约450个）。
我真的不知道我会对这些机器做什么，所以我只是设置了服务器基础设施，以便以后做点什么。“
不要使用外部端口，而是使用用C或C ++编写的内部驱动程序。
答案 2 :(得分：1)
你会发现很多关于erlang架构的信息就是这个答案：How scalable is distributed Erlang?
简短的回答是，群集中的节点存在实际限制，但这种限制可能很容易违反联盟。
编辑1 /我还建议您阅读本书：Designing for scalability with Erlang/OTP