Пример интеграции Akka с существующим проектом java

Если у меня уже есть существующее веб-приложение java, которое использует контейнер spring и servlet. Каков правильный способ интеграции Akka?

Как и у меня есть Actor1 и Actor2, которые общаются друг с другом. Каким будет точка входа, чтобы начать использовать этих участников? (например: 1. поместите его туда 2. измените конфигурацию 3. получите ссылку на актера)

Я нашел http://doc.akka.io/docs/akka/2.2-M3/general/configuration.html Но он не дает мне клей. Просто хочу получить реальный пример интеграции.

Есть ли простой пример интеграции?

EDIT: Приложение выполняет поиск, получает некоторые данные извне, сохраняет информацию в файлах.

Приложение довольно большое. Некоторые компоненты/объект могут оставить свою собственную жизнь, то есть из-за прямых клиентских запросов, он может делать некоторые вещи параллельно. Как некоторые одноэлементные объекты, которые в нем имеют изменяемое состояние.

Дело в том, что я точно не знаю, где я могу применить актеров, я расследую это. Но у меня уже много синхронизированных блоков здесь и там.

И это уже, я считаю, своего рода знак того, что актеры могут быть применены. (потому что я не уверен, возможно, я забыл поместить некоторые синхронизированные, и, конечно, для него нет интеграционных тестов)

О конфигурации, я просто не уверен, должен ли я настроить какой-то application.conf для let Actrors/Akka там (, так как сама документация описывает).

Что я вижу:

@Component("someManager")
public class SomeManager {
 List<Some> something;  // mutable state, that why I use locks here.
 // methods: add(), delete(), update()  
}

Я мог бы сделать это SomeManagerActor

SomeManager используется из controller. Таким образом, было бы неплохо иметь контроллер Актер также? Я хочу получить обратную связь в (onReceive() метод).

Это своего рода спорный... Это еще одна причина, по которой мне нужен пример.

Я считаю, что могу улучшить приложение, избавляясь от всего материала synchronized/whait/notify, перенося обязанности на участников, используя сообщения как способ общения с ними/между ними.

Или, например, это, он может быть актером для записи в файлы свойств:

EDIT:

Например, на данный момент я нашел: Чтобы отправить Actor1 сообщение в Actor2, я использую трюк:

