Elixir / erlangはマイクロサービスアプローチにどこに適合しますか？[閉まっている]

最近、共同作業する複数のマイクロサービスをデプロイするために、Docker Composeでいくつかの実験を行っています。マイクロサービスが提供する多くの利点を見ることができ、それらを管理するための優れたツールセットがあるので、マイクロサービスワゴンに飛び込むことはそれほど難しくないと思います。

しかし、私はElixirも実験しており、それ自体がもたらす利点をとても気に入っています。それはあなたのコードを複数の分離されたアプリケーションに詰め込むことを奨励し、ホットコードのアップグレードをサポートすることを考えると、どのようにdockerをelixir（またはそのことについてはerlang）と混合しますか？

たとえば、dev-prodパリティを提供するためにdockerを使用したい場合、elixirはそれにどのように適合しますか？Dockerコンテナーは不変であることを考えると、ホットコードのアップグレードを実行できなくなりますよね？青/緑のデプロイメントまたはカナリアリリースについてはどうですか？

つまり、Elixirでマイクロサービスを作成して、他の言語で作成されているかのようにそれらを使用することができます。ポリグロティズムは、いずれにせよマイクロサービスの利点の1つですが、OTPプラットフォームを使用することの完全な利点は得られません。純粋なコラボレーティブerlangアプリケーションは、中間のキューを使用して異なる（または異なる）言語で記述されたマイクロサービス間で通信するよりもはるかに最適であると推測します。

これは非常にオープンな質問ですが、分散システムの開発にElixir / Erlangが最適なプラットフォームである理由を説明しようと思います（マイクロサービスを使用しているかどうかに関係なく）。

まず、いくつかの背景から始めましょう。Erlang VMとその標準ライブラリは、分散システムを構築するために事前に設計されており、これは実際に現れています。私の知る限り、これは、このユースケース用に事前に設計された本番環境で広く使用されている唯一のランタイムとVMです。

用途

たとえば、すでに「アプリケーション」をほのめかしています。Erlang / Elixirでは、コードは次のようなアプリケーション内にパッケージ化されています。

1. ユニットとして開始および停止されます。システムの起動と停止は、システム内のすべてのアプリケーションを起動することの問題です
2. 統一されたディレクトリ構造と構成API（XMLではありません！）を提供します。OTPアプリケーションをすでに使用して構成している場合は、他のアプリケーションを使用する方法を知っています。
3. アプリケーション監視ツリーと、すべてのプロセス（プロセスとは、計算の軽量スレッドである「VMプロセス」を意味します）とその状態を含みます

このデザインの影響は巨大です。これは、Elixir開発者がアプリケーションを作成するときに、より明確なアプローチをとることを意味します。

1. コードの開始方法と停止方法
2. アプリケーションの一部を構成するプロセスは何か、したがってアプリケーションの状態は何か
3. クラッシュまたは何か問題が発生した場合に、これらのプロセスがどのように反応して影響を受けるか

それだけでなく、この抽象化に関連するツールは素晴らしいです。Elixirがインストールされている場合は、「iex」を開き、次のように入力します:observer.start()。ライブシステムに関する情報とグラフを表示するだけでなく、ランダムプロセスを強制終了し、メモリの使用状況や状態などを確認できます。これは、Phoenixアプリケーションでこれを実行する例です。

ここでの違いは、アプリケーションとプロセスが、本番環境でのコードに関する推論の抽象化を提供することです。多くの言語は、ランタイムシステムに反映せずに、主にコード編成のためのパッケージ、オブジェクト、およびモジュールを提供しています。クラス属性またはシングルトンオブジェクトがある場合、それを操作できるエンティティについてどのように推論できますか？メモリリークまたはボトルネックがある場合、それを担当するエンティティをどのようにして見つけることができますか？

分散システムを実行している誰かに尋ねると、それは彼らが望む一種の洞察であり、Erlang / Elixirを使用すると、それをビルディングブロックとして使用できます。

コミュニケーション

これらすべてはほんの始まりにすぎません。分散システムを構築する場合、通信プロトコルとデータシリアライザーを選択する必要があります。多くの人がHTTPとJSONを選択します。HTTPとJSONは、考えてみると、実際にRPC呼び出しを実行するための非常に冗長で高価な組み合わせです。

Erlang / Elixirを使用すると、箱から出してすぐに通信プロトコルとシリアル化メカニズムを利用できます。2台のマシンが互いに通信するようにしたい場合は、それらに名前を付け、同じシークレットがあることを確認するだけで済みます。

ジェイミーは、Erlang Factory 2015でこれについて、またこれを活用してゲームプラットフォームを構築する方法について話しました：https : //www.youtube.com/watch?v=_i6n-eWiVn4

HTTPとJSONを使用する場合も問題ありません。プラグインのようなライブラリやフェニックスのようなフレームワークは、ここでも生産性を保証します。

マイクロサービス

これまでのところ、マイクロサービスについては触れていません。これまでのところ、彼らは本当に重要ではないためです。すでに分離されている非常に小さなプロセスを中心にシステムとノードを設計しています。必要に応じて、ナノサービスと呼んでください。

それだけでなく、アプリケーションとしてパッケージ化され、アプリケーションをユニットとして開始および停止できるエンティティとしてグループ化します。アプリケーションA、B、Cがあり、それらを[A、B] + [C]または[A] + [B] + [C]としてデプロイする場合、そうすることで問題はほとんど発生しません。それらの固有の設計に。または、さらに良いことに、マイクロサービスの導入の複雑さをシステムに事前に追加したくない場合は、それらをすべて同じノードに導入するだけで済みます。

そして、結局のところ、Erlang Distributed Protocolを使用してこれらすべてを実行している場合は、それらを別のノードで実行でき、の{:node@network, :name}代わりにを参照している限り、他のノードにアクセスできます:name。

さらに先に進むこともできますが、この時点であなたを納得させたいと思います。:)