Akka hoặc Lò phản ứng [đã đóng cửa]


94

Tôi đang trong quá trình bắt đầu một dự án mới (dựa trên java). Tôi cần xây dựng nó như một kiến ​​trúc mô-đun, phân tán và có khả năng phục hồi.

Do đó, tôi muốn có các quy trình kinh doanh để giao tiếp giữa chúng, có thể tương tác nhưng cũng độc lập.

Tôi hiện đang xem xét hai khuôn khổ, ngoài sự khác biệt về tuổi tác, còn thể hiện 2 quan điểm khác nhau:

Tôi nên cân nhắc điều gì khi chọn một trong các khuôn khổ trên?

Theo như tôi hiểu cho đến bây giờ, Akka vẫn bị ghép đôi (theo cách mà tôi phải 'chọn' diễn viên tôi muốn gửi tin nhắn), nhưng rất kiên cường. Trong khi Reactor lỏng lẻo (dựa trên sự kiện đăng tải).

Ai đó có thể giúp tôi hiểu làm thế nào để đưa ra một quyết định đúng đắn?

CẬP NHẬT

Sau khi xem xét tốt hơn Xe buýt sự kiện của Akka, tôi tin rằng theo một cách nào đó, các tính năng do Reactor thể hiện đã được đưa vào Akka.

Ví dụ: đăng ký và xuất bản sự kiện, được ghi lại trên https://github.com/reactor/reactor#events-selectors-and-consumers , có thể được diễn đạt bằng Akka như sau:

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");

Do đó, bây giờ đối với tôi, có vẻ như sự khác biệt chính giữa hai là:

  • Akka, trưởng thành hơn, ràng buộc với Typeafe
  • Lò phản ứng, giai đoạn đầu, liên kết với mùa xuân

Giải thích của tôi có đúng không? Nhưng về mặt khái niệm thì sự khác biệt giữa Diễn viên trong Akka và Người tiêu dùng trong Lò phản ứng là gì?


8
Akka không bị ràng buộc phải được sử dụng bởi Scala, trên thực tế, phần lớn sử dụng nó từ Java.
Viktor Klang

1
David: Một cái gì đó như: Akka EventBus API phối hợp với Akka Actors thực hiện Mô hình lò phản ứng
Viktor Klang

9
Chỉ cần làm rõ: Reactor không bị ràng buộc với Spring. Chúng tôi cố ý loại bỏ bất kỳ phụ thuộc Spring nào bởi vì, với tư cách là một khung nền tảng, không có ý nghĩa gì nếu chỉ giới hạn việc sử dụng nó cho người dùng Spring. Đối với sự khác biệt giữa Tác nhân và Người tiêu dùng: đối với Lò phản ứng, Người tiêu dùng của bạn có thể ở trạng thái rõ ràng hoặc không. Giả định rằng bạn sẽ muốn sử dụng một lớp ẩn danh không trạng thái hoặc lambda Java 8 nhưng đó không phải là một yêu cầu. Và giống như tôi đã đề cập trong câu trả lời của mình, bộ công cụ Reactor, đối với các lần lặp lại sớm, ngắn gọn có chủ ý. Chúng tôi không cố gắng tạo "Akka tiếp theo".
Jon Brisbin

8
Chỉ cần thả một đề cập đến vertx.io như tôi tin rằng nó là trong cùng một sự kiện lĩnh vực điều khiển với một số khái niệm thú vị trong tĩnh mạch tương tự đối với những người đang nghiên cứu ..
Opentuned

1
Sau một vài năm, tôi cũng ở trong tình huống tương tự, Ứng dụng của tôi chủ yếu dựa trên lò xo và bây giờ tôi cần xử lý một tính năng hướng sự kiện. Có người chiến thắng rõ ràng b / w Akka và lò phản ứng Spring không? Tôi đang tìm kiếm một khuôn khổ với các giao tiếp người dùng đang hoạt động trong trường hợp tôi gặp các tình huống phức tạp hơn.
tintin

Câu trả lời:


47

