如何把erlang应用在项目中？

考虑到现有的项目使用erlang重写的复杂性和erlang对于某些数据库支持的弱点，想结合erlang的分布式、代码热加载、处理高并发方面的优势，和C++在性能上以及大量现有项目上的优势，实现集群部署。

考察了erlang和C进行交互的几种方式，ports受限于物理服务器分布，port_driver没测试成功，应该也是受限于本机，最后选定C nodes方式。

测试了c server和c client两种方式，感觉如果是server方式，还得用C写一套处理高并发的网络模块，也不方便升级，erlang的优势完全没发挥上，所以选定client方式。

大致的想法是这样的：
* erlang监听一个本地端口和一个对外的端口，本地的用于和c node通讯，对外的通过协议和客户交互。
* c node连接到本地端口后，就在erlang里面注册一个名字，这时候对外的端口上收到的数据就根据这个名字发给c node。
* c node上接收到数据以后就放队列，给线程池去消化，线程池处理完以后就通过端口发回给erlang节点，当然是使用erl_send (问题1)。
* erlang上面当然是由process“阻塞”处理，它收到结果以后，就发回给客户端，这个阻塞当然是假的，也正是利用erlang编程的便利。
* c node升级，只需要另开一个程序，注册另一个名字，比如名字加上版本号，连到erlang节点，再使用热加载把erlang代码更新，就可以在不停机的情况下更新服务器。更新完了再停掉旧版本的c node。
* 增加协议格式等操作都交给erlang了，C node保持不变。

不知道erlang应用于这种项目，上面这种方式是不是最优的？请有经验的朋友指点。

问题1：
erl_send是不是线程安全的？如果不是，我可能要做个发送线程去处理发送队列了。

评论

28 楼 everlasting_188 2008-04-12  

iunknown 写道

qiezi 写道

倒是公司现有的很多C++项目，明显是生手的练习，各种漏洞一大堆，几乎所有的项目都被补过一遍了，可维护性是有，却是很需要维护啊，而且维护的成本也不低。

我遇到的情况也类似。最常见的情况是长函数一大堆，或者因为模块划分不好，导致循环依赖。在这个坛子里，大多数人都认为 c++ 难学难精，但是在我遇到的情况中，好像是反过来，反而好像认为随便一个人都是 c++ 高手，有些重要的关于项目方面的决策也没怎么讨论，随便就交给了一个新手，结果就像 qiezi 说的：“很多C++项目，明显是生手的练习，各种漏洞一大堆”。

qiezi 写道

几乎每个项目我都实现过多种可选方案，然后进行比较，再找一下各种方案的差异，当然最后上线的肯定是C++版本的，每种方案都做完了，都是可以上线的版本，上哪个版本正是考虑到以后的维护性问题。

呵呵，公司有那么宽松的时间给你？ 口水ing 。。。。。。
我经常也有这样的想法，不过公司基本上不会答应。所以只好自己业余时间来试了。

赞一个

27 楼 mryufeng 2007-07-31  

erl的trace更是强大 erts\emulator\beam\erl_trace.c emulator的实现 还有更cool的 et_viewer 对整个message 的流向更是 尽收眼底， 对分布程序的调试真是太方便了

26 楼 mryufeng 2007-07-31  

monitor是 erts\emulator\beam\erl_monitors.c  里面实现的 看下 .h的说明

