- Actor model 을 기반으로 만들어진 Akka는 몇 가지 Component로 구성
- Dispatcher: Actor System 내에서 실행되는 모든 코드를 스케줄링하며 각 Actor의 처리량과 시간 점유율을 조정하여 각자에게 공정한 리소스를 제공
- Mailbox: Dispatcher에서 들어오는 메시지를 담는 메시징 큐로 Actor마다 Mailbox를 가지고 있으며 들어온 메시지의 순서대로 Actor에서 소비
- Actor: 시스템을 구성하는 일종의 행위 객체로 메시지를 실질적으로 필요로 하는 소비자 및 송/수신자
- 계층구조
- Akka Actor 계층 구조는 트리 형태로 표현 가능
- Parent Actor node는 다수의 Child Actor node를 가질 수 있어 Parent Actor 가 Child Actor를 생성, 삭제 가능
- Actor 예제
- ParentActor에서 메시지 라우팅을 통한 행동들을 정의한다.
- ChildActor에서 메시지 라우팅을 통한 행동을 정의한다.
- Actor의 행동 및 계층 구조를 설계해서 메시지를 전송할 수 있게 만들면 유연하고 간단하게 메시지에 따라 프로세싱
- UserChat -> ChatRoom -> Broadcast to all users: 채팅방을 구현한다고 한다면 그림과 같은 구조로 Actor들을 설계해서 구현
- 정말 간단한 수준의 채팅 서버에 대한 Actor 설계지만 Akka framework를 이용하면 실제로 고성능의 채팅 서버를 비교적 간단하게 만들 수 있음
- Actor의 상태 변경 및 행동 지시는 메시지 통신을 통한 간접적 지시에 의해 처리
- 메시지가 발생하면 원하는 액터에게 메시지를 보낼 수 있다.
- 메시지를 통해 행동이 결정되면 Actor 자신의 상태를 변경하거나 Child Actor를 만들거나 죽이고, 다른 Actor에 메시지를 보낼 수 있음
- 장점
- 직관성: Actor model이라는 개념 자체가 꽤 직관적인 부분이 있어 내가 원하는 Actor를 정의해서 Actor 간의 통신을 구성하는 것이 상대적으로 쉽다.
- 확장성: Akka framework는 클러스터 형식으로 운영할 수 있기 때문에 물리적인 확장성에서도 대응이 된다.
- 격리성: Actor에 직접적인 제어권을 갖거나 접근하기 위한 API가 존재하는 게 아니라 모든 것이 메시지로 인해서 비동기적으로 동작하기 때문에 직접적으로 다른 Actor에 영향을 줄 가능성이 거의 없다.
- 유지 보수: Actor들의 행위가 메시징을 통해서 이뤄지다 보니 Actor의 행위 및 메시지 등에 의하여 전체 시스템에 대한 이해가 없으면 유지 보수하기 어려워질 수 있다.
- Type Not Safe: 정적언어의 컴파일 타임에서 개발자의 실수를 최소한으로 줄여주는 장점을 활용하기 어렵다. Actor의 메시지 송수신 타입이 Any이기 때문이다.
- Akka Typed를 시도해보아야 함