Gdzie Elixir / erlang pasuje do podejścia mikroserwisowego? [Zamknięte]

Ostatnio przeprowadzałem kilka eksperymentów z docker compose, aby wdrożyć wiele współpracujących mikrousług. Widzę wiele korzyści, jakie zapewniają mikrousługi, a teraz, gdy istnieje dobry zestaw narzędzi do zarządzania nimi, myślę, że nie jest niezwykle trudno wskoczyć do wagonu mikrousług.

Ale eksperymentowałem również z Elixirem i bardzo lubię korzyści, które zapewnia sam. Biorąc pod uwagę, że zachęca to do umieszczania kodu w wielu oddzielnych aplikacjach i obsługuje aktualizacje kodu na gorąco, jak można połączyć docker z eliksirem (lub erlang, jeśli o to chodzi)?

Na przykład, jeśli chcę używać dockera, ponieważ zapewnia on parzystość dev-prod, jak ma się do tego eliksir? Biorąc pod uwagę, że kontenery Dockera są niezmienne, tracę możliwość wykonywania uaktualnień typu hot-code, prawda? A co z niebieskimi / zielonymi wdrożeniami lub wydaniami canary?

Chodzi mi o to, że mógłbym po prostu pisać mikrousługi w Elixirze i używać ich tak, jakby były napisane w jakimkolwiek innym języku, poliglotyzm i tak jest jedną z zalet mikrousług, ale wtedy nie mam pełnych korzyści z korzystania z platformy OTP, ja zgaduję, że aplikacje erlang oparte wyłącznie na współpracy są o wiele bardziej optymalne niż używanie kolejek pośrednich do komunikacji między mikrousługami napisanymi w różnych (lub nie) językach.

To bardzo otwarte pytanie, ale spróbuję zilustrować, dlaczego Elixir / Erlang może być najlepszą platformą do tworzenia systemów rozproszonych (niezależnie od tego, czy pracujesz z mikrousługami).

Najpierw zacznijmy od tła. Maszyna wirtualna Erlang i jej biblioteka standardowa zostały zaprojektowane z góry do tworzenia systemów rozproszonych i to naprawdę się sprawdza. O ile wiem, jest to jedyne środowisko uruchomieniowe i maszyna wirtualna szeroko stosowane w produkcji, zaprojektowane z góry dla tego przypadku użycia.

Aplikacje

Na przykład wspomniałeś już o „aplikacjach”. W Erlang / Elixir kod jest spakowany wewnątrz aplikacji, które:

1. są uruchamiane i zatrzymywane jako jednostka. Uruchamianie i zatrzymywanie systemu to kwestia uruchomienia w nim wszystkich aplikacji
2. zapewniają ujednoliconą strukturę katalogów i konfiguracyjny interfejs API (który nie jest XML!). Jeśli już pracowałeś i skonfigurowałeś aplikację OTP, wiesz, jak pracować z każdą inną
3. zawiera drzewo nadzoru Twojej aplikacji, ze wszystkimi procesami (przez proces rozumiem "procesy VM", które są lekkimi wątkami obliczeniowymi) i ich stanem

Wpływ tego projektu jest ogromny. Oznacza to, że programiści Elixir pisząc aplikacje mają bardziej jednoznaczne podejście do:

1. jak ich kod jest uruchamiany i zatrzymywany
2. jakie procesy składają się na aplikację, a zatem jaki jest stan aplikacji
3. jak ten proces będzie reagował i jak wpłynie na niego awarie lub gdy coś pójdzie nie tak

Co więcej, oprzyrządowanie wokół tej abstrakcji jest świetne. Jeśli masz zainstalowany Elixir, otwórz „iex” i wpisz: :observer.start(). Oprócz wyświetlania informacji i wykresów dotyczących systemu na żywo, możesz zabijać losowe procesy, sprawdzać zużycie pamięci, stan i nie tylko. Oto przykład uruchomienia tego w aplikacji Phoenix:

Różnica polega na tym, że aplikacje i procesy dają abstrakcję do rozumowania kodu w produkcji . Wiele języków udostępnia pakiety, obiekty i moduły głównie do organizacji kodu bez refleksji nad systemem wykonawczym. Jeśli masz atrybut klasy lub obiekt pojedynczy: jak możesz wnioskować o jednostkach, które mogą nim manipulować? Jeśli masz wyciek pamięci lub wąskie gardło, jak możesz znaleźć podmiot za to odpowiedzialny?

Jeśli zapytasz kogoś, kto używa systemu rozproszonego, właśnie tego chce, a Erlang / Elixir to podstawa.

Komunikacja

To wszystko tak naprawdę to dopiero początek. Budując system rozproszony, należy wybrać protokół komunikacyjny oraz serializator danych. Wiele osób wybiera HTTP i JSON, które, kiedy się nad tym zastanowić, są bardzo rozwlekłą i kosztowną kombinacją do wykonywania tak naprawdę wywołań RPC.

Dzięki Erlang / Elixir masz już protokół komunikacyjny i mechanizm serializacji od razu po wyjęciu z pudełka. Jeśli chcesz, aby dwa komputery komunikowały się ze sobą, wystarczy nadać im nazwy, upewnić się, że mają ten sam sekret i gotowe.

Jamie mówił o tym w Erlang Factory 2015 io tym, jak mogli to wykorzystać do zbudowania platformy do gier: https://www.youtube.com/watch?v=_i6n-eWiVn4

Jeśli chcesz używać HTTP i JSON, to też jest w porządku, a biblioteki takie jak Plug i frameworki, takie jak Phoenix, gwarantują, że również tutaj będziesz produktywny.

Mikrousługi

Do tej pory nie mówiłem o mikroserwisach. To dlatego, że do tego momentu nie mają one znaczenia. Już projektujesz swój system i węzły wokół bardzo małych procesów, które są izolowane. Nazywaj je nanoserwisami, jeśli chcesz!

Co więcej, są one również pakowane w aplikacje, które grupują je jako jednostki, które można uruchamiać i zatrzymywać jako jednostkę. Jeśli masz aplikacje A, B i C, a następnie chcesz je wdrożyć jako [A, B] + [C] lub [A] + [B] + [C], nie będziesz miał z tym problemów, ponieważ do ich wrodzonej konstrukcji. A nawet lepiej, jeśli chcesz uniknąć dodawania z góry złożoności wdrożeń mikrousług w systemie, możesz po prostu wdrożyć je w całości w tym samym węźle.

I na koniec dnia, jeśli wykonujesz to wszystko za pomocą protokołu rozproszonego Erlang, możesz uruchomić je w różnych węzłach i będą one mogły dotrzeć do innych, o ile będziesz się do nich odwoływać {:node@network, :name}zamiast :name.

Mógłbym pójść dalej, ale mam nadzieję, że przekonałem Cię w tym momencie. :)