/**********************************************************************
* Header for monitors and links data structures.
* Monitors are kept in an AVL tree and the data structures for
* the four different types of monitors are like this:
**********************************************************************
* Local monitor by pid/port:
* (Ref is always same in all involved data structures)
**********************************************************************
*        Process/Port X     Process Y
*       +-------------+    +-------------+
* Type: | MON_ORIGIN  |    | MON_TARGET  |
*       +-------------+    +-------------+
* Pid:  | Pid(Y)      |    | Pid/Port(X) |
*       +-------------+    +-------------+
* Name: | []          |    | []          |
*       +-------------+    +-------------+
**********************************************************************
* Local monitor by name: (Ref is always same in all involved data structures)
**********************************************************************
*        Process X          Process Y (name foo)
*       +-------------+    +-------------+
* Type: | MON_ORIGIN  |    | MON_TARGET  |
*       +-------------+    +-------------+
* Pid:  | Pid(Y)      |    | Pid(X)      |
*       +-------------+    +-------------+
* Name: | Atom(foo)   |    | Atom(foo)   |
*       +-------------+    +-------------+
**********************************************************************
* Remote monitor by pid: (Ref is always same in all involved data structures)
**********************************************************************
*                    Node A              |           Node B
*       ---------------------------------+----------------------------------
*        Process X (@A)   Distentry @A       Distentry @B     Process Y (@B)
*                         for node B         for node A
*       +-------------+  +-------------+    +-------------+  +-------------+
* Type: | MON_ORIGIN  |  | MON_TARGET  |    | MON_ORIGIN  |  | MON_TARGET  |
*       +-------------+  +-------------+    +-------------+  +-------------+
* Pid:  | Pid(Y)      |  | Pid(X)      |    | Pid(Y)      |  | Pid(X)      |
*       +-------------+  +-------------+    +-------------+  +-------------+
* Name: | []          |  | []          |    | []          |  | []          |
*       +-------------+  +-------------+    +-------------+  +-------------+
**********************************************************************
* Remote monitor by name: (Ref is always same in all involved data structures)
**********************************************************************
*                    Node A              |           Node B
*       ---------------------------------+----------------------------------
*        Process X (@A)   Distentry @A       Distentry @B     Process Y (@B)
*                         for node B         for node A       (name foo)
*       +-------------+  +-------------+    +-------------+  +-------------+
* Type: | MON_ORIGIN  |  | MON_TARGET  |    | MON_ORIGIN  |  | MON_TARGET  |
*       +-------------+  +-------------+    +-------------+  +-------------+
* Pid:  | Atom(node B)|  | Pid(X)      |    | Pid(Y)      |  | Pid(X)      |
*       +-------------+  +-------------+    +-------------+  +-------------+
* Name: | Atom(foo)   |  | Atom(foo)   |    | Atom(foo)   |  | Atom(foo)   |
*       +-------------+  +-------------+    +-------------+  +-------------+
* The reason for the node atom in X->pid is that we don't know the actual
* pid of the monitored process on the other node when setting the monitor
* (which is done asyncronously).
**********************************************************************/

25 楼 qiezi 2007-07-31  

mryufeng 写道

节点间的通讯协议见otp_src_R11B-5\erts\emulator\internal_doc\erl_ext_dist.txt

erl_interface 目前还不支持 link monitor的op, 只能send receive 数据。 理论上自己可以扩展ei  自己来解释这几条op

原来如此。看到这些协议了：

引用

4.2.1.1 LINK

    {1, FromPid, ToPid}

4.2.1.3 EXIT

    {3, FromPid, ToPid, Reason}

4.2.1.4 UNLINK

    {4, FromPid, ToPid}

引用

4.4.1 MONITOR_P

    {19, FromPid, ToProc, Ref}

    FromPid = monitoring process
    ToProc = monitored process pid or name (atom)

4.4.2 DEMONITOR_P
   
    {20, FromPid, ToProc, Ref}
    We include the FromPid just in case we want to trace this.

    FromPid = monitoring process
    ToProc = monitored process pid or name (atom)

4.4.3 MONITOR_P_EXIT

    {21, FromProc, ToPid, Ref, Reason}

    FromProc = monitored process pid or name (atom)
    ToPid = monitoring process
    Reason = exit reason for the monitored process

看样子都是基于Process的，难道monitor_node实际上是用link或monitor_p协议做出来的？不过我看erts/emulator/beam/dist.c里面有个monitor_node_3，但没有以public方式开放出来。

24 楼 mryufeng 2007-07-31  

节点间的通讯协议见otp_src_R11B-5\erts\emulator\internal_doc\erl_ext_dist.txt

erl_interface 目前还不支持 link monitor的op, 只能send receive 数据。 理论上自己可以扩展ei  自己来解释这几条op

23 楼 qiezi 2007-07-31  

iunknown 写道

另外，你们公司还是比较人性化啊，做得快，剩下的时间可以自己支配。最担心就是公司见你做得快，很好，再来一个！然后你变成了做得最快，但是最忙的人，呵呵。

我们公司是给自己做软件，作为WEB应用，稳定性比进度重要。通常逻辑也比较简单，只是要从系统架构上考虑任何一个点挂掉以后的备用策略。

----------------------------------------------------------------------------
这个帖子提到的erlang应用，我简单测试了一下还是可行的，简单总结一下用到的知识。

1、分布式结点发送消息注册服务：
{manager, '[e-mail]'} ! {reg_service, auth, self()}

2、监测节点退出：
monitor_node('[e-mail]', true)
然后接收：
{nodedown, Node}

3、监测进程退出：
process_flag(trap_exit, true),
link(Pid)

4、远程节点心跳检测：
erl -heart
设置心跳间隔：
erl -heart -env HEART_BEAT_TIMEOUT 30 设置30秒心跳间隔，范围是10-65535秒之间。

