architecture - Elixir/erlang은 마이크로 서비스 접근 방식에 어디에 적합합니까?



docker microservices (1)

이것은 매우 개방적인 질문이지만 분산 시스템을 개발하기 위해 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를 사용하면 이미 통신 프로토콜과 직렬화 메커니즘이 있습니다. 두 대의 컴퓨터가 서로 통신하도록하려면 해당 컴퓨터에 이름을 지정하고 동일한 비밀을 유지해야합니다.

Jamie는 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 Distributed Protocol을 사용하여이 모든 것을 실행하면 다른 노드에서 실행할 수 있으며 {:[email protected], :name} 참조하는 한 다른 노드에 도달 할 수 {:[email protected], :name} 대신 {:[email protected], :name}

더 나아갈 수 있지만이 시점에서 당신을 설득했으면합니다. :)

최근에 여러 협업 마이크로 서비스를 배포하기 위해 docker compose로 몇 가지 실험을 해왔습니다. 마이크로 서비스가 제공하는 많은 이점을 볼 수 있으며 이제는이를 관리하기위한 훌륭한 도구 세트가 있으므로 마이크로 서비스 마차에 뛰어 드는 것이 그리 어렵지 않다고 생각합니다.

그러나 나는 Elixir도 실험하고 있으며, 그 자체로 제공되는 이점을 아주 좋아합니다. 코드를 여러 개의 분리 된 응용 프로그램으로 포장하고 핫 코드 업그레이드를 지원한다고 가정하면 docker와 elixir (또는 erlang)를 어떻게 혼합합니까?

예를 들어, dev-prod 패리티를 제공하기 때문에 docker를 사용하려면 elixir가 어떻게 적용됩니까? 도커 컨테이너가 변경 불가능하다는 것을 감안할 때 핫 코드 업그레이드를 수행 할 수있는 능력이 손실됩니까? 블루 / 그린 배포 또는 카나리아 릴리스는 어떻습니까?

엘릭서로 마이크로 서비스를 작성하여 마치 다른 언어로 작성된 것처럼 사용할 수 있습니다. 순수한 협업 erlang 애플리케이션이 중간 큐를 사용하여 다른 언어로 작성된 마이크로 서비스간에 통신하는 것보다 훨씬 더 최적이라고 생각하십시오.





microservices