现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

为什么选择Erlang作为服务器编程语言

2020-01-13 13:23 工业·编程 ⁄ 共 1848字 ⁄ 字号 暂无评论

虽然Erlang有很长的历史,并且也被应用到很多领域中,在编程语言众多,新编程语言还在继续涌现的今天,Erlang却并不为普通大众所知,仅仅在一个小众圈子里面备受推崇。Erlang既是一个编程语言,更是一个操作系统加一整套工具集。对于服务器端的各种编程任务,Erlang使不可能做到的事情成为了可能,让可能做到的事情变得更简单。

首先举个生活中的例子吧,当我们打电话的时候当我们发短信的时候,我们很有可能正在使用基于Erlang构建的系统,但是我们却从来没有听说电信公司发布公告说系统要维护系统要更新,有一段时间不能使用,请用户耐心等待。其实电信公司一直在不断的修复软件bug,升级软件和硬件,和我们最常见过的的web 应用程序服务器或者游戏服务器的维护升级是没有区别的。我们能这么平滑和不间断的使用手机上的各种业务,很有可能里面就有Erlang的功劳。

接着我们来讲本来我们应该解决,但是目前我们却很少去解决的问题,可能这个问题第一目前还不突出还不明显,第二可能这个问题解决起来比较麻烦,事情一麻烦真心想去解决的积极性就低很多。

1.支持动态扩展系统能力,在web程序这类相对比较成熟的领域,我们用集群,负载均衡来解决了这类问题。但是对于面向连接的状态更复杂多变的游戏服务器,却很少是能够动态扩展的,于是简单而粗暴的解决方案就是分服务器。庆幸的是我们打电话的时候不需要先选择服务器,也不需要通信的对方必须在同一个服务器。有且只有一个世界,并且能够动态扩展处理能力和连接能力才是理论上完善的解决之道。Erlang的地址透明的消息传递机制,不再区分消息是发给本地的进程,还是远程的进程。加上本地和全局命名服务,和完善的组网基础设施,让这些变的非常简单。

2.热升级,也就是不停止产品运营的情况下升级软件,我们也可以做到电信运营级别的连续性。特别是如果能保证服务器能够连续运行,那么程序结构都可能完全不同,可能完全做到基于内存的系统,因为不间断内存和永久存储没有差别。Erlang通过Release,Appup等机制让这些也变的简单了,在rebar和relx等工具的帮助下,这个工作变得更简单,简单的配置文件和执行几个命令就能做到打包,部署,升级了。如果要做到完全的不间断运营,还需要考虑硬件错误发生的可能。Erlang通过监听进程,监听节点的情况,可以做到转移服务到备份节点上,也让这个工作成为了可行。

3.运营中诊断和查找问题的能力。

最后我们来说说Actor模型。Erlang是Actor模型的典型实现,但是实现了Actor模型的框架和库是很多的,基于Java语言的和C#语言的都有。这两个语言被使用的这么广泛,程序员基础也那么好的情况下,为啥还需要选择Erlang这种小众语言了?

Erlang语言是简单的,熟悉Erlang语言本身可能一两个星期就足够了。在熟悉了简单的语法之后最多的考虑的就是系统架构的问题了,如何做到保证逻辑正确的情况下最大程度的并发,如何实现一个不间断运行的系统成为了需要考虑的核心问题。读关于Erlang的书籍和文档等,能够接触到最多的是关于这类问题的讨论。

既然和其他语言没有差别,为啥还要选择Erlang了。因为Erlang生来就是Actor模型,这是他的唯一并发模型。而C#和Java最基本的基于共享状态和锁机制的并发模型。另一个非常重要的是Erlang中所有的东西都是不可变值(即使Erlang底层对某些场景做了性能优化,但依然是保证不变值的性质的),是一旦绑定再也不能修改的。而C#和Java是有状态的可变对象,很可能一不小心就传递了对象的引用到不同的actor中去了。因此C#和Java程序员在使用Actor框架的时候稍不注意可能就会出现并发问题,这个对程序员的要求变高了,而且一旦出现问题查找和发现也是耗时费劲的。

在消息传递的并发模型中,尽可能多的使用不可变的值,特别是作为消息传递的数据必须是不可变值才能保证程序的并发正确性,但是这必然会产生更多的临时对象。而JVM和CLR的GC机制却又不是为这样的场景设计的,这样就需要更频繁的GC操作,而他们的VM的GC也还是一个并发锁定操作,这必然使系统有短暂的停顿。而Erlang是在每个Actor里面做GC,不需要暂停整个世界来做GC,因此具有更平滑的软实时特性。这方面Erlang具有设计的一致性,而其他的Actor模型的框架和库可以只能说是在他们基于的语言上打补丁,而底层语言的设计却和Actor模型是不配合的,不协调的。

给我留言

留言无头像?