有这些应该够用了。如果是C程序，如何发出monitor_node和process_flag/link呢？也可以从erlang节点上检测C节点，不过还是想知道反过来怎么检测。

22 楼 iunknown 2007-07-28  

引用

长函数是普遍情况了，呵呵。比较合理的情况，公用库放在外面，项目特定的代码应该只有少于1/5的代码用来把一些库串联起来，而逻辑部分则应该占到1/2 或更多，其它都是完成架构不可少的胶合代码。但目前一些项目，几十个文件在一起，只有几个文件是逻辑的，但却不能离开其它文件单独拿来测试。逻辑处理基本上都是长函数，加上没有很好的利用分级日志，排错非常麻烦，服务器又不能经常重启去做调试。

出现长函数，或者模块划分不清楚，很多时候是由于开发人员没有清晰的分层意识，没有分清楚公用库和胶合代码。有时候有些库是从特定项目中重构出来的。在重构成库的过程中，没有考虑清楚这个库的主体功能，从而把一些胶合代码也被放到了库里面。导致这个库本身就依赖于太多的其他库。当需要使用这个库的时候，令人发狂的事情就开始了。

引用

我刚到这公司时，写代码就是有名的快，一周的任务都是一天之内完成，其实也不是很快，只不过大家都习惯了慢。搞C++的多半都喜欢调试而不喜欢单元测试，我正是使用这一简单的敏捷方式来提高开发效率，可测试的代码通常接口也比较好，重用性也会很好。

嗯，对于后台开发，很多复杂的情况，不用单元测试，可能还没那么容易模拟出来。单元测试一般来说，能够比较方便地模拟出自己想要的前提条件。

另外，你们公司还是比较人性化啊，做得快，剩下的时间可以自己支配。最担心就是公司见你做得快，很好，再来一个！然后你变成了做得最快，但是最忙的人，呵呵。

21 楼 qiezi 2007-07-28  

iunknown 写道

我遇到的情况也类似。最常见的情况是长函数一大堆，或者因为模块划分不好，导致循环依赖。在这个坛子里，大多数人都认为 c++ 难学难精，但是在我遇到的情况中，好像是反过来，反而好像认为随便一个人都是 c++ 高手，有些重要的关于项目方面的决策也没怎么讨论，随便就交给了一个新手，结果就像 qiezi 说的：“很多C++项目，明显是生手的练习，各种漏洞一大堆”。

长函数是普遍情况了，呵呵。比较合理的情况，公用库放在外面，项目特定的代码应该只有少于1/5的代码用来把一些库串联起来，而逻辑部分则应该占到1/2或更多，其它都是完成架构不可少的胶合代码。但目前一些项目，几十个文件在一起，只有几个文件是逻辑的，但却不能离开其它文件单独拿来测试。逻辑处理基本上都是长函数，加上没有很好的利用分级日志，排错非常麻烦，服务器又不能经常重启去做调试。

iunknown 写道

呵呵，公司有那么宽松的时间给你？ 口水ing 。。。。。。
我经常也有这样的想法，不过公司基本上不会答应。所以只好自己业余时间来试了。

我刚到这公司时，写代码就是有名的快，一周的任务都是一天之内完成，其实也不是很快，只不过大家都习惯了慢。搞C++的多半都喜欢调试而不喜欢单元测试，我正是使用这一简单的敏捷方式来提高开发效率，可测试的代码通常接口也比较好，重用性也会很好。初期大家都不放心，不过负责的几个项目都是最稳定的，也就没什么疑虑了。这样我每周可以省很多时间，几乎所有的时间都是在写代码或看书。对我来说时间还是充裕的，只不过喜欢的东西太杂太多，每样都搞点皮毛，所以显得也很忙。通常服务器系统写完测试上线还需要监控一段时间，这段时间基本上是不分配任务的，定时上去监控看一下日志就好，一般这些时间有些同事在聊天、下棋什么的(好像公司不反对)，我拿这些时间看书或写代码。多点练习也是好的，我刚来时公司有很多各方面的专家，很短一段时间以后，我就发现他们的很多理论是错误的，很多都是在做项目的过程中看过一些文档后就深信不疑，而我喜欢写代码验证，所以一段时间以后我的意见就能成为更有参考价值的。


又跑题了。难怪说：3页之内必跑题，如果没跑肯定是前2页已经跑了。。
跑题也没什么，话题都是扩展的，如果能把一个帖子的各个回帖打标签就好了，连在一起看时也可以知道是怎么跑到这个话题上的，分开看也价值。

20 楼 iunknown 2007-07-28  

qiezi 写道

