Akka atau Reaktor [ditutup]


94

Saya sedang dalam proses memulai proyek baru (berbasis java). Saya perlu membangunnya sebagai arsitektur modular, terdistribusi, dan tangguh.

Oleh karena itu, saya ingin proses bisnis dapat berkomunikasi di antara mereka sendiri, dapat dioperasikan, tetapi juga independen.

Saat ini saya sedang melihat dua kerangka kerja yang, selain perbedaan usia, mengekspresikan 2 pandangan berbeda:

Apa yang harus saya pertimbangkan saat memilih salah satu kerangka kerja di atas?

Sejauh yang saya pahami sampai sekarang, Akka entah bagaimana masih digabungkan (dengan cara saya harus 'memilih' aktor yang ingin saya kirimi pesan), tetapi sangat tangguh. Sementara Reaktor longgar (berdasarkan postingan acara).

Dapatkah seseorang membantu saya memahami bagaimana membuat keputusan yang tepat?

MEMPERBARUI

Setelah meninjau Bus Acara Akka dengan lebih baik, saya yakin dalam beberapa hal fitur yang diungkapkan oleh Reaktor sudah termasuk dalam Akka.

Misalnya langganan dan penerbitan acara, yang didokumentasikan di https://github.com/reactor/reactor#events-selectors-and-consumers , dapat diekspresikan di Akka sebagai berikut:

final ActorSystem system = ActorSystem.create("system");
final ActorRef actor = system.actorOf(new Props(
    new UntypedActorFactory() {

        @Override
        public Actor create() throws Exception {

            return new UntypedActor() {
                final LoggingAdapter log = Logging.getLogger(
                        getContext().system(), this);

                @Override
                public void onReceive(Object message)
                        throws Exception {
                    if (message instanceof String)
                        log.info("Received String message: {}",
                                message);
                    else
                        unhandled(message);
                }
            };
        }
    }), "actor");

system.eventStream().subscribe(actor, String.class);
system.eventStream().publish("testing 1 2 3");

Oleh karena itu menurut saya sekarang perbedaan utama antara keduanya adalah:

  • Akka, lebih dewasa, terikat pada Typeafe
  • Reaktor, tahap awal, terikat ke Spring

Apakah interpretasi saya benar? Tapi apa perbedaan secara konseptual antara Aktor Akka dan Konsumen di Reaktor ?


8
Akka tidak terikat untuk digunakan oleh Scala, bahkan mayoritas menggunakannya dari Jawa.
Viktor Klang

1
David: Sesuatu seperti: Akka EventBus API bersama dengan Akka Actors menerapkan Pola Reaktor
Viktor Klang

9
Hanya untuk memperjelas: Reaktor sama sekali tidak terikat pada Spring. Kami sengaja mencegah dependensi Spring karena, sebagai kerangka kerja dasar, tidak masuk akal untuk membatasi penggunaannya hanya untuk pengguna Spring. Adapun perbedaan antara Aktor dan Konsumen: sejauh menyangkut Reaktor, Konsumen Anda bisa stateful atau tidak. Diasumsikan bahwa Anda ingin menggunakan kelas anonim tanpa status atau Java 8 lambda tetapi itu bukan persyaratan. Dan seperti yang saya sebutkan dalam jawaban saya, perangkat Reaktor, untuk pengulangan awal, sengaja dibuat ringkas. Kami tidak mencoba membuat "Akka berikutnya".
Jon Brisbin

8
Hanya menjatuhkan penyebutan vertx.io karena saya percaya itu berada di bidang yang didorong acara yang sama dengan beberapa konsep menarik dengan nada yang sama bagi mereka yang sedang meneliti ..
Diopentuned

1
Berpindah beberapa tahun, saya juga dalam situasi yang sama, Aplikasi saya pada dasarnya berbasis pegas dan sekarang saya perlu menangani fitur yang digerakkan oleh peristiwa. Apakah ada pemenang yang jelas b / w Akka dan reaktor pegas? Saya mencari kerangka kerja dengan komunitas pengguna aktif jika saya mencapai skenario yang lebih rumit.
tintin

Jawaban:


47

Sulit untuk mengatakannya pada saat ini karena Reaktor masih berupa sketsa dan saya (pimpinan teknologi Akka) tidak memiliki wawasan kemana arahnya. Akan menarik untuk melihat apakah Reaktor menjadi pesaing Akka, kami sangat menantikannya.

Sejauh yang saya bisa lihat, dari daftar kebutuhan Anda Reaktor kehilangan ketahanan (yaitu apa yang diberikan pengawasan kepada Anda di Akka) dan transparansi lokasi (yaitu mengacu pada entitas aktif dengan cara yang memungkinkan Anda mengabstraksikan pesan lokal atau jarak jauh; itulah yang Anda tersirat oleh "didistribusikan"). Untuk “modular” saya tidak cukup tahu tentang Reaktor, khususnya bagaimana Anda dapat mencari komponen aktif dan mengelolanya.

Jika Anda memulai proyek nyata sekarang dan membutuhkan sesuatu yang memenuhi kalimat pertama Anda, maka menurut saya tidak akan kontroversial untuk merekomendasikan Akka pada saat ini (seperti yang juga dicatat Jon). Jangan ragu untuk mengajukan pertanyaan yang lebih konkret tentang SO atau di milis pengguna akka .


Terima kasih Roland, saya senang melihat orang-orang dari kedua proyek berkontribusi pada jawabannya. Saya sedang mencoba Akka. Seperti yang Anda antisipasi, terlalu dini untuk memberikan jawaban akhir atas pertanyaan tersebut, kecuali Reaktor masih dalam tahap awal, oleh karena itu belum cocok untuk perbandingan. Jadi, mari kita tunggu dan lihat bagaimana hal-hal berkembang :-) Terima kasih, David
David Riccitelli