Thật khó để nói vào thời điểm này vì Reactor vẫn còn là một bản phác thảo và tôi (trưởng nhóm công nghệ của Akka) không có cái nhìn sâu sắc về nơi nó sẽ đi. Sẽ rất thú vị nếu Reactor trở thành đối thủ cạnh tranh với Akka, chúng tôi rất mong chờ điều đó.

Theo như tôi có thể thấy, từ danh sách yêu cầu của bạn, Lò phản ứng thiếu khả năng phục hồi (tức là tính năng giám sát mang lại cho bạn trong Akka) và tính minh bạch của vị trí (tức là đề cập đến các thực thể đang hoạt động theo cách cho phép bạn tóm tắt thông tin cục bộ hoặc từ xa; đó là những gì bạn ngụ ý bởi "phân phối"). Đối với "mô-đun", tôi không biết đủ về Reactor, cụ thể là cách bạn có thể tra cứu các thành phần đang hoạt động và quản lý chúng.

Nếu bạn bắt đầu một dự án thực sự ngay bây giờ và cần thứ gì đó thỏa mãn câu đầu tiên của bạn, thì tôi không nghĩ sẽ gây tranh cãi khi giới thiệu Akka vào thời điểm này (như Jon cũng đã lưu ý). Vui lòng đặt các câu hỏi cụ thể hơn trên SO hoặc trên danh sách gửi thư của người dùng akka .


Cảm ơn Roland, tôi rất vui khi thấy mọi người từ cả hai dự án đang đóng góp vào câu trả lời. Tôi hiện đang dùng thử Akka. Như bạn dự đoán, còn khá sớm để đưa ra câu trả lời cuối cùng cho câu hỏi, ngoại trừ Reactor vẫn đang ở giai đoạn đầu, do đó chưa phù hợp để so sánh. Vì vậy, chúng ta hãy chờ đợi và xem làm thế nào điều phát triển :-) Cảm ơn, David
David Riccitelli

7
Cảm ơn câu trả lời của bạn, Roland. Tôi chỉ muốn làm rõ rằng Reactor không phải là đối thủ cạnh tranh của Akka. Có những điểm tương đồng do một khu vực chồng chéo đáng quan tâm liên quan đến các ứng dụng không đồng bộ. Nhưng Reactor được hiểu là một khung nền tảng để các hệ thống khác có thể được xây dựng. Những hệ thống khác có thể trùng lặp với Akka nhiều hơn so với bản thân Reactor. Nhưng trong tương lai gần, Reactor sẽ vẫn là một khuôn khổ cho phép các hệ thống khác và bản thân nó sẽ không phải là một khuôn khổ đầy đủ. Bạn sẽ phải trì hoãn sự hài lòng trong loạt đấu súng Reactor / Akka. ;)
Jon Brisbin

Đừng lo lắng, tôi nghĩ bạn sẽ làm tốt, và tôi khá chắc chắn rằng chúng ta sẽ thấy sự thụ phấn chéo khi nhiều thư viện tham gia lĩnh vực này.
Roland Kuhn

37

Reactor không bị ràng buộc với Spring, nó là một mô-đun tùy chọn. Chúng tôi muốn Reactor có thể di động được, một nền tảng như Jon đã vạch ra.

Tôi sẽ không tự tin về việc thúc đẩy sản xuất vì chúng tôi thậm chí không phải là Milestone (1.0.0.SNAPSHOT), về mặt đó, tôi sẽ có một cái nhìn sâu hơn về Akka , một IMO khuôn khổ không đồng bộ tuyệt vời. Cũng nên xem xét Vert.xFinagle có thể được điều chỉnh nếu bạn tìm kiếm một nền tảng (trước đây) hoặc cho tương lai có thể kết hợp (sau này). Nếu bạn quan tâm đến một loạt các mẫu không đồng bộ, có thể GPars sẽ cung cấp cho bạn một giải pháp hoàn chỉnh hơn.

