Akka의 좋은 사용 사례 [종료 됨]
Akka 프레임 워크 (Java / Scala 서비스 플랫폼) 에 대한 열광적 인 이야기를 많이 들었지만 지금까지 그것이 좋은 사용 사례의 실제 사례를 많이 보지 못했습니다. 그래서 저는 개발자들이 그것을 성공적으로 사용한 것에 대해 듣고 싶습니다.
한 가지 제한 사항 : 채팅 서버를 작성하는 경우는 포함하지 마십시오. (왜? 이것은 유사한 많은 것들의 예로 남용 되었기 때문에)
지금까지 두 가지 실제 프로젝트에서 매우 성공적으로 사용했습니다. 둘 다 거의 실시간 교통 정보 필드 (고속도로의 자동차와 같은 교통)에 있으며 여러 노드에 분산되어 여러 당사자 간의 메시지 통합, 안정적인 백엔드 시스템입니다. 아직 클라이언트에 대한 세부 사항을 제공 할 자유가 없습니다. 확인을 받으면 참조로 추가 할 수 있습니다.
Akka는 버전 0.7에서 시작했지만 실제로 이러한 프로젝트를 진행했습니다. (우리는 스칼라를 사용하고 있습니다)
큰 장점 중 하나는 보일러 플레이 팅이 거의없이 액터와 메시지로 시스템을 쉽게 구성 할 수 있다는 것입니다. 손으로 돌리는 스레딩의 모든 복잡성없이 매우 잘 확장되며 거의 무료로 객체간에 비동기 메시지를 전달할 수 있습니다.
모든 유형의 비동기 메시지 처리를 모델링하는 데 매우 유용합니다. 나는 다른 어떤 스타일보다이 스타일로 모든 유형의 (웹) 서비스 시스템을 작성하는 것을 선호합니다. (JAX-WS를 사용하여 비동기 웹 서비스 (서버 측)를 작성해 본 적이 있습니까? 그것은 많은 배관 작업입니다). 따라서 모든 시스템이 동기 메서드를 사용하여 암시 적으로 호출되고 하나의 구성 요소가 무언가를 잠그기 때문에 구성 요소 중 하나에 매달리고 싶지 않은 시스템을 말합니다. 매우 안정적이며 실패에 대한 let-it-crash + 감독자 솔루션이 실제로 잘 작동합니다. 모든 것이 프로그래밍 방식으로 설정하기 쉽고 단위 테스트가 어렵지 않습니다.
그런 다음 훌륭한 추가 모듈이 있습니다. Camel 모듈은 실제로 Akka에 잘 연결되며 구성 가능한 엔드 포인트로 비동기 서비스를 쉽게 개발할 수 있습니다.
저는 프레임 워크에 매우 만족하며 우리가 구축하는 연결된 시스템의 사실상 표준이되고 있습니다.
면책 조항 : 나는 Akka의 PO입니다
추론하고 올바른 정보 (액터, 에이전트, 데이터 흐름 동시성) 및 STM 형태의 동시성 제어 기능을 제공하는 동시성 smorgasbord를 제공하는 것 외에도.
고려할 수있는 몇 가지 사용 사례는 다음과 같습니다.
- 거래 처리 (온라인 게임, 금융, 통계, 베팅, 소셜 미디어, 통신 등)
- 확장, 확장, 내결함성 / HA
- 서비스 백엔드 (모든 산업, 모든 앱)
- 서비스 REST, SOAP, cometd 등
- 메시지 허브 / 통합 계층 역할
- 확장, 확장, 내결함성 / HA
- 스냅인 동시성 / 병렬성 (모든 앱)
- 옳은
- 작업 및 이해가 간단
- 기존 JVM 프로젝트에 jar를 추가하기 만하면됩니다 (Scala, Java, Groovy 또는 JRuby 사용).
- 일괄 처리 (모든 산업)
- 배치 데이터 소스와 연결하기위한 Camel 통합
- 행위자는 배치 워크로드를 분할하고 정복합니다.
- 통신 허브 (통신, 웹 미디어, 모바일 미디어)
- 확장, 확장, 내결함성 / HA
- 게임 서버 (온라인 게임, 베팅)
- 확장, 확장, 내결함성 / HA
- BI / 데이터 마이닝 / 범용 크 런칭
- 확장, 확장, 내결함성 / HA
- 여기에 다른 좋은 사용 사례 삽입
이를 사용하는 방법의 예는 직불 / 신용 카드 거래의 우선 순위 대기열에 있습니다. 우리는 수백만 가지를 가지고 있으며 작업 노력은 입력 문자열 유형에 따라 다릅니다. 트랜잭션이 CHECK 유형 인 경우 처리가 거의 없지만 POS 인 경우 메타 데이터 (카테고리, 레이블, 태그 등)와 병합하고 서비스 (이메일 / SMS 알림, 사기 탐지, 자금 부족 등). 입력 유형에 따라 작업을 처리하고 작업을 수행하는 데 필요한 다양한 특성 (믹신이라고 함)의 클래스를 구성합니다. 이러한 모든 작업은 서로 다른 금융 기관에서 실시간 모드로 동일한 대기열에 들어갑니다. 데이터가 정리되면 지속성, 분석을 위해 다른 데이터 저장소로 전송되거나 소켓 연결로 푸시되거나 Lift comet actor로 전송됩니다. 작업하는 행위자는 가능한 한 빨리 데이터를 처리 할 수 있도록 작업을 지속적으로 자체로드 밸런싱합니다. 또한 추가 서비스, 지속성 모델 및중요한 결정 지점에 대한 stm .
JVM에서 전달되는 Erlang OTP 스타일 메시지는 기존 라이브러리 및 애플리케이션 서버의 어깨에서 실시간 시스템을 개발하기위한 훌륭한 시스템을 만듭니다.
Akka를 사용하면 기존의 esb 에서와 같이 메시지를 빠르게 전달할 수 있습니다 ! 또한 솔루션에 필요한 방대한 액터 풀, 원격 노드 및 내결함성을 관리 할 수있는 프레임 워크의 도구를 제공합니다.
Akka를 사용하여 REST 호출을 비동기식으로 처리합니다. 비동기 웹 서버 (Netty 기반)와 함께 사용자 요청 모델 당 기존 스레드에 비해 노드 / 서버 당 서비스되는 사용자 수를 10 배 향상시킬 수 있습니다.
Tell it to your boss that your AWS hosting bill is going to drop by the factor of 10 and it is a no-brainer! Shh... dont tell it to Amazon though... :)
We are using Akka in a large scale Telco project (unfortunately I can't disclose a lot of details). Akka actors are deployed and accessed remotely by a web application. In this way, we have a simplified RPC model based on Google protobuffer and we achieve parallelism using Akka Futures. So far, this model has worked brilliantly. One note: we are using the Java API.
If you abstract the chat server up a level, then you get the answer.
Akka provides a messaging system that is akin to Erlang's "let it crash" mentality.
So examples are things that need varying levels of durability and reliability of messaging:
- Chat server
- Network layer for an MMO
- Financial data pump
- Notification system for an iPhone/mobile/whatever app
- REST Server
- Maybe something akin to WebMachine (guess)
The nice things about Akka are the choices it affords for persistence, it's STM implementation, REST server and fault-tolerance.
Don't get annoyed by the example of a chat server, think of it as an example of a certain class of solution.
With all their excellent documentation, I feel like a gap is this exact question, use-cases and examples. Keeping in mind the examples are non-trivial.
(Written with only experience of watching videos and playing with the source, I have implemented nothing using akka.)
We use Akka in several projects at work, the most interesting of which is related to vehicle crash repair. Primarily in the UK but now expanding to the US, Asia, Australasia and Europe. We use actors to ensure that crash repair information is provided realtime to enable the safe and cost effective repair of vehicles.
The question with Akka is really more 'what can't you do with Akka'. Its ability to integrate with powerful frameworks, its powerful abstraction and all of the fault tolerance aspects make it a very comprehensive toolkit.
You can use Akka for several different kinds of things.
I was working on a website, where I migrated the technology stack to Scala and Akka. We used it for pretty much everything that happened on the website. Even though you might think a Chat example is bad, all are basically the same:
- Live updates on the website (e.g. views, likes, ...)
- Showing live user comments
- Notification services
- Search and all other kinds of services
Especially the live updates are easy since they boil down to what a Chat example ist. The services part is another interesting topic because you can simply choose to use remote actors and even if your app is not clustered, you can deploy it to different machines with ease.
I am also using Akka for a PCB autorouter application with the idea of being able to scale from a laptop to a data center. The more power you give it, the better the result will be. This is extremely hard to implement if you try to use usual concurrency because Akka gives you also location transparency.
Currently as a free time project, I am building a web framework using only actors. Again the benefits are scalability from a single machine to an entire cluster of machines. Besides, using a message driven approach makes your software service oriented from the start. You have all those nice components, talking to each other but not necessarily knowing each other, living on the same machine, not even in the same data center.
And since Google Reader shut down I started with a RSS reader, using Akka of course. It is all about encapsulated services for me. As a conclusion: The actor model itself is what you should adopt first and Akka is a very reliable framework helping you to implement it with a lot of benefits you will receive along the way.
We are using akka with its camel plugin to distribute our analysis and trending processing for twimpact.com. We have to process between 50 and 1000 messages per second. In addition to multi-node processing with camel it is also used to distribute work on a single processor to multiple workers for maximum performance. Works quite well, but requires some understanding of how to handle congestions.
I was trying out my hands on Akka (Java api). What I tried was to compare Akka's actor based concurrency model with that of plain Java concurrency model (java.util.concurrent classes).
The use case was a simple canonical map reduce implementation of character count. The dataset was a collection of randomly generated strings (400 chars in length), and calculate the number of vowels in them.
For Akka I used a BalancedDispatcher(for load balancing amongst threads) and RoundRobinRouter (to keep a limit on my function actors). For Java, I used simple fork join technique (implemented without any work stealing algorithm) that would fork map/reduce executions and join the results. Intermediate results were held in blocking queues to make even the joining as parallel as possible. Probably, if I am not wrong, that would mimic somehow the "mailbox" concept of Akka actors, where they receive messages.
Observation: Till medium loads (~50000 string input) the results were comparable, varying slightly in different iterations. However, as I increased my load to ~100000 it would hang the Java solution. I configured the Java solution with 20-30 threads under this condition and it failed in all iterations.
Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.
So for me, it seems Akka scales out better than traditional Java multithreaded solution. And probably the reason is the under the hood magic of Scala.
If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the JVM.
Test performed on: Java version:1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3GB ram. Intel Core i5 processor, 2.5 GHz clock speed
Please note, the problem domain used for the test can be debated and I tried to be as much fair as my Java knowledge allowed :-)
We use Akka in spoken dialog systems (primetalk). Both internally and externally. In order to simultaneously run a lot of telephony channels on a single cluster node it is obviously necessary to have some multithreading framework. Akka works just perfect. We have previous nightmare with the java-concurrency. And with Akka it is just like a swing — it simply works. Robust and reliable. 24*7, non-stop.
Inside a channel we have real-time stream of events that are processed in parallel. In particular: - lengthy automatic speech recognition — is done with an actor; - audio output producer that mixes a few audio sources (including synthesized speech); - text-to-speech conversion is a separate set of actors shared between channels; - semantic and knowledge processing.
복잡한 신호 처리를 상호 연결하기 위해 SynapseGrid 를 사용 합니다 . 복잡한 행위자 시스템에서 DataFlow의 컴파일 타임 검사의 이점이 있습니다.
최근 에 Akka : Word count에서 표준 맵 축소 예제를 구현 했습니다. 따라서 Akka의 한 가지 사용 사례는 더 나은 성능입니다. 그것은 무엇보다 JRuby와 Akka의 배우들의 실험에 가깝지만, Akka 가 Scala 나 Java만이 아니라는 것을 보여줍니다. JVM 위에있는 모든 언어에서 작동합니다.
참고 URL : https://stackoverflow.com/questions/4493001/good-use-case-for-akka
'Programing' 카테고리의 다른 글
| 확인없이 cp를 강제로 덮어 쓰는 방법 (0) | 2020.10.03 |
|---|---|
| 상위 페이지의 iframe에서 JavaScript 코드 호출 (0) | 2020.10.03 |
| 지원되지 않는 major.minor 버전 52.0 (0) | 2020.10.03 |
| 사용자의 시간대 결정 (0) | 2020.10.03 |
| 프로젝트에서 Git 추적을 제거하려면 어떻게합니까? (0) | 2020.10.03 |