7
Terima kasih atas jawaban Anda, Roland. Saya hanya ingin menjelaskan bahwa Reaktor bukanlah pesaing Akka. Ada kesamaan karena area perhatian yang tumpang tindih terkait aplikasi asinkron. Tetapi Reaktor dimaksudkan sebagai kerangka kerja dasar di mana sistem lain dapat dibangun. Sistem lain itu mungkin lebih tumpang tindih dengan Akka daripada Reaktor itu sendiri. Tetapi di masa mendatang, Reaktor akan tetap menjadi kerangka kerja yang memungkinkan sistem lain dan tidak akan menjadi kerangka kerja full-stack. Anda harus menunda kepuasan pada baku tembak Reaktor / Akka. ;)
Jon Brisbin

Jangan khawatir, saya pikir Anda akan baik-baik saja, dan saya yakin kita akan melihat penyerbukan silang karena semakin banyak perpustakaan yang memasuki bidang ini.
Roland Kuhn

37

Reaktor tidak terikat pada Spring, ini adalah modul opsional. Kami ingin Reactor menjadi portabel, yayasan seperti yang dijelaskan Jon.

Saya tidak akan percaya diri untuk mendorong produksi karena kami bahkan bukan Milestone (1.0.0.SNAPSHOT), dalam hal itu, saya akan melihat lebih dalam Akka yang merupakan IMO kerangka kerja asinkron yang fantastis. Juga pertimbangkan Vert.x dan Finagle yang mungkin diadaptasi jika Anda mencari platform (yang pertama) atau untuk masa depan yang dapat disusun (yang terakhir). Jika Anda menjaga berbagai pola asinkron, mungkin GPars akan memberi Anda solusi yang lebih lengkap.

Pada akhirnya, kita mungkin memiliki tumpang tindih, sebenarnya kita cenderung ke pendekatan campuran (eventing fleksibel yang dapat disusun, didistribusikan, dan tidak terikat pada strategi pengiriman apa pun) di mana Anda dapat dengan mudah menemukan bit dari RxJava , Vert.x , Akka , dll. Kami bahkan tidak keberatan dengan pilihan bahasa, meskipun kami sangat berkomitmen pada Groovy, orang-orang telah memulai port Clojure dan Kotlin . Tambahkan ke campuran ini fakta bahwa beberapa persyaratan didorong oleh Spring XD dan Grails .

Terima kasih banyak atas minat yang Anda saksikan, semoga Anda memiliki lebih banyak poin perbandingan dalam beberapa bulan :)


Terima kasih Stephane, saya yakin jawaban Anda (dan komentar Jon, stackoverflow.com/questions/16595393/akka-or-reactor/… ) memberikan perspektif yang lebih jelas. Saya akan tetap menahan sebelum menandai pertanyaan dijawab, seperti yang Anda katakan, mari kita lihat apa yang akan muncul dalam waktu dekat. Sekali lagi saya sangat menghargai bahwa orang-orang yang terlibat dalam kedua proyek tersebut meluangkan waktu untuk memberikan wawasan yang berguna.
David Riccitelli

Saya setuju dengan Vert.x. Saya telah menggunakan Vert.x di lingkungan produksi dalam beberapa proyek untuk berkomunikasi antar komponen dan berfungsi dengan lancar.
Menang

33

Ini adalah pertanyaan yang sangat bagus dan jawabannya akan berubah selama beberapa minggu mendatang. Kami tidak dapat membuat janji apa pun tentang seperti apa komunikasi antar-node saat ini hanya karena terlalu dini. Kami masih memiliki beberapa bagian untuk disatukan sebelum kami dapat mendemonstrasikan pengelompokan di Reactor.

Karena itu, hanya karena Reaktor tidak melakukan komunikasi antar-node, OOTB tidak berarti tidak bisa . :) Seseorang hanya membutuhkan lapisan jaringan yang cukup tipis untuk berkoordinasi antara Reaktor menggunakan sesuatu seperti Redis atau AMQP untuk memberikan beberapa kecerdasan berkerumun.

Kami pasti berbicara tentang dan merencanakan skenario terdistribusi di Reaktor. Masih terlalu dini untuk mengatakan dengan tepat bagaimana ini akan berhasil.

Jika Anda membutuhkan sesuatu yang melakukan pengelompokan sekarang, Anda akan lebih aman memilih Akka.


Terima kasih Jon, saya menemukan Reactor sangat menjanjikan. Namun saya perlu memahami jika ada perbedaan konseptual antara Reaktor dan Akka, selain fitur yang hilang dari Reaktor (tentu saja, berada pada tahap awal). Singkatnya, apa perbedaan konseptual antara Aktor di Akka dan Konsumen di Reaktor? Saya juga memperbarui pertanyaan saya dengan contoh Acara di Akka yang menurut saya mirip dengan langganan / pengiriman acara di halaman GitHub Reaktor. Terima kasih.
David Riccitelli

Jon, saya membaca tanggapan Anda di sini: blog.springsource.org/2013/05/13/… - jadi kita mungkin berasumsi bahwa dalam jangka panjang Akka dan Reaktor akan memiliki kerangka kerja yang sama, baik mendukung pola Reaktor dan model Aktor.
David Riccitelli


Saya tidak mengerti bagaimana komentar ini sekarang salah? Di sini tidak ada yang bertentangan dengan penjelasan tentang arah strategis Reaktor.
Jon Brisbin

1
Kena kau. Ya, Anda mengerti dengan benar. Terima kasih telah mengajukan pertanyaan ini! :)
Jon Brisbin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.