倒是公司现有的很多C++项目，明显是生手的练习，各种漏洞一大堆，几乎所有的项目都被补过一遍了，可维护性是有，却是很需要维护啊，而且维护的成本也不低。

我遇到的情况也类似。最常见的情况是长函数一大堆，或者因为模块划分不好，导致循环依赖。在这个坛子里，大多数人都认为 c++ 难学难精，但是在我遇到的情况中，好像是反过来，反而好像认为随便一个人都是 c++ 高手，有些重要的关于项目方面的决策也没怎么讨论，随便就交给了一个新手，结果就像 qiezi 说的：“很多C++项目，明显是生手的练习，各种漏洞一大堆”。

qiezi 写道

几乎每个项目我都实现过多种可选方案，然后进行比较，再找一下各种方案的差异，当然最后上线的肯定是C++版本的，每种方案都做完了，都是可以上线的版本，上哪个版本正是考虑到以后的维护性问题。

呵呵，公司有那么宽松的时间给你？ 口水ing 。。。。。。
我经常也有这样的想法，不过公司基本上不会答应。所以只好自己业余时间来试了。

19 楼 qiezi 2007-07-27  

dustinth 写道

那估计你们公司没什么希望. 不考虑以后维护性方面的问题. 我自己也挺讨厌想LZ这种所谓的"牛人", 自己随自己喜欢, 那公司的东西做实验, 做烂了就拍拍屁股走人.

python应用这么广，公司大部分人都会，会C++的学python几天就可以上手，而且公司目前大力推广C++配合脚本语言开发业务逻辑，我带个头而已。erlang我还没应用到项目中呢，用的人毕竟是少，很多时候有些项目都是临时性的，解决一时的问题，过渡性方案，要求快速开发，用完就没什么用了，所以我经常会在各个项目里临时救一下火，或者是要快速做一下原型，你不得找个开发效率和运行效率都过得去的东西？另外模块化的开发很容易维护，都是分布式系统，协议兼容就可以了。倒是公司现有的很多C++项目，明显是生手的练习，各种漏洞一大堆，几乎所有的项目都被补过一遍了，可维护性是有，却是很需要维护啊，而且维护的成本也不低。

我在公司基本上所有时间都在写代码，这是唯一爱好，一个项目完了如果有其它可选方案我肯定会试试，或者是其它语言来实现，你经常会看到我说用什么语言做项目，那是因为我完成了现有项目，多出来的时间我做些尝试而已，其他同事完成项目后都在聊天或看网站，我不过是做点不同的事而已。几乎每个项目我都实现过多种可选方案，然后进行比较，再找一下各种方案的差异，当然最后上线的肯定是C++版本的，每种方案都做完了，都是可以上线的版本，上哪个版本正是考虑到以后的维护性问题。你说做实验也可以，至少我没搞砸过一个项目，否则我早被开掉了。关于公司，在不到2年时间里，日浏览量目前已经接近搜狐，你要说没什么希望我也不需要反驳。。。每种公司都有自己的文化氛围，越是成功的公司越会鼓励员工尝试新技术，而不是以各种理由去阻碍。拍拍屁股走人更不是我的风格，我在过去工作过的地方时间都很长，不要拿自己的习惯去猜度别人。

又要成吵架帖了。最后说几句：
1、怀疑别人的人品的话不要说，除非你有证据证明我人品有问题。
2、明确的对别人说你讨厌他这种类型，很明显是一种挑衅行为，版规所不容。

18 楼 dustinth 2007-07-27  

qiezi 写道

iunknown 写道

qiezi 写道

找了源代码看了，应该不是线程安全的，一个消息发送就有多个写操作，并发的写FD肯定有问题的。

HIDDEN NODE没有提供更多东西，只是隐藏而已，其它没区别。

这个架构准备在项目中试用一下了，以后服务调用、服务器间通讯都是走erlang节点了。

qiezi 是怎么说服公司使用 erlang 的？我对这一点比较好奇

还没说服啊，公司并不看我写代码，项目搞稳定就行了，我已经把一部分用python写了，其它部分则使用了一些第三方库比如log4cxx，同事项目有问题就会看我怎么做，看了也会学着用的。目前有些部分本来就是独立的进程，用配置文件去定义功能，然后组合到新的服务器中，用什么语言实现都没多大差别了，稳定、高效就是唯一追求。

那估计你们公司没什么希望. 不考虑以后维护性方面的问题. 我自己也挺讨厌想LZ这种所谓的"牛人", 自己随自己喜欢, 那公司的东西做实验, 做烂了就拍拍屁股走人.

17 楼 mryufeng 2007-07-25  