Cuối cùng, chúng tôi chắc chắn có thể có sự trùng lặp, trên thực tế, chúng tôi đang nghiêng về cách tiếp cận hỗn hợp (sự kiện có thể kết hợp linh hoạt, phân tán và không bị ràng buộc bởi bất kỳ chiến lược điều phối nào) nơi bạn có thể dễ dàng tìm thấy các bit từ RxJava , Vert.x , Akka , v.v. Chúng tôi thậm chí không kiên quyết với lựa chọn ngôn ngữ, ngay cả khi chúng tôi rất cam kết với Groovy, mọi người đã bắt đầu sử dụng các cổng ClojureKotlin . Thêm vào sự kết hợp này thực tế là một số yêu cầu được thúc đẩy bởi Spring XDGrails .

Rất cám ơn sự quan tâm của bạn, hy vọng bạn sẽ có nhiều điểm so sánh hơn trong vài tháng tới :)


Cảm ơn Stephane, tôi tin rằng câu trả lời của bạn (và nhận xét của Jon, stackoverflow.com/questions/16595393/akka-or-reactor/… ) cho một góc nhìn rõ ràng hơn nhiều. Tôi sẽ vẫn giữ trước khi đánh dấu câu hỏi đã trả lời, như bạn đã nói, hãy xem điều gì sẽ xuất hiện trong tương lai gần. Một lần nữa, tôi thực sự đánh giá cao rằng những người tham gia vào cả hai dự án đã dành thời gian cung cấp thông tin chi tiết hữu ích.
David Riccitelli

Tôi đồng ý với Vert.x. Tôi đã sử dụng Vert.x trong môi trường sản xuất trong một vài dự án để giao tiếp giữa các thành phần và nó hoạt động liền mạch.
Thắng

33

Đây là một câu hỏi tuyệt vời và câu trả lời sẽ thay đổi trong những tuần tới. Chúng tôi không thể đưa ra bất kỳ lời hứa nào về giao tiếp giữa các nút sẽ như thế nào ngay bây giờ chỉ vì còn quá sớm. Chúng tôi vẫn còn một số phần để ghép lại với nhau trước khi có thể chứng minh việc phân cụm trong Lò phản ứng.

Như đã nói, chỉ vì Reactor không thực hiện kết nối giữa các nút OOTB không có nghĩa là nó không thể . :) Người ta sẽ chỉ cần một lớp mạng khá mỏng để phối hợp giữa các Reactor bằng cách sử dụng thứ gì đó như Redis hoặc AMQP để cung cấp cho nó một số thông minh được phân cụm.

Chúng tôi chắc chắn đang nói về và lập kế hoạch cho các kịch bản phân tán trong Reactor. Vẫn còn quá sớm để nói chính xác nó sẽ hoạt động như thế nào.

Nếu bạn cần thứ gì đó có thể phân cụm ngay bây giờ, bạn sẽ an toàn hơn khi chọn Akka.


Cảm ơn Jon, tôi thấy Reactor rất hứa hẹn. Tuy nhiên, tôi cần hiểu nếu có sự khác biệt về khái niệm giữa Reactor và Akka, bên cạnh các tính năng mà Reactor bị thiếu (tất nhiên, đang ở giai đoạn đầu). Tóm lại, sự khác biệt về khái niệm giữa Tác nhân trong Akka và Người tiêu dùng trong Lò phản ứng là gì? Tôi cũng đã cập nhật câu hỏi của mình với một Sự kiện mẫu ở Akka mà tôi tin rằng giống như đăng ký / gửi sự kiện trên trang Reactor GitHub. Cảm ơn.
David Riccitelli

Jon, tôi đã đọc câu trả lời của bạn ở đây: blog.springsource.org/2013/05/13/… - vì vậy chúng ta có thể cho rằng về lâu dài Akka và Reactor sẽ là một khung tương tự, cả hai đều hỗ trợ mô hình Reactor và mô hình Actor.
David Riccitelli

Nhận xét ở trên không còn đúng nữa do những điều sau: stackoverflow.com/questions/16595393/akka-or-reactor/…stackoverflow.com/a/16674388/565110
David Riccitelli

Tôi không hiểu bây giờ nhận xét này không chính xác như thế nào? Không có gì ở đây mâu thuẫn với lời giải thích về hướng chiến lược của Reactor.
Jon Brisbin

1
Gotcha. Vâng, bạn hiểu đúng. Cảm ơn vì đã đặt những câu hỏi này! :)
Jon Brisbin
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.