Elixir/erlang 在哪里适合微服务方法? [英] Where does Elixir/erlang fit into the microservices approach?

问题描述

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

Lately I've been doing some experiments with docker compose in order to deploy multiple collaborating microservices. I can see the many benefits that microservices provide, and now that there is a good toolset for managing them, I think that it's not extremely hard to jump into the microservices wagon.

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

But, I have been experimenting with Elixir too, and I am quite fond of the benefits that provides by itself. Given that it encourages packing your code into multiple decoupled applications, and supports hot code upgrades, how would you mix docker with elixir (or erlang, for that matter)?

例如，如果我想使用 docker，因为它提供了 dev-prod parity，那么 elixir 是如何适应的?鉴于 docker 容器是不可变的，我失去了进行热代码升级的能力，对吗?蓝/绿部署或金丝雀版本怎么样?

For example, if I want to use docker because it provides dev-prod parity, how does elixir fit in that? Given that docker containers are immutable, I lose the ability to do hot-code upgrades, right? What about blue/green deployments or canary releases?

我的意思是，我可以用 Elixir 编写微服务，然后像用任何其他语言编写一样使用它们，无论如何，多语言是微服务的好处之一，但是我没有得到使用 OTP 的全部好处平台，我想纯协作 erlang 应用程序比使用中间队列在用不同(或不是)语言编写的微服务之间进行通信更优化.

I mean, I could just write microservices with Elixir and use them as if they were written in any other language, polyglotism is one of the benefits of microservices anyway, but then I'm not getting the full benefits of using the OTP platform, I guess that pure collaborative erlang applications are way more optimal that using intermediate queues to communicate between microservices written in different (or not) languages.

推荐答案

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

This is a very open question but I will try to illustrate why Elixir/Erlang may be the best platform out there for developing distributed systems (regardless if you are working with microservices).

首先，让我们从一些背景开始.Erlang VM 及其标准库是为构建分布式系统而预先设计的，这确实显示出来了.据我所知，它是唯一在生产中广泛使用的运行时和 VM，为此用例预先设计.

First, let's start with some background. The Erlang VM and its standard library were designed upfront for building distributed systems and this really shows up. As far as I know, it is the only runtime and VM used widely in production designed upfront for this use case.

例如，您已经暗示了应用程序".在 Erlang/Elixir 中，代码打包在应用程序中:

For example, you have already hinted at "applications". In Erlang/Elixir, code is packaged inside applications which:

1. 作为一个单元开始和停止.启动和停止系统就是启动其中的所有应用程序
2. 提供统一的目录结构和配置 API(不是 XML！).如果您已经使用并配置过 OTP 应用程序，您就会知道如何使用其他任何应用程序
3. 包含您的应用程序监督树，以及所有进程(我所说的进程是指轻量级计算线程的VM 进程")及其状态

这个设计的影响是巨大的.这意味着 Elixir 开发人员在编写应用程序时有更明确的方法:

The impact of this design is huge. It means that Elixir developers, when writing applications have a more explicit approach to:

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

不仅如此，围绕这种抽象的工具也很棒.如果你安装了 Elixir，打开iex"并输入::observer.start().除了显示有关您的实时系统的信息和图表外，您还可以终止随机进程，查看它们的内存使用情况、状态等.下面是在 Phoenix 应用程序中运行它的示例:

Not only that, the tooling around this abstraction is great. If you have Elixir installed, open up "iex" and type: :observer.start(). Besides showing information and graphs about your live system, you can kill random processes, see their memory usage, state and more. Here is an example of running this in a Phoenix application:

这里的区别在于应用程序和进程为您提供了一个抽象来推理生产中的代码.许多语言提供包、对象和模块主要用于代码组织，而不反映运行时系统.如果您有一个类属性或一个单例对象:您如何推理可以操作它的实体?如果您有内存泄漏或瓶颈，您如何找到对此负责的实体?

The difference here is that Applications and Processes give you an abstraction to reason about your code in production. Many languages provides packages, objects and modules mostly for code organization with no reflection on the runtime system. If you have a class attribute or a singleton object: how can you reason about the entities that can manipulate it? If you have a memory leak or a bottleneck, how can you find the entity responsible for it?

如果你问任何运行分布式系统的人，这就是他们想要的洞察力，而使用 Erlang/Elixir，你可以将其作为构建块.

If you ask anyone running a distributed system, that's the kind of insight that they want, and with Erlang/Elixir you have that as the building block.

这一切真的只是一个开始.在构建分布式系统时，需要选择通信协议和数据序列化器.很多人选择 HTTP 和 JSON，仔细想想，对于执行真正的 RPC 调用来说，这是一个非常冗长和昂贵的组合.

All of this is just the beginning really. When building a distributed system, you need to choose a communication protocol and the data serializer. A lot of people choose HTTP and JSON which, when you think about it, is a very verbose and expensive combination for performing what is really RPC calls.

使用 Erlang/Elixir，您已经拥有开箱即用的通信协议和序列化机制.如果你想让两台机器互相通信，你只需要给它们命名，确保它们有相同的秘密，你就完成了.

With Erlang/Elixir, you already have a communication protocol and a serialization mechanism out of the box. If you want to have two machines communicating with each other, you only need to give them names, ensure they have the same secret, and you are done.

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

Jamie talked about this at Erlang Factory 2015 and how they were able to leverage this to build a game platform: https://www.youtube.com/watch?v=_i6n-eWiVn4

如果您想使用 HTTP 和 JSON，那也很好，Plug 之类的库和 Phoenix 之类的框架也可以保证您在这里也能高效工作.

If you want to use HTTP and JSON, that is fine too and libraries like Plug and frameworks like Phoenix will guarantee you are productive here too.

到目前为止我还没有谈到微服务.那是因为，到目前为止，它们并不重要.您已经在围绕非常小的孤立进程设计系统和节点.如果您愿意，可以将它们称为纳米服务！

So far I haven't talked about microservices. That's because, up to this point, they don't really matter. You are already designing your system and nodes around very tiny processes that are isolated. Call them nanoservices if you'd like to!

不仅如此，它们还被打包到应用程序中，应用程序将它们分组为可以作为单元启动和停止的实体.如果您有应用程序 A、B 和 C，然后您想将它们部署为 [A, B] + [C] 或 [A] + [B] + [C]，那么这样做不会有什么麻烦，因为到他们固有的设计.或者，更好的是，如果您想避免预先将微服务部署的复杂性添加到您的系统中，您可以将它们完全部署在同一节点中.

Not only that, they are also packaged into applications, which group them as entities that can be started and stopped as unit. If you have applications A, B and C, and then you want to deploy them as [A, B] + [C] or [A] + [B] + [C], you will have very little trouble in doing so due to their inherent design. Or, even better, if you want to avoid adding the complexity of microservices deployments into your system upfront, you can just deploy them altogether in the same node.

而且，归根结底，如果你使用 Erlang 分布式协议运行所有这些，你可以在不同的节点上运行它们，只要你通过 {:node@network, :name} 而不是 :name.

And, at the end of the day, if you are running all of this using the Erlang Distributed Protocol, you can run them in different nodes and they will be able to reach other as long as you refer to them by {:node@network, :name} instead of :name.

我可以走得更远，但我希望我现在已经说服了你.:)

I could go further but I hope I have convinced you at this point. :)

这篇关于Elixir/erlang 在哪里适合微服务方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！