architecture - Elixir / erlang은 microservices 접근법에 어디에 들어 맞습니까?




docker (2)

이것은 매우 열려있는 질문이지만, 필자가 마이크로 서비스로 작업하는 경우에도 왜 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을 선택합니다. 여러분이 생각할 때 실제로 RPC 호출을 수행하기 위해 매우 장황하고 값 비싼 조합입니다.

Erlang / Elixir를 사용하면 통신 프로토콜 및 직렬화 메커니즘을 이미 사용할 수 있습니다. 두 대의 기계가 서로 통신하기를 원할 경우, 이름을주고, 동일한 비밀이 있는지 확인하고 완료해야합니다.

Jamie는 Erlang Factory 2015에서이 점에 대해 이야기했으며 게임 플랫폼을 구축하기 위해이를 어떻게 활용할 수 있는지에 대해 이야기했습니다. https://www.youtube.com/watch?v=_i6n-eWiVn4

HTTP와 JSON을 사용하고 싶다면 Phoenix와 같은 플러그 앤 프레임 워크와 같은 라이브러리도 여기에서 생산성을 보장 할 것입니다.

마이크로 서비스

지금까지 나는 마이크로 서비스에 관해서 이야기하지 않았다. 지금까지는 별 문제가 없었기 때문입니다. 고립 된 매우 작은 프로세스를 중심으로 시스템과 노드를 이미 설계하고 있습니다. 원한다면 나노 서비스라고 부르세요!

뿐만 아니라 응용 프로그램에 패키지화되어 단위로 시작되고 중지 될 수있는 엔터티로 그룹화됩니다. 응용 프로그램 A, B 및 C가 있고 [A, B] + [C] 또는 [A] + [B] + [C]로 배포하려는 경우, 그렇게 할 때 거의 문제가 없습니다 그들의 본래 디자인에. 또는 시스템의 초기 단계에 복잡한 마이크로 서비스를 추가하는 것을 피하려면 동일한 노드에 모두 배포 할 수 있습니다.

그리고 하루가 끝날 무렵에 Erlang Distributed Protocol을 사용하여이 모든 것을 실행한다면 다른 노드에서 실행할 수 있고 {:[email protected], :name} 참조하는 한 다른 {:[email protected], :name} 대신에 :name .

나는 더 멀리 갈 수 있었지만 나는이 시점에서 내가 당신을 확신 시켰 으면 좋겠다. :)

최근에 저는 여러 개의 협업 마이크로 서비스를 배포하기 위해 docker 작성으로 몇 가지 실험을 해왔습니다. 마이크로 서비스가 제공하는 많은 이점을 볼 수 있습니다. 이제는이를 관리하는 데 유용한 도구 세트가 있으므로 마이크로 서비스 왜건으로 뛰어 들기가 극히 어렵지 않습니다.

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

예를 들어, Docker가 dev-prod parity를 ​​제공하기 때문에 docker를 사용하고 싶다면, elixir는 어떻게 적합합니까? 도커 컨테이너가 변경되지 않는다고 가정 할 때, 나는 핫 코드 업그레이드를 수행 할 능력을 잃어 버렸지, 그렇지? 청색 / 녹색 배치 또는 카나리아 방출은 어떻게됩니까?

내 말은, 나는 Elixir를 사용하여 마이크로 서비스를 작성하고 다른 언어로 작성된 것처럼 사용할 수 있지만, 다국어 지원은 어쨌든 마이크로 서비스의 장점 중 하나이지만 OTP 플랫폼을 사용하면 모든 이점을 얻지 못할 것이다. 순수 공동 협업 응용 프로그램이 다른 중간 또는 다른 언어로 작성된 마이크로 서비스 간 통신을 위해 중간 대기열을 사용하는 것이 더 최적이라고 생각하십시오.


엘릭서가 빔 바이트 코드로 직접 컴파일되기 때문에, 신경 쓰이는 경우 지터와 같은 중간 비용을 지불하지 않아도됩니다.





architecture erlang docker elixir microservices