Najszybsza niezawodny sposób na Clojure (Java) i Ruby aplikacje do komunikowania

Question

Mamy chmurze gospodarzem (Rackspace Chmura) Ruby i Java aplikacje, które oddziałują w sposób następujący:

1. Ruby aplikacja wysyła żądanie do aplikacji Java. Żądanie składa się ze struktury mapy zawierającej ciągi, liczby całkowite, inne mapy i listy (analogiczne do JSON).
2. Aplikacja Java analizuje dane i wysyła odpowiedź do aplikacji Ruby.

Jesteśmy zainteresowani w ocenie oba formaty wiadomości (JSON, Buffer Protocols, Thrift, itd.), Jak również kanałów transmisji wiadomości/technik (rurkowe, kolejki komunikatów, RPC, REST, SOAP, etc.)

Nasze kryteria:

1. Krótki czas podróży w obie strony.
2. Niskie odchylenie standardowe w czasie krótkiego cyklu. (Rozumiemy, że wstrzymanie zbierania śmieci i wzrost wykorzystania sieci może wpłynąć na tę wartość).
3. Wysoka dostępność.
4. Skalowalność (możemy chcieć mieć wiele instancji aplikacji Ruby i Java wymieniających wiadomości typu punkt-punkt w przyszłości).
5. Łatwość debugowania i profilowania.
6. Dobra dokumentacja i wsparcie społeczności.
7. Punkty premiowe za wsparcie Clojure.
8. Dobra obsługa dynamicznego języka.

Jaką kombinację formatu wiadomości i metody transmisji poleciłbyś? Czemu?

Mam tu pewne materiały zebrane już zebrane na test:

• Comparison of various java serialization options
• Comparison of Thrift and Protocol Buffers (old)
• Comparison of various data interchange formats
• Comparison of Thrift and Protocol Buffers
• Fallacies of Protocol Buffers RPC features
• Discussion of RPC in the context of AMQP (Message-Queueing)
• Comparison of RPC and message-passing in distributed systems (pdf)
• Criticism of RPC from perspective of message-passing fan
• Overview of Avro from Ruby programmer perspective
• Overview of Thrift from Ruby programmer perspective
• Overview of Thrift from Java programmer perspective
• Introduction to MessagePack
• Introduction to BERT by dynamic language enthusiast
• Message Queue Evaluation Notes
• ZeroMQ and Clojure

Answer 1

Zdecydowaliśmy się przejść z BSON przez RabbitMQ.

Lubimy wsparcie BSON dla heterogenicznych kolekcji i brak potrzeby określania formatu komunikatów z góry.Nie przeszkadza nam to, że ma słabą charakterystykę użytkowania przestrzeni i prawdopodobnie gorszą wydajność serializacji niż inne formaty wiadomości, ponieważ część komunikacyjna naszej aplikacji nie jest wąskim gardłem. Wygląda na to, że ładny interfejs Clojure nie został napisany, aby pozwolić ci bezpośrednio manipulować obiektami BSON, ale mam nadzieję, że to nie będzie problem. Zrewiduję ten wpis, jeśli zdecydujemy, że BSON nie zadziała dla nas.

Wybraliśmy RabbitMQ głównie dlatego, że mamy już z tym doświadczenie i używamy go w systemie, który wymaga dużej przepustowości i dostępności.

Jeśli komunikat stanie się wąskim gardłem, najpierw zajrzymy do BERT (odrzuciliśmy go, ponieważ obecnie nie obsługuje Java), następnie do MessagePack (odrzucono, ponieważ wydaje się, że nie ma dużej społeczności Programiści Java używający go), następnie do Avro (odrzucony, ponieważ wymaga to zdefiniowania formatu wiadomości z góry), następnie bufory protokołów (odrzucone z powodu dodatkowego etapu generowania kodu i braku heterogenicznych zbiorów), a następnie oszczędzanie (odrzucone dla wymienione powody dla buforów protokołu).

Możemy chcieć pójść prostym schematem RPC zamiast używać kolejki komunikatów, ponieważ nasz styl przesyłania wiadomości jest zasadniczo synchroniczny punkt-punkt.

Dzięki za wkład każdy!

Aktualizacja: Oto project.clj i core.clj, który pokazuje w jaki sposób przekonwertować mapy Clojure do BSON i tył:

;;;; project.clj 

(defproject bson-demo "0.0.1" 
    :description "BSON Demo" 
    :dependencies [[org.clojure/clojure "1.2.0"] 
       [org.clojure/clojure-contrib "1.2.0"] 
       [org.mongodb/mongo-java-driver "2.1"]] 
    :dev-dependencies [[swank-clojure "1.3.0-SNAPSHOT"]] 
    :main core) 

;;;; core.clj 
(ns core 
    (:gen-class) 
    (:import [org.bson BasicBSONObject BSONEncoder BSONDecoder])) 

(defonce *encoder* (BSONEncoder.)) 

(defonce *decoder* (BSONDecoder.)) 

;; XXX Does not accept keyword arguments. Convert clojure.lang.Keyword in map to java.lang.String first. 
(defn map-to-bson [m] 
    (->> m (BasicBSONObject.) (.encode *encoder*))) 

(defn bson-to-map [^BasicBSONObject b] 
    (->> (.readObject *decoder* b) (.toMap) (into {}))) 

(defn -main [] 
    (let [m {"foo" "bar"}] 
    (prn (bson-to-map (map-to-bson m)))))

Answer 2

Wierzę, że bufory protokołów byłyby dużo szybsze i bardziej wydajne niż JSON (ostatnio sprawdzałem, że było około 40 razy szybciej, nie próbowałem tego z rubinem, aby twój przebieg był różny).

Answer 3

Nie mogę mówić z osobistych doświadczeń, ale wiem, że Flightcaster korzysta z przesyłania komunikatów JSON, aby połączyć swój mechanizm analityki kliknięć w back-end z aplikacją Railsową front-end i wydaje się, że działa dla nich. Oto artykuł (pojawia się pod koniec):

Clojure and Rails - the Secret Sauce Behind FlightCaster

Nadzieja to pomaga. - Mike

Answer 4

Nie mam żadnego doświadczenia w tym zakresie. W każdym razie opublikuję to prawdopodobnie pomocne podpowiedź.

• ZeroMQ oferuje wiadomości point-to-point, włącznie z różnymi typami topologii sieci. Wiadomości składają się z arbitralnych wartości binarnych - więc potrzebujesz tylko formatu serializacji binarnej dla wiadomości strukturalnych.

• BSON, ProtoBuffers i BERT oferta serializacji dowolnych struktur danych (numerów sekwencyjnych, smyczki, tablice, tablice asocjacyjne) do wartości binarnych.

GitHub wynalazł BERT dla szybkiego RCP; BSON został wynaleziony przez MongoDB (lub 10gen) z tego samego powodu; i ProtoBuffers również przez Google.