There are two different interfaces, the old 'erl_interface' and 'ei'.
The old interface is to depend on the new one, not the other way arount.

Erl_interface should bze "thread safe", i.e. you should be able to
handle connections, convert data etc from different threads.

Ei should be "reentrant" or "async safe", i.e. no locks should be set
so that if an ei function is called inside an signal handler there
could be a deadlock.

VxWorks call the operating processes "tasks". These are to be handled the
same way as Unix threads, i.e. there can only be one C node for all tasks
using the old interface.

16 楼 mryufeng 2007-07-21  

cnode的实现非常薄 没有任何防护措施 这不是erl_interface的错。 ei的价值在于给你一把匕首 你能够很方便地切肉吃 当然有可能伤到手。

15 楼 Trustno1 2007-07-19  

以前potain提醒过,cnode非常不稳定.运行几天就会有没有原因的内核crash.

14 楼 qiezi 2007-07-18  

firebody 写道

赫赫，跟我猜测的不大一样，没做过实际测试，原来估计 两个线程的切换和 四个线程的切换，系统在切换上所花的时间应该差别不大，照你实际情况来看，我的估计还是错误的。

看具体情况吧，网游这种计算集中的，数据都从外部主动输入，当然是线程数少比较好，目前很多网游都是单线程跑逻辑。一些中间层服务封装数据库、远程服务调用和事务的，通常IO延时会比较明显，这时候多个线程效果比较好。这2种情况下erlang都是适用的。

13 楼 firebody 2007-07-18  

qiezi 写道

firebody 写道

有个疑问：
Erlang高并发性能的主要思想来自于 独立于操作系统的本身自带的进程调度系统，Erlang的进程切换非常高效，
现在你的设计 是 C node 大量系统线程切换+Erlang的高并发服务器。 前者会不会是个瓶颈所在？ 使得系统退化回了 传统的服务器设计？  传统设计上的进程/线程 切换开销太大了。

可以设置成erlang使用一个线程，C node开3线程，一共4个，在4CPU上运行，目前使用的服务器都是4CPU的，部分高档货8CPU。通常运行时线程数会更多，因为各种IO都会影响，我测试线程数达到十几个才会明显感觉到线程切换的影响，这个数字也和测试的具体业务相关，通常是根据测试情况来配置。

赫赫，跟我猜测的不大一样，没做过实际测试，原来估计 两个线程的切换和 四个线程的切换，系统在切换上所花的时间应该差别不大，照你实际情况来看，我的估计还是错误的。

12 楼 mryufeng 2007-07-17  

个人感觉是cnode是做些比较难用erlang实现的东西如和操作系统或者硬件交互之类的事情，调用的频率不是很高。 但是实现和调试起来又比较麻烦的场合。

11 楼 qiezi 2007-07-17  

firebody 写道

有个疑问：
Erlang高并发性能的主要思想来自于 独立于操作系统的本身自带的进程调度系统，Erlang的进程切换非常高效，
现在你的设计 是 C node 大量系统线程切换+Erlang的高并发服务器。 前者会不会是个瓶颈所在？ 使得系统退化回了 传统的服务器设计？  传统设计上的进程/线程 切换开销太大了。

可以设置成erlang使用一个线程，C node开3线程，一共4个，在4CPU上运行，目前使用的服务器都是4CPU的，部分高档货8CPU。通常运行时线程数会更多，因为各种IO都会影响，我测试线程数达到十几个才会明显感觉到线程切换的影响，这个数字也和测试的具体业务相关，通常是根据测试情况来配置。

10 楼 firebody 2007-07-17  

有个疑问：
Erlang高并发性能的主要思想来自于 独立于操作系统的本身自带的进程调度系统，Erlang的进程切换非常高效，
现在你的设计 是 C node 大量系统线程切换+Erlang的高并发服务器。 前者会不会是个瓶颈所在？ 使得系统退化回了 传统的服务器设计？  传统设计上的进程/线程 切换开销太大了。

9 楼 qiezi 2007-07-17  

javavsnet 写道

qiezi 写道

还没说服啊，公司并不看我写代码，项目搞稳定就行了，我已经把一部分用python写了，其它部分则使用了一些第三方库比如log4cxx，同事项目有问题就会看我怎么做，看了也会学着用的。目前有些部分本来就是独立的进程，用配置文件去定义功能，然后组合到新的服务器中，用什么语言实现都没多大差别了，稳定、高效就是唯一追求。

qiezi你在实现哪些功能的时候用了python？说说看，我想借鉴你的经验。

运行效率要求不是特别高的地方都可以用，比如日志服务器、文件服务器、大量的压力测试程序、文本处理等。