Elixir / erlang在哪里适合微服务方法?[关闭]


109

最近,我一直在使用docker compose做一些实验,以部署多个协作微服务。我可以看到微服务提供的许多好处,并且现在有了一个很好的工具集来管理它们,我认为跳入微服务旅行并不难。

但是,我也一直在尝试Elixir,我非常喜欢它本身提供的好处。鉴于它鼓励将代码打包到多个解耦的应用程序中,并支持热代码升级,您如何将docker与elixir(或erlang)混合使用?

例如,如果我要使用docker,因为它提供了dev-prod奇偶校验,那么elixir怎么适合呢?鉴于Docker容器是不可变的,我将失去进行热代码升级的能力,对吗?蓝色/绿色部署或Canary版本又如何呢?

我的意思是,我可以用Elixir编写微服务,并像使用其他任何语言编写微服务一样使用。多语制仍然是微服务的好处之一,但是我没有得到使用OTP平台的全部好处,我猜想纯协作式erlang应用程序比使用中间队列在以不同(或不同)语言编写的微服务之间进行通信的方式更为优化。


7
我看到投票否决是因为问题“没有显示任何研究成果”。这很可悲,因为它不是真的,当然问题可能出在问题本身上,但是我不能因为没有研究而被指责,因为这是我最近一直在做的事情。很多。
2015年

1
这个问题太广泛了-有关stackoverflow的问题旨在包含特定的问题。
帕维尔Obrok

4
我应该将其移至另一个Stackexchange网站吗?因为该问题是合法的IMO。
2015年

2
我认为这是一个有趣的问题,但可能属于程序员stackexchange吗?话虽这么说,但没有投票关闭
乔治·莫尔

1
太棒了,完全适合这份工作。
布莱恩·亨特(Bryan hunt)

Answers:


138

这是一个非常开放的问题,但是我将尝试说明为什么Elixir / Erlang可能是开发分布式系统的最佳平台(无论您是否使用微服务)。

首先,让我们从一些背景开始。Erlang VM及其标准库是为构建分布式系统而预先设计的,这确实可以证明这一点。据我所知,它是在生产环境中为此用途预先设计的唯一运行时和VM。

应用领域

例如,您已经提示“应用程序”。在Erlang / Elixir中,代码打包在以下应用程序内部:

  1. 作为一个单元启动和停止。启动和停止系统是启动系统中所有应用程序的问题
  2. 提供统一的目录结构和配置API(不是XML!)。如果您已经使用并配置了OTP应用程序,那么您将知道如何使用其他任何应用程序
  3. 包含您的应用程序监视树,其中包含所有进程(按进程,我的意思是“ VM进程”,它们是轻量级的计算线程)及其状态

这种设计的影响是巨大的。这意味着Elixir开发人员在编写应用程序时可以采用更明确的方法来:

  1. 他们的代码如何启动和停止
  2. 构成应用程序一部分的过程是什么,因此应用程序状态是什么
  3. 在崩溃或出现问题时,这些过程将如何反应并受到影响

不仅如此,围绕这种抽象的工具也很棒。如果您已安装Elixir,请打开“ iex”并键入::observer.start()。除了显示有关实时系统的信息和图表之外,您还可以杀死随机进程,查看其内存使用情况,状态等。这是在Phoenix应用程序中运行此示例:

带有Phoenix应用程序的观察者

此处的区别在于,应用程序和流程为您提供了有关生产中代码原因抽象。许多语言提供的包,对象和模块主要用于代码组织,而对运行时系统没有影响。如果您具有类属性或单例对象:如何推理可以操纵它的实体?如果您有内存泄漏或瓶颈,如何找到造成此问题的实体?

如果您要求运行分布式系统的任何人,这就是他们想要的洞察力,而使用Erlang / Elixir则可以作为基础。

通讯

所有这一切仅仅是开始。构建分布式系统时,需要选择通信协议和数据串行器。很多人选择HTTP和JSON,当您考虑使用它们时,它们对于执行真正的RPC调用是非常冗长且昂贵的组合。

使用Erlang / Elixir,您已经可以立即使用通信协议和序列化机制。如果要使两台机器相互通信,则只需给它们命名,确保它们具有相同的机密即可。

杰米(Jamie)在2015年的Erlang Factory上谈论了这一点,以及他们如何利用它来构建游戏平台:https : //www.youtube.com/watch?v=_i6n-eWiVn4

如果您想使用HTTP和JSON,那也很好,Plug之类的库和Phoenix之类的框架也将保证您在这里也很高效。

微服务

到目前为止,我还没有谈论微服务。这是因为到目前为止,它们并不重要。您已经在围绕孤立的非常小的流程设计系统和节点。如果需要,可以将它们称为nanoservices!

不仅如此,它们还被打包到应用程序中,这些应用程序将它们分组为可以作为一个单元启动和停止的实体。如果您有应用程序A,B和C,然后要将它们部署为[A,B] + [C]或[A] + [B] + [C],那么这样做的麻烦将很小。为其固有的设计。或者,甚至更好的是,如果您希望避免将微服务部署的复杂性提前添加到系统中,则可以将它们完全部署在同一节点中。

而且,归根结底,如果您使用Erlang Distributed Protocol运行所有这些,则可以在不同的节点上运行它们,并且只要您引用{:node@network, :name}而不是,它们就可以访问其他节点:name

我可以走得更远,但我希望在这一点上已经说服了您。:)


实际上,我非常喜欢Elixir和OTP,问题更多的是关于在使用Elixir时如何获得微服务的一些好处(如dev-prod奇偶校验,canary发布等)。
2015年

我有一篇关于Docker的文章,但它迷路了。:)要点是您将其用于节点部署,因此您可以选择每个节点有意义的应用程序。蓝色/绿色部署绝对是可以实现的,但取决于协议,状态类型和其他因素。
何塞·瓦利姆(JoséValim)

5
我提到的话题涵盖了可用于蓝/绿或金丝雀的路由层。同样,这取决于选择的协议,但是您可以从分布式Erlang中的全局条目开始,使用consul进行操作,或者使用基于HTTP的haproxy。
何塞·瓦利姆(JoséValim)

服务发现方法很有意义。我想我一直在考虑负载平衡条件。
2015年

1
微服务的其他好处之一,例如为特定任务选择最佳语言。我喜欢长生不老药,但这不是每项任务的最佳语言。我的意思是可能需要一种特定的微服务使用另一种语言而不是长生不老药。那么,它是否仍应遵循传统的微服务架构?
Jeancarlo '17
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.