Де Elixir / erlang вписується у підхід до мікропослуг? [зачинено]

Останнім часом я робив кілька експериментів із докерським складом, щоб розгорнути декілька співпрацюючих мікросервісів. Я бачу багато переваг, які надають мікросервіси, і тепер, коли є хороший набір інструментів для управління ними, я думаю, що не дуже важко заскочити у вагон мікросервісів.

Але я також експериментував з Еліксиром, і мені дуже подобаються переваги, які дає сам собою. Зважаючи на те, що він заохочує пакувати ваш код у декілька роз'єднаних програм та підтримує гарячі оновлення коду, як би ви змішали докер з еліксиром (або з цього питання erlang)?

Наприклад, якщо я хочу використовувати докер через те, що він забезпечує паритет dev-prod, то як еліксир може входити до цього? З огляду на те, що контейнери докера незмінні, я втрачаю можливість робити оновлення гарячого коду, правда? Що з синьо / зеленими розгортаннями або канарними випусками?

Я маю на увазі, що я можу просто писати мікросервіси за допомогою Elixir і використовувати їх так, як ніби вони написані будь-якою іншою мовою, поліглотизм так чи інакше є однією з переваг мікросервісів, але тоді я не отримую всіх переваг використання платформи OTP, я здогадуйтесь, що чисті спільні програми erlang набагато оптимальніші, ніж використання проміжних черг для спілкування між мікропослугами, написаними різними (чи ні) мовами.

Це дуже відкрите питання, але я спробую проілюструвати, чому Elixir / Erlang може бути найкращою платформою для розвитку розподілених систем (незалежно від того, чи працюєте ви з мікросервісами).

Спочатку почнемо з деякого тла. Erlang VM та його стандартна бібліотека були розроблені наперед для побудови розподілених систем, і це дійсно проявляється. Наскільки мені відомо, це єдиний час виконання та VM, широко використовуваний у виробництві, розробленому наперед для цього випадку використання.

Програми

Наприклад, ви вже натякали на "додатки". У Erlang / Elixir код упаковується всередині додатків, які:

1. запускаються і зупиняються як одиниця. Запуск та зупинка вашої системи - це питання запуску всіх програм у ній
2. надати API уніфікованої структури та конфігураційного каталогу (що не є XML!). Якщо ви вже працювали та налаштовували додаток OTP, ви знаєте, як працювати з будь-яким іншим
3. містить ваше дерево нагляду за програмами, з усіма процесами (під процесом я маю на увазі "процеси VM", які є легкими нитками обчислень) та їх станом

Вплив цієї конструкції величезний. Це означає, що розробники Elixir під час написання програм мають більш чіткий підхід до:

1. як запускається і зупиняється їх код
2. які процеси є частиною програми та, отже, який стан програми
3. як реагуватимуть на цей процес і на яких впливатимуть у разі аварій або коли щось піде не так

Мало того, що інструменти навколо цієї абстракції чудові. Якщо у вас є Еліксир встановлений, відкрийте «Iex» і введіть: :observer.start(). Окрім показу інформації та графіків про вашу живу систему, ви можете вбивати випадкові процеси, бачити використання їх пам'яті, стан тощо. Ось приклад запуску цього в додатку Phoenix:

Різниця тут полягає в тому, що програми та процеси дають вам абстракцію про міркування про ваш код у виробництві . Багато мов надають пакети, об'єкти та модулі, здебільшого для організації коду, без відображення на системі виконання. Якщо у вас є атрибут класу або однотонний об’єкт: як можна міркувати про сутності, які можуть ним маніпулювати? Якщо у вас є витік пам'яті або вузьке місце, як ви можете знайти відповідальну за це організацію?

Якщо ви запитаєте будь-кого, хто працює з розподіленою системою, то це таке розуміння, яке вони хочуть, і з Erlang / Elixir у вас це є складовим елементом.

Зв'язок

Все це справді лише початок. При побудові розподіленої системи потрібно вибрати протокол зв'язку та серіалізатор даних. Дуже багато людей обирають HTTP та JSON, що, коли ви думаєте про це, є дуже багатослівним та дорогим поєднанням для виконання того, що насправді викликає RPC.

З Erlang / Elixir у вас уже є протокол зв'язку та механізм серіалізації поза коробкою. Якщо ви хочете, щоб два машини спілкувалися один з одним, вам потрібно лише дати їм імена, переконатися, що вони мають однаковий секрет, і ви все зробили.

Джеймі розповів про це на Erlang Factory 2015 та про те, як їм вдалося використати це для створення ігрової платформи: https://www.youtube.com/watch?v=_i6n-eWiVn4

Якщо ви хочете використовувати HTTP та JSON, це теж добре, а бібліотеки на зразок Plug та фреймворки на зразок Phoenix гарантують, що ви тут також продуктивні.

Мікросервіси

Поки що я не говорив про мікросервіси. Це тому, що до цього часу вони насправді не мають значення. Ви вже проектуєте свою систему та вузли навколо дуже крихітних процесів, які є ізольованими. Зателефонуйте їм, якщо ви хочете!

Мало того, вони також упаковані в додатки, які групують їх як сутності, які можна запустити і зупинити як одиницю. Якщо у вас є програми A, B і C, і ви хочете розгорнути їх як [A, B] + [C] або [A] + [B] + [C], у вас виникнуть дуже маленькі проблеми з цим через до їх притаманного дизайну. Або ще краще, якщо ви хочете уникнути додавання складності розгортання мікросервісів у вашій системі наперед, ви можете просто розгорнути їх цілком у тому ж вузлі.

І, нарешті, якщо ви все це запускаєте за допомогою розподіленого протоколу Erlang, ви можете запустити їх у різних вузлах, і вони зможуть дістатися до інших, якщо ви посилаєтесь на них {:node@network, :name}замість :name.

Я міг би піти далі, але сподіваюся, що я переконав вас у цьому пункті. :)