如果应用逻辑是以服务的形式暴露出来的，那么你不用担心其下层语言或平台，你只要根据WSDL契约生成SOAP请求、或直接调用一个REST访问点即可访问服务。无论你用哪种方式访问服务，你都看不出服务背后是什么语言或平台，而且你用什么语言来访问它也无关紧要。然而，在某些环境下，你在客户端或服务端所使用的语言能够有助于服务的设计， 比方说并发环境。下面我将围绕并发环境、以及Erlang语言是如何致力于处理并发行为的进行讨论。

　　并发（concurrency）是计算机科学里的一个经典问题。实际上，它是编程基础课里较早讲到的一个概念，一般我们是通过“哲学家进餐”问题来讲解并发的。简单地说，如果同时执行两个逻辑序列或进程，而且它们有冲突的可能，那么就会出现并发问题。

　　这些情况在图形界面编程里很普遍：若没有考虑到并发，就有可能导致鼠标光标“锁死”或“乱晃”——因为鼠标移动与应用逻辑是同时执行的，这可能会导致潜在的冲突，因而造成上述问题。另外，面向多处理器或多核处理器（它跟多处理器具有同样的效果）的应用也同样存在并发问题。为了利用这些资源，应用在设计时就要把并发考虑进来。

　　那么这些对服务架构有什么影响呢？对一个服务来说，客户端与服务端均有可能出现并发问题。比方说，后端服务收到大量请求，或者有客户端发出需要并发保护的请求。大多数编程语言都能处理并发，但Erlang是最简单的。下面，我将以Java为例说说大家所熟知的编程语言里的并发技术。

　　在Java里，并发主要是通过多线程编程实现的。同步块、方法以及显式启动与停止线程等Java构造成分，正是通过它才能被用于支持并发行为的。多个线程可以在同一程序（进程）里执行，而不用线程之间彼此等候。不过还是得小心，要防止各个线程对给定资源作并发访问——前面那些Java构造成分的唯一目的便在于此。

　　这使得多线程编程成为一项不易完成的任务，因为万一哪里没有做好，就会造成许多并发相关的副作用，如竞争条件（race conditions）、死锁（deadlocks）及“饿死（starvation）”等。那Erlang有何不同呢？首先，Erlang里没有线程（threads）的概念，而是以进程（processes）为主要构造部件——它粒度较粗，因而确保了资源是受保护的、而且在分享资源时不需要特殊的构造成分或语法。

　　不过，也许你在想，Java和许多其他语言也能派生进程，区别在哪里？区别在于，Erlang里的进程可以用异步消息彼此通信。这与大多数语言构成了鲜明的对比：在大多数语言里，进程是自包含的、不彼此通信的；而在Erlang里，不仅进程可以彼此交换消息，而且由于通信是异步进行的、不存在互斥或锁定的情况，所以并发副作用的风险（如死锁或“饿死”等）被降到了最低。

　　尽管Erlang本身并非新事物——八十年代就已经在爱立信内部诞生了——但随着多核处理器的盛行，随着软件即服务（SaaS）进入主流从而对分布式应用有更多需求，Erlang又时兴起来了。 除了Erlang语言，Erlang还以Erlang/OTP（Open Telecom Platform，开放电信平台）的形式发布了出来，这里的OTP代表很多被Erlang语言使用的工具和库。

　　另外，Erlang还在分布式应用中给自己寻求到了一个重要的位置。 下面是一些比较值得关注的Erlang项目：YAWS是一个还在测试中的Web服务器，Apache vs. YAWS展示了它比强壮的Apache Web服务器具有更优越的性能；Apache CouchDB是一种网络数据库服务器；ErlyWeb是一个Web框架；以及Facebook的集成聊天系统，它基本维持在七千万个用户左右。

　　正如这些近期项目的设计者们可以证实的，若不是归功于Erlang能够支持长期运行、并发和高度可靠的分布式系统，这些项目将很难、甚至根本无法解决架构方面的难题。其实，Erlang进程“通过交换消息进行通信”的特性，也是使用与JVM兼容的语言Scala（由Scala Actors库支持）的主要优势之一。

　　从趋势上看，在接下来的几年中，多核处理器以及基于SOA原则的分布式应用的优势基本上是肯定的，因此现在正是你用Erlang（或者是像Scala Actors这样的效仿项目）来重新考虑如何在应用中处理并发问题的最佳时机。