// somewhere in existing code
public void initActors() {

        ActorSystem system = ActorSystem.create(example");

        // initializing
        final ActorRef actor1 = system.actorOf(Props.create(Actor1.class), "actor1");

}

У Actor1 есть метод preStart(), который запускается, как только я получаю ссылку на него (см. выше). И он отправляет сообщение в Actor2:

@Override
public void preStart() {

Но я не уверен, что это хорошо, почему нужно инициализировать двух актеров, чтобы сделать их работа.

Ответы

Ответ 1

Отвечая на мой вопрос. Просто чтобы поделиться своими мыслями, что я придумала.

Если у нас уже есть работающее веб-приложение, основанное на Servlets/Spring MVC, кажется, что часто нет веской причины переключаться на Actors/AKKA (или вводить актеров в существующую систему просто для взлома), если в нашем приложение мы:

  • Не имейте: логикурабочих потоков, когда задачи разделяются на фоне. (как правило, типичное веб-приложение не имеет этого), как длинные и длинные вычисления. (параллелизм).
  • Иметь: Если у нас есть последовательные вызовы - когда один компонент вызывает другой, то это вызывает другой, где вызовы зависят друг от друга: Контроллеры вызывают Компонент, Компонент сохраняет некоторые данные в некоторый Список (который является изменяемым, но синхронизируется как Synchronized-list).
  • Не располагайте свободным временем для замены всех Spring Controllers актерами Akka или использования разных серверов вообще (не Tomcat) (не так много менеджеров/владельцев продуктов, которые позволили бы вам это сделать)

Что плохого в том, что актеры в этой простой системе:

  • Наличие тонн сообщений (классы, которые переносят команды в/из актеров), которые проходят через компоненты вместо вызова общих методов (используя преимущества OPP, реализуя интерфейсы, имея несколько реализаций - но Актеры обычно final class).

  • Иметь сообщения в виде string, тоже не очень хорошее решение - так как их сложно отлаживать.

  • В такой системе (например, на сайте MVC) обычно не так много вещей для синхронизации (это уже довольно stateless). В каждом контроллере/компоненте есть 0..2 mutable shared data. Что не так сложно синхронизировать (просто приучите синхронизировать все общее и общее в верхней части ваших классов (чтобы состояния были распознаваемыми/локализованными). Иногда вам просто нужно synchronized collection или использовать оболочку java Atomic типа.

Когда актеры могут быть использованы для существующего приложения. Варианты использования могут быть такими:

  • когда у нас есть долгоживущий поиск, он проходит через несколько источников (вид рабочего потока). Наличие нескольких /pull MasterActor → SiteSearchActor (как это было описано для вычислений PI здесь). MasterActor имеет окончательный результат. Где SiteSearchActor вычисляет (выполняет поиск по нескольким сайтам) несколько клиентов.
  • или когда у нас есть какие-либо ветки потоков, из текущих сервлетов
  • когда мы точно знаем/выяснили, что наша система будет использоваться миллионами клиентов (даже с простой логикой), мы должны заранее подумать о scalability и performance (
    • Актеры хорошо масштабируются - мы можем делегировать одну работу от одного актера к N-тем.
    • актеры сохраняют тип процессора при работе с потоками (не нужно 10000 потоков для 10000 клиентов, в большинстве случаев достаточно иметь 4 потока (столько же, сколько позволяет процессорное ядро) говори))

Но в целом я согласен с этой статьей о concurrency и parallelism. Если бы у меня была возможность создать приложение с нуля, я бы использовал Akka без контейнера сервлетов и как-то заботился о сообщениях (классы команд) и ООП, когда это необходимо для использования (в общих веб-приложениях OOP не так много. В любом случае, я бы сказал, но никто не мешает придерживаться бизнес-логики OOP, актеры - просто клей связи). Это намного лучше/проще, чем, например, использовать JMS.

Но, как я уже сказал:

Актеры/Акка хороша для:

  1. Сервисы/Контроллеры (вместо Servlet/SpringMVC)
  2. Работники потоков любят логику
  3. Особенно для проекта с нуля (когда существующая инфраструктура не делает вас барьерами для применения актера).

Единственный вопрос, который у меня сейчас есть, это performance comparison. Предполагая, что мы знаем, что:

наличие 10000 потоков в одной JVM с синхронизацией и блокировками для общего доступа изменяемые данные в наших контроллерах/сервисах MVC могут быть очень плохими с точки зрения производительности. Так как есть много возможных замков, потоки, которые являются параллельными (конкурент или конкурент для hared ресурс) друг другу.

Если бы у нас был такой же сценарий для AKKA/Servlets с N (актеры, где N гораздо больше меньше, чем 1000), мы, скорее всего, имели бы гораздо лучшую производительность (поскольку никто не блокировал никого, кроме самой очереди, нет нужно переключаться с одного потока на другой).

Но даже при наличии системы с 10000 клиентами для приложения на основе сервлетов (потоковая модель) с 100 клиентами это может работать очень хорошо. И если у нас есть пул соединений (конечно, у нас есть), он выполняет ту же работу, что и очередь Actor (входящие), планируя доступ клиентов к какой-либо части службы. Это может улучшить нашу производительность в K раз (где K намного больше, чем если бы у нас не было пула - позволяя потоку отчаянно блокировать друг друга).

Вопрос в следующем:

Это хорошая причина, чтобы не применять AKKA для существующих приложений на основе сервлетов?

Принимая это аргумент: даже имея старую систему на серверах, с connection pool может улучшить производительность до хорошего уровня. И это уровень, скорее всего, может быть достаточно хорошим, чтобы НЕ применять АККА к существующее приложение сервлета, например, попытка изменить модель сервлета (это должно быть плохо по сравнению с контроллерами на вершине АККА).

Есть ли смысл думать так?

Считайте, что соединение является своего рода INBOX (как в AKKA), планируя команды (соединение).

Даже если модель сервлетов плохая (имеет дело с блокировками в остальном (активном) потоке, который создается соединением, исходящим из пула соединений).

Это может быть достаточно для пула соединений, который забывают при сравнении Akka с сервлетами. Мы все еще можем настроить наше приложение, изменив MAX-CONNECTION в пуле соединений. Обычно мы делаем все возможное, чтобы приложение не сохраняло состояние, поэтому в большинстве случаев мы ничего не синхронизируем.

Но, конечно, плохо иметь только один пул соединений для целого приложения. При сравнении с субъектами каждый субъект имеет каждый собственный пул соединений (почтовый ящик), и каждый субъект может отвечать за прием HTTP-запросов. Эта модель, безусловно, лучше.

Постскриптум  В большинстве случаев Future достаточно хороши. Актеры хороши, если вы хотите, чтобы "безопасность" сохраняла в нем состояние (в основном это отличает его от будущего).

UPDATE: Некоторые люди считают, что вообще нельзя использовать актеров. Что хорошо, так это чисто функциональный подход или что-то, что scalaz уже предлагает (а также, как я полагаю, Haskell), но пока не для удаленных вызовов.

Ответ 2

Я столкнулся с аналогичной проблемой.

Я согласен с тем, что мало пользы от добавления AKKA в простой веб-аппликатор с небольшим количеством пользователей.

Но я не думаю, что сложно добавить AKKA в существующее приложение spring mvc. Если ваш проект нужно масштабировать, вы можете обернуть свой слой @Service в роли актеров. Следовательно, @Controllers не нужно находиться внутри участников.

Вот презентация о слиянии spring с akka: https://www.youtube.com/watch?v=fALUf9BmqYE

Исходный код для презентации: https://github.com/jsuereth/spring-akka-sample/tree/master/src/main/java/org/springframework/samples/travel