Erlang vs. CERL - CERL简介

最新推荐文章于 2024-05-24 09:34:13 发布

原创最新推荐文章于 2024-05-24 09:34:13 发布 · 8.1k 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#erlang #服务器 #processing #语言 #server #框架

C++ 同时被 3 个专栏收录

77 篇文章

订阅专栏

Erlang

40 篇文章

订阅专栏

CERL

18 篇文章

订阅专栏

Erlang vs. CERL

Erlang众所周知，这里不介绍了。其优势在于：

最简洁精练的分布式模型
- Node, Process, Mail (Message)
最优雅的错误处理模型：速错（Fail fast）
- 如果出现任何异常，立即死掉
GenServer编程框架
- 程序代码风格完全一致，便于交流
轻量级的进程
- 可以尽可能地按照正常的业务逻辑去设计，而不是过多地考虑硬件环境的制约。
热部署（Hot swap）
变量不可变
- 更容易写出可靠的程序。也利于事务性代码的编写。
- 当然这是一把双刃剑。它也改变了你的编程习惯。

CERL 这个词的来源是因为他被定为为：Erlang Model for C++。目的是在C++中获得Erlang的好处（部分）。不过，实际上CERL被实现为与语言无关的。基于CERL，你可以用PHP、Python之类的语言来写服务器或客户端。

CERL 基于Erlang的分布式模型。实现了Erlang做最重要的几个概念：Node, Process, Mail (Message)。他也支持速错（Fail fast）及GenServer编程框架。当然，也有它没有做到的，如：

CERL 不支持轻量级的进程。尽管CERL的Process模型和Erlang一致，但是他并不轻量，事实上CERL的进程就是操作系统中的Thread。刚开始我准备用协程，不过后来被证明这是不必要的，所以CERL永远都不考虑协程这东西。
CERL 不支持热部署。当然，这是指他没有提供机制支持，而不是指你没法做到。

为什么是CERL，而不用Erlang？

刚开始我确实用Erlang，而且完成了DEMO。不过，我最终发现这中间存在些问题。尽管Erlang的思想是非常优秀的，但是：

Erlang是小众语言，使用它存在维护上的风险。(这个是缺点，但不是我最重要的理由)
Erlang的变量不可变，改变了程序员的思维习惯。
- 我个人原则上认可变量应不可变带来的好处，但是允许特殊情形下的可变（例如for循环的自变量）。
Erlang是动态语言。
- 我个人认为大型工程都应该使用静态类型语言，以获得更好的代码质量和性能（静态类型语言更容易写出高质量少BUG的代码）。

其实，最终极的理由是第3条。

CERL简介

CERL对外表现为一个动态库（cerl.dll） + 一个编译器（sdlc）。逻辑上CERL分为两层，底层称为CERL Core，上层为GenServer框架。

CERL Core –表现为动态库cerl.dll。主要实现Erlang的分布式模型，及其他辅助基础设施。
GenServer框架。它主要定义了服务器接口描述语言: Server Description Language（SDL），并提供相应的编译器 sdlc 以生成：
- 客户端如何调用该服务器的Proxy代码。
- 服务器端Stub代码。
- 服务器Impl文件的框架代码。

基于CERL的程序样例

假设我们要实现一个简单的HashServer。

首先，我们定义该服务器的接口（HashServer.sdl）：

module hasht; server HashServer { HashServer(UInt32 bucket_count); [id=1] put(UInt32 key, UInt32 value) -> ok; [id=2] get(UInt32 key) -> {ok, UInt32 value} | false; [id=3, async] stop(); }

然后，sdlc编译它，生成 sdl_hasht.h 文件（Client调用需要的Proxy），HashServerStub.h，HashServerImpl.h。

Proxy, Stub文件是不建议编辑的，HashServerImpl.h文件才是你需要去填写真正实现代码的地方。当然生成的还有一个比较次要的文件：sdl_hasht_base.h，该文件放的是Client和Server端都需要的公用代码，也不需要编辑。

生成的 HashServerImpl.h 大体如下：

注解：_start 函数已经帮你实现，你需要做的就是实现这里的put, get, stop三个函数。他们和普通的函数并无区别，多余的mail参数是该请求的邮件实例，一般情况下不需要用到该参数。

客户端调用代码示例如下：

注解：服务器可能由client启动（通过调用_start函数，不过这种情况比较少见），也可以通过CERL提供的命名进程（NamedProcess）机制向远程节点获得（该机制和域名机制有点类似），如本例的注释所示。