Erlang到底好在哪里_Erlang的优势与缺陷

Erlang到底好在哪里？

因为能力有限，对Erlang的了解仅限皮毛，本文只做简单了解.

从技术上说，Erlang是一个平台，她提供了一套完整的高性能、高可靠网络服务开发所需要的基础设施，并提供了原语给开发人员使用，她降低了开发类似系统的难度与门槛.有一个说法，Erlang让一个中高级程序员，用一半的时间，一半的代码量，就能提供顶尖C程序员开发的网络服务80%性能的类似系统，并且可靠性不输于甚至超过前者。实践证明这是真的.

另一方面，Erlang也给了开发人员强大的自信，就如同前面开发DSF时的场景所述.有开发维护过线上系统的人应该可以深刻的感受到，开发一个高可靠的网络服务有多困难，维护一个线上系统有多劳心，当一个服务上线时，我们的运维与程序员即使睡觉都恨不得睁着一只眼睛.

采用Erlang开发的系统，其出现的bug量与用常规语言开发的绝对不是一个数量级；Erlang的监控树机制，更是让我们的服务，天生就具备了高可靠的基因，只要稍花精力，仔细规划我们的监控树与重启策略，就可以让本来就少了很多的bug及一些无法预料的外部故障，在即使出现时也有很大的几率迅速恢复，给你修复bug排除故障一个缓冲的时间，更何况，Erlang可是具备热更新能力的，那真的可以让你延寿啊！延寿！

如果你的老板问你，为什么要用Erlang，Erlang好在哪里，你可以这样总结：省钱.你想想，一个资深的、顶尖的程序员与中高级普通程序员之间的成本差，普通的系统就只要普通的程序员就好啦，那不仅仅是省钱，是省很多很多的钱.

Erlang的优势与缺陷

Erlang在消息执行方式上的优势在于灵活.Erlang是弱类型语言，在实现的时候可以任意调整消息的内容，或是模式的要求.在 Erlang进行模式匹配时往往有种约定：使用“原子”来表示“做什么”，而使用“绑定”来获取操作所需要的“数据”，这种方式避免了冗余的cast和赋 值，在使用的时候颇为灵活.然而，世上没有完美的事物，Erlang的消息执行方式也有缺陷，而且是较为明显的缺陷.

首先，Erlang的数据抽象能力实在太弱.如果编写一个略显复杂的应用程序，您会发现程序里充斥着复杂的元组.您可能会疲于应对那些拥有7、 8个单元（甚至跟多）的元组，一个一个数过来到底某个绑定匹配的是第几项，它的含义究竟是什么——一旦搞错，程序便会出错，而且想要调试都较为困难.因 此，也有人戏称Erlang是一门“天生会损害人视力的语言”（令人惊讶的是，那篇文章居然搜不到了，我们只能从搜索引擎上看出点痕迹了）.

而我认为，这并不是Erlang语言中最大的问题，Erlang中最大的问题也是其“弱类型”特性.例如，现在有一个公用的Service Locator服务，任意类型的Actor都会像SL发送一个消息用于请求某个Service的位置，SL会在得到请求之后，向请求方发送一条消息表示应 答.试想，如果SL的功能需要有所修改，作为回复的消息结构产生了变化，那么我们势必要修改每一个请求方中所匹配的模式.由于消息的发送方和接受方在实际 上完全分离，没有基于任何协议，因此静态检查几乎无从做起.一旦遇到这种需要大规模的修改的情况，Erlang程序便很容易产生差错.因为一旦有所遗漏， 系统便无法正常执行下去了.

这的确是对于动态类型语言很常见到的担心，而且，确实，如果不加注意会成为严重的问题.这种困扰确实是因为 Erlang 的“动态类型”和“基于消息”而造成的.但，这并非无解，实际上，在 Erlang 编程规范之中，已经给出了解决方案.

通常而言，Erlang 中的消息应该是以“控制流”为主，在消息的数据结构表达上，不同的消息通常都对应着不同的处理流程，在这里“控制”是消息中最为关注的内容.为此我们可以简单的引入一个 atom 来予以表达，这就是 Tag Messages 的最佳实践：

5.7 Tag messages

All messages should be tagged. This makes the order in the receive statement less important and the implementation of new messages easier.

Don’t program like this：

loop（State） ->

receive

...

{Mod， Funcs， Args} -> % Don‘t do this

apply（Mod， Funcs， Args}，

loop（State）;

...

end.

The new message {get_status_info， From， Option} will introduce a conflict if it is placed below the {Mod， Func， Args} message.

If messages are synchronous， the return message should be tagged with a new atom， describing the returned message. Example： if the incoming message is tagged get_status_info， the returned message could be tagged status_info. One reason for choosing different tags is to make debugging easier.

This is a good solution：

loop（State） ->

receive

...

{execute， Mod， Funcs， Args} -> % Use a tagged message.

apply（Mod， Funcs， Args}，

loop（State）;

{get_status_info， From， Option} ->

From ！ {status_info， get_status_info（Option， State）}，

loop（State）;

...

end.

可以相信，一段庞杂的代码，在经过一番这样对 Message 本身的设计和重构之后，最终都能让其恢复“秩序与美感”.而消息中的其他参数，如果其处理逻辑非常复杂的话，那么带有模式匹配的子函数，又或着是 Tuple/Record 正是其用武之地.

上面我们提到了“对 Message 的设计和重构”，实际上，这只是问题的一个方面.另外一个方面是：无论 Message 的“协议”设计得有多精巧，其对外的接口都不应该用消息来表达，而应该是“接口函数”的形式.

Erlang 系统之中的消息是极度灵活的系统，但它并不适合用来作为模块之间的接口，因为它过于灵活.更加适合这一角色的设施是“函数”.用来充当这样角色的函数就被 称作“接口函数”，在其实现代码中，除了“按照约定的格式发消息以外”什么别的也不做——因为它包装的正是以消息为载体的交互“协议”.它是函数，有着严 格的语法检查，而且可以在多个模块之间重用.一旦需要修改消息协议，起隔离作用的“接口函数”就会体现出其存在的巨大价值.

5.10 Interface functions

Use functions for interfaces whenever possible， avoid sending messages directly. Encapsulate message passing into interface functions. There are cases where you can’t do this.

The message protocol is internal information and should be hidden to other modules.

Example of interface function：

-module（fileserver）.

-export（［start/0， stop/0， open_file/1， ...］）.

open_file（FileName） ->

fileserver ！ {open_file_request， FileName}，

receive

{open_file_response， Result} -> Result

end.

...code...

Erlang 是动态语言，对其进行静态检查比较困难（并非不能 R13 已经有所动作）.但，并不是说没有静态检查就会寸步难行.Erlang 同样重要的语法特性是它还是函数式语言，遇到有疑惑的地方，不妨以函数的角度来思考.

Erlang 语言素有“难学”的名声，其中一个原因就是因为虽然其语法十分简单，但常会让人心生 “就这样了，然后呢？” 之惑——因为过于灵活而无所适从，而且也不存在着显而易见的正确用法.这种困扰通常要在有了一定的实践经验之后才会渐渐消散.换句话说，在“学会”和“用 好”之间存在着一堵模模糊糊的墙，而这一“未知区域”又需要一定的耐心和经验方可穿越.