Отдельные стороны записи / чтения Lagom на отдельные сервисы? - PullRequest
Новая
       6

Отдельные стороны записи / чтения Lagom на отдельные сервисы?

0 голосов
/ 29 мая 2018

Я ознакомился с несколькими демонстрационными примерами, включая демонстрационное приложение Chirper: https://github.com/lagom/lagom-java-sbt-chirper-example

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

public interface ChirpService extends Service {

  ServiceCall<Chirp, NotUsed> addChirp(String userId);

  ServiceCall<LiveChirpsRequest, Source<Chirp, ?>> getLiveChirps();

  ServiceCall<HistoricalChirpsRequest, Source<Chirp, ?>> getHistoricalChirps();

  @Override
  default Descriptor descriptor() {
    // @formatter:off
    return named("chirpservice").withCalls(
        pathCall("/api/chirps/live/:userId", this::addChirp),
        namedCall("/api/chirps/live", this::getLiveChirps),
        namedCall("/api/chirps/history", this::getHistoricalChirps)
      ).withAutoAcl(true);
    // @formatter:on
  }
}

Мой вопрос вращается вокруг идеи, что вы могли бы отправить сообщение addChirp в тему брокера сообщений (процесс Кафки) с целью отделения операций чтения от записей.,Таким образом, запись вернет успех, даже когда сторона чтения (потребитель) временно недоступна (т. Е. ЧФП временно сохраняется Kafka на диск, чтобы обрабатываться стороной чтения, как только она снова становится доступной).

Разве не было бы логично разделить сторону записи и сторону чтения на отдельные службы и запустить их на разных портах в целом?Или у этого подхода есть общие подводные камни?

1 Ответ

0 голосов
/ 29 мая 2018

При записи read-side в Lagom у вас есть два варианта:

  • Внутри-сервисная сторона чтения: использует Akka Persistence Query для чтения непосредственно из журнала стороны записи и сборкисторона чтения.Операция для получения новых событий, отслеживания смещения (чтобы узнать, какие события уже были прочитаны) и создания таблиц на стороне чтения выполняется в процессе, и, что наиболее важно, отслеживание смещения и обновление пользовательской таблицы происходят в транзакциипредлагая effectively-once семантику.Другим преимуществом внутрисервисных сторон чтения является то, что моделирование остается за дверью, и вы можете свободно проводить рефакторинг своих таблиц, если публичные конечные точки REST предлагают тот же API.
  • Межсервисная сторона чтения: (akaудаленные стороны чтения) альтернатива подразумевает создание удаленной службы и публикацию событий из исходной службы в брокер, чтобы удаленная служба могла их использовать.Здесь есть несколько предостережений: (1) события теперь общедоступны, и поэтому публичный API не так легко реорганизовать, (2) публикация не транзакционна и может потреблять либо at-least-once (что вы обычно хотите), либо at-most-onceтаким образом, сквозные гарантии больше не effectively-once, (3) тема доступна для других сервисов (это неплохо, это просто дополнительное соображение), (4) прямой доступ со стороны записи и со стороны чтенияв разных сервисах, что немного неестественно.

В демонстрационном приложении online-auction-java есть демонстрационная версия удаленной стороны чтения: search-service - удаленная сторона чтениякоторый потребляет события из многих тем, консолидирующей информацию в единый индекс elasticsearch.В этом случае имеет смысл использовать удаленную сторону чтения, потому что: (а) мы используем конкретную технологию хранения данных (упругий поиск) и (б) мы объединяем потоки, поступающие из двух разных восходящих сервисов.

HTH,

...