语言与可伸缩性的关系

Question

我在Erlang社区网站Trapexit上看到了以下声明：

Erlang是一种用于构建具有高可用性要求的大规模可扩展软实时系统的编程语言。

此外，我还记得在某个地方看到Twitter从Ruby切换到Scala以解决可伸缩性问题。

因此，我想知道编程语言和可伸缩性之间的关系是什么？

我认为可伸缩性只取决于系统设计、异常处理等。是因为语言的实现方式、库还是其他原因？

希望开悟。谢谢。

Answer 1

Erlang对电信环境进行了高度优化，运行时间为5 9 s左右。

它包含一组名为OTP的库，可以在不关闭应用程序的情况下将代码重新加载到应用程序中！此外，还有一个监控程序模块的框架等，这样当某件事情发生故障时，它会自动重新启动，或者故障会逐渐地沿着链向上工作，直到它到达一个能够处理它的监督模块。

当然，这在其他语言中也是可能的。在C++中，您可以动态地重新加载dll，加载plugsin。在Python中，您可以重新加载模块。在C#中，您可以动态加载代码，使用反射等等.

只是该功能内置于Erlang，这意味着：

• it更标准，任何erlang开发人员都知道它是如何工作的，而不知道如何重新实现自己的

也就是说，语言之间有一些根本的区别，有些语言被解释，有些被运行字节码，有些语言是本机编译的，因此在运行时性能和类型信息的可用性等等都不一样。

Python的运行库周围有一个全局解释器锁，因此不能使用SMP。

Erlang只是在最近才增加了一些改变，以利用SMP。

总的来说，我同意你的观点，我觉得一个很大的区别在于内置的库，而不是语言本身之间的根本区别。

最终，我觉得任何一个项目，无论它是用什么语言写的，都有可能被“陷入困境”。正如您说的，我觉得架构和设计对于可伸缩性来说是非常基本的，选择一种语言而不是另一种语言，我会觉得不可思议地提供了可怕的可伸缩性.

Answer 2

Erlang来自另一种文化，在思考可靠性和如何实现它。理解文化是很重要的，因为Erlang代码并不仅仅因为Erlang而变得具有容错能力。

一个基本的想法是，高的正常运行时间不仅来自于一个非常长的平均时间间隔失败，它也来自一个非常短的平均恢复时间，如果一个失败发生。

然后，人们意识到，当检测到故障时，需要自动重新启动。人们意识到，在第一次发现一些不完全正确的东西时，一个人就应该“崩溃”，从而重新启动。需要优化恢复，尽可能减少可能的信息损失。

遵循这一策略的是许多成功的软件，例如日志记录文件系统或事务日志数据库。但绝大多数情况下，软件往往只考虑故障之间的平均时间，并向系统日志发送关于错误指示的消息，然后尝试继续运行，直到不再可能。通常需要人工监视系统并手动重新启动。

这些策略大多以Erlang图书馆的形式存在。作为语言特性的部分是进程可以“链接”和“监视”对方。第一个是双向契约，“如果你崩溃，我就会收到你的崩溃信息，如果不被困住，它会让我崩溃”，第二个是“如果你崩溃，我就会收到关于它的信息”。

链接和监视是库用来确保其他进程没有崩溃的机制。过程被组织成“监督”树。如果树中的工作进程失败，主管将尝试重新启动它，或者树中处于同一级别的所有工作人员。如果失败了，它会升级，等等。如果高级主管放弃应用程序崩溃，虚拟机退出，那么系统操作员应该重新启动计算机。

进程堆之间的完全隔离是Erlang成功的另一个原因。除了少数例外，不可能在进程之间“共享值”。这意味着所有进程都是非常独立的，并且通常不会受到另一个进程崩溃的影响。该属性还保存在Erlang集群中的节点之间，因此处理出集群的节点失败的风险很低。复制和发送更改事件，而不是有一个单一的失败点。

Erlang所采用的哲学有许多名称：“快速失败”、“只崩溃系统”、“面向恢复的编程”、“暴露错误”、“微重启”、“复制”、“复制”。

Answer 3

Erlang是一种考虑并发性的语言。虽然大多数语言依赖于多线程操作系统，但并发性是内置在Erlang中的。Erlang程序可以由数千到数百万个极其轻量级的进程组成，这些进程可以运行在单个处理器上，可以运行在多核处理器上，也可以运行在处理器网络上。Erlang还支持进程之间的消息传递、容错等。Erlang的核心是一种功能语言，而函数编程是构建并发系统的最佳范例。

简而言之，在Erlang中创建一个分布式、可靠和可伸缩的系统是很容易的，因为它是一种专门为此目的设计的语言。