Trường hợp sử dụng tốt cho Akka [đóng]

Tôi đã nghe nhiều lời ca ngợi về khung Akka (nền tảng dịch vụ Java / Scala), nhưng cho đến nay vẫn chưa thấy nhiều ví dụ thực tế về các trường hợp sử dụng sẽ tốt cho nó. Vì vậy, tôi sẽ quan tâm đến việc nghe về những thứ mà các nhà phát triển đã sử dụng nó thành công.

Chỉ có một giới hạn: vui lòng không bao gồm trường hợp viết máy chủ trò chuyện. (tại sao? vì điều này đã được sử dụng quá mức làm ví dụ cho rất nhiều điều tương tự)

Tôi đã sử dụng nó cho đến nay trong hai dự án thực sự rất thành công. cả hai đều ở trong trường thông tin giao thông gần thời gian thực (giao thông như trong xe hơi trên đường cao tốc), được phân phối trên một số nút, tích hợp tin nhắn giữa một số bên, hệ thống phụ trợ đáng tin cậy. Tôi không được tự do cung cấp thông tin cụ thể về khách hàng, khi tôi nhận được OK, có lẽ nó có thể được thêm vào như một tài liệu tham khảo.

Akka đã thực sự bắt tay vào các dự án đó, mặc dù chúng tôi đã bắt đầu khi nó ở phiên bản 0.7. (chúng tôi đang sử dụng scala bằng cách này)

Một trong những lợi thế lớn là bạn có thể dễ dàng soạn thảo một hệ thống từ các diễn viên và tin nhắn mà hầu như không có sự kết hợp, nó có quy mô cực kỳ tốt mà không có sự phức tạp của việc xâu chuỗi bằng tay và bạn có được thông điệp không đồng bộ giữa các đối tượng gần như miễn phí.

Nó là rất tốt trong việc mô hình hóa bất kỳ loại xử lý tin nhắn không đồng bộ. Tôi thích viết bất kỳ loại hệ thống dịch vụ (web) nào theo phong cách này hơn bất kỳ phong cách nào khác. (Bạn đã bao giờ thử viết một dịch vụ web không đồng bộ (phía máy chủ) bằng JAX-WS chưa? Đó là rất nhiều hệ thống ống nước). Vì vậy, tôi muốn nói rằng bất kỳ hệ thống nào không muốn treo trên một trong các thành phần của nó bởi vì mọi thứ đều được gọi ngầm bằng các phương thức đồng bộ và một thành phần đó đang khóa trên một cái gì đó. Nó rất ổn định và giải pháp cho phép sự cố + giám sát cho sự thất bại thực sự hoạt động tốt. Mọi thứ đều dễ dàng để thiết lập chương trình và không khó để kiểm tra đơn vị.

Sau đó là các mô-đun bổ trợ tuyệt vời. Mô-đun Camel thực sự kết hợp tốt với Akka và cho phép phát triển dễ dàng các dịch vụ không đồng bộ như vậy với các điểm cuối có thể định cấu hình.

Tôi rất hài lòng với khung công tác và nó đang trở thành một tiêu chuẩn defacto cho các hệ thống được kết nối mà chúng tôi xây dựng.

Tuyên bố miễn trừ trách nhiệm: Tôi là PO cho Akka

Bên cạnh việc cung cấp một smorgasbord đồng thời đơn giản hơn nhiều để lý do và để có được chính xác (diễn viên, tác nhân, dataflow concurrency) và với điều khiển đồng thời ở dạng STM.

Dưới đây là một số trường hợp sử dụng bạn có thể xem xét:

1. Xử lý giao dịch (chơi game trực tuyến, tài chính, thống kê, cá cược, truyền thông xã hội, viễn thông, ...)
   • mở rộng quy mô, mở rộng quy mô, khả năng chịu lỗi / HA
2. Dịch vụ phụ trợ (mọi ngành, mọi ứng dụng)
   • dịch vụ REST, SOAP, cometd vv
   • hoạt động như lớp trung tâm / lớp tích hợp
   • mở rộng quy mô, mở rộng quy mô, khả năng chịu lỗi / HA
3. Đồng thời đính kèm / song song (bất kỳ ứng dụng nào)
   • Chính xác
   • Đơn giản để làm việc và hiểu
   • Chỉ cần thêm các tệp vào dự án JVM hiện tại của bạn (sử dụng Scala, Java, Groovy hoặc JRuby)
4. Xử lý hàng loạt (bất kỳ ngành nào)
   • Tích hợp lạc đà để kết nối với các nguồn dữ liệu hàng loạt
   • Các diễn viên phân chia và chinh phục khối lượng công việc hàng loạt
5. Trung tâm truyền thông (viễn thông, truyền thông web, phương tiện di động)
   • mở rộng quy mô, mở rộng quy mô, khả năng chịu lỗi / HA
6. Máy chủ trò chơi (chơi game trực tuyến, cá cược)
   • mở rộng quy mô, mở rộng quy mô, khả năng chịu lỗi / HA
7. BI / datamining / crunching mục đích chung
   • mở rộng quy mô, mở rộng quy mô, khả năng chịu lỗi / HA
8. chèn các trường hợp sử dụng tốt đẹp khác ở đây

Một ví dụ về cách chúng tôi sử dụng nó sẽ nằm trong hàng ưu tiên của các giao dịch thẻ ghi nợ / thẻ tín dụng. Chúng tôi có hàng triệu trong số này và nỗ lực của công việc phụ thuộc vào loại chuỗi đầu vào. Nếu giao dịch thuộc loại KIỂM TRA, chúng tôi có rất ít xử lý nhưng nếu đó là điểm bán thì có rất nhiều việc phải làm như hợp nhất với dữ liệu meta (danh mục, nhãn, thẻ, v.v.) và cung cấp dịch vụ (thông báo email / sms, phát hiện gian lận, số dư quỹ thấp, v.v.). Dựa trên loại đầu vào, chúng tôi soạn các lớp có nhiều đặc điểm khác nhau (được gọi là mixin) cần thiết để xử lý công việc và sau đó thực hiện công việc. Tất cả các công việc này đi vào cùng một hàng đợi trong chế độ thời gian thực từ các tổ chức tài chính khác nhau. Sau khi dữ liệu được xóa, nó sẽ được gửi đến các kho lưu trữ dữ liệu khác nhau để duy trì, phân tích hoặc đẩy đến kết nối ổ cắm hoặc để nâng diễn viên sao chổi. Các tác nhân làm việc liên tục tự tải cân bằng công việc để chúng tôi có thể xử lý dữ liệu nhanh nhất có thể. Chúng tôi cũng có thể tham gia vào các dịch vụ bổ sung, mô hình kiên trì vàstm cho các điểm quyết định quan trọng.

Thông báo kiểu Erlang OTP truyền trên JVM tạo ra một hệ thống tuyệt vời để phát triển các hệ thống thời gian thực trên vai của các thư viện và máy chủ ứng dụng hiện có.

Akka cho phép bạn gửi tin nhắn như bạn truyền thống esbnhưng với tốc độ! Nó cũng cung cấp cho bạn các công cụ trong khung để quản lý số lượng lớn các nhóm tác nhân, các nút từ xa và khả năng chịu lỗi mà bạn cần cho giải pháp của mình.

Chúng tôi sử dụng Akka để xử lý các cuộc gọi REST không đồng bộ - cùng với máy chủ web async (dựa trên Netty), chúng tôi có thể cải thiện gấp 10 lần số lượng người dùng được phục vụ trên mỗi nút / máy chủ, so với luồng truyền thống trên mỗi mô hình yêu cầu người dùng.

Nói với sếp của bạn rằng hóa đơn lưu trữ AWS của bạn sẽ giảm theo hệ số 10 và nó là không có trí tuệ! Suỵt ... đừng nói với Amazon mặc dù ... :)

Chúng tôi đang sử dụng Akka trong một dự án Telco quy mô lớn (tiếc là tôi không thể tiết lộ nhiều chi tiết). Các diễn viên Akka được triển khai và truy cập từ xa bằng một ứng dụng web. Theo cách này, chúng tôi có một mô hình RPC được đơn giản hóa dựa trên trình tạo mẫu của Google và chúng tôi đạt được sự song song bằng cách sử dụng Akka Futures. Cho đến nay, mô hình này đã làm việc rực rỡ. Một lưu ý: chúng tôi đang sử dụng API Java.

Nếu bạn trừu tượng máy chủ trò chuyện lên một cấp, thì bạn sẽ có câu trả lời.

Akka cung cấp một hệ thống nhắn tin gần giống với tâm lý "hãy để nó sụp đổ" của Erlang.

Vì vậy, ví dụ là những thứ cần mức độ bền và độ tin cậy khác nhau của tin nhắn:

• Máy chủ trò chuyện
• Lớp mạng cho MMO
• Bơm dữ liệu tài chính
• Hệ thống thông báo cho iPhone / thiết bị di động / bất kỳ ứng dụng nào
• Máy chủ REST
• Có lẽ một cái gì đó giống với WebMachine (đoán)

Những điều tốt đẹp về Akka là những lựa chọn mà nó mang lại cho sự bền bỉ, đó là triển khai STM, máy chủ REST và khả năng chịu lỗi.

Đừng khó chịu với ví dụ về máy chủ trò chuyện, hãy nghĩ về nó như một ví dụ về một loại giải pháp nhất định.

Với tất cả tài liệu tuyệt vời của họ, tôi cảm thấy có một khoảng trống là câu hỏi, trường hợp sử dụng và ví dụ chính xác này. Hãy ghi nhớ các ví dụ là không tầm thường.

(Được viết chỉ với kinh nghiệm xem video và chơi với nguồn, tôi đã không thực hiện được gì khi sử dụng akka.)

Chúng tôi sử dụng Akka trong một số dự án tại nơi làm việc, trong đó thú vị nhất là liên quan đến sửa chữa tai nạn xe cộ. Chủ yếu ở Anh nhưng hiện đang mở rộng sang Mỹ, Châu Á, Úc và Châu Âu. Chúng tôi sử dụng các tác nhân để đảm bảo rằng thông tin sửa chữa sự cố được cung cấp theo thời gian thực để cho phép sửa chữa xe an toàn và tiết kiệm chi phí.

Câu hỏi với Akka thực sự nhiều hơn "bạn không thể làm gì với Akka". Khả năng tích hợp với các khung mạnh mẽ, tính trừu tượng mạnh mẽ và tất cả các khía cạnh chịu lỗi khiến nó trở thành một bộ công cụ rất toàn diện.

Bạn có thể sử dụng Akka cho một số loại khác nhau.

Tôi đang làm việc trên một trang web, nơi tôi đã di chuyển kho công nghệ sang Scala và Akka. Chúng tôi đã sử dụng nó cho hầu hết mọi thứ xảy ra trên trang web. Mặc dù bạn có thể nghĩ rằng một ví dụ Trò chuyện là xấu, nhưng về cơ bản tất cả đều giống nhau:

• Cập nhật trực tiếp trên trang web (ví dụ: lượt xem, lượt thích, ...)
• Hiển thị ý kiến ​​người dùng trực tiếp
• Dịch vụ thông báo
• Tìm kiếm và tất cả các loại dịch vụ khác

Đặc biệt là các bản cập nhật trực tiếp rất dễ dàng vì chúng sôi nổi với những gì một ví dụ Trò chuyện ist. Phần dịch vụ là một chủ đề thú vị khác vì bạn chỉ cần chọn sử dụng các tác nhân từ xa và ngay cả khi ứng dụng của bạn không được phân cụm, bạn có thể dễ dàng triển khai nó đến các máy khác nhau.

Tôi cũng đang sử dụng Akka cho một ứng dụng tự động PCB với ý tưởng có thể mở rộng quy mô từ máy tính xách tay sang trung tâm dữ liệu. Bạn càng cung cấp nhiều năng lượng, kết quả sẽ tốt hơn. Điều này cực kỳ khó thực hiện nếu bạn cố gắng sử dụng đồng thời thông thường vì Akka cũng cung cấp cho bạn tính minh bạch về vị trí.

Hiện tại là một dự án thời gian rảnh, tôi đang xây dựng một khung web chỉ sử dụng các diễn viên. Một lần nữa, lợi ích là khả năng mở rộng từ một máy duy nhất đến toàn bộ cụm máy. Bên cạnh đó, sử dụng cách tiếp cận theo hướng thông điệp làm cho dịch vụ phần mềm của bạn được định hướng ngay từ đầu. Bạn có tất cả những thành phần tốt đẹp đó, nói chuyện với nhau nhưng không nhất thiết phải biết nhau, sống trên cùng một máy, thậm chí không ở trong cùng một trung tâm dữ liệu.

Và kể từ khi Google Reader ngừng hoạt động, tôi bắt đầu với một trình đọc RSS, sử dụng Akka tất nhiên. Đó là tất cả về các dịch vụ đóng gói cho tôi. Kết luận: Bản thân mô hình diễn viên là điều bạn nên áp dụng trước tiên và Akka là một khuôn khổ rất đáng tin cậy giúp bạn thực hiện nó với rất nhiều lợi ích bạn sẽ nhận được trên đường đi.

Chúng tôi đang sử dụng akka với plugin lạc đà của nó để phân phối phân tích và xử lý xu hướng cho twimpact.com . Chúng tôi phải xử lý từ 50 đến 1000 tin nhắn mỗi giây. Ngoài xử lý đa nút bằng lạc đà, nó cũng được sử dụng để phân phối công việc trên một bộ xử lý cho nhiều công nhân để có hiệu suất tối đa. Hoạt động khá tốt, nhưng đòi hỏi một số hiểu biết về cách xử lý tắc nghẽn.

Tôi đã thử dùng Akka (Java api). Những gì tôi đã cố gắng là so sánh mô hình đồng thời dựa trên diễn viên của Akka với mô hình đồng thời Java đơn giản (các lớp java.util.conc hiện).

Trường hợp sử dụng là một bản đồ kinh điển đơn giản làm giảm việc thực hiện số lượng ký tự. Bộ dữ liệu là một tập hợp các chuỗi được tạo ngẫu nhiên (độ dài 400 ký tự) và tính toán số nguyên âm trong chúng.

Đối với Akka, tôi đã sử dụng Bal cânDispatcher (để cân bằng tải giữa các luồng) và RoundRobinRouter (để giữ giới hạn cho các tác nhân chức năng của tôi). Đối với Java, tôi đã sử dụng kỹ thuật nối ngã ba đơn giản (được triển khai mà không có bất kỳ thuật toán đánh cắp công việc nào) sẽ phân tách bản đồ / giảm thực thi và tham gia kết quả. Kết quả trung gian đã được tổ chức trong việc chặn hàng đợi để làm cho việc tham gia càng song song càng tốt. Có lẽ, nếu tôi không sai, điều đó sẽ bắt chước bằng cách nào đó khái niệm "hộp thư" của các diễn viên Akka, nơi họ nhận được tin nhắn.

Quan sát: Cho đến tải trung bình (~ 50000 đầu vào chuỗi) kết quả tương đương nhau, thay đổi một chút trong các lần lặp khác nhau. Tuy nhiên, khi tôi tăng tải lên ~ 100000, nó sẽ treo giải pháp Java. Tôi đã cấu hình giải pháp Java với 20-30 luồng trong điều kiện này và nó đã thất bại trong tất cả các lần lặp.

Tăng tải lên 1000000, cũng gây tử vong cho Akka. Tôi có thể chia sẻ mã với bất kỳ ai quan tâm để kiểm tra chéo.

Vì vậy, đối với tôi, có vẻ như Akka mở rộng tốt hơn giải pháp đa luồng Java truyền thống. Và có lẽ lý do là sự kỳ diệu của Scala.

Nếu tôi có thể mô hình hóa một miền vấn đề như một thông điệp hướng sự kiện đi qua một, tôi nghĩ Akka là một lựa chọn tốt cho JVM.

Thử nghiệm được thực hiện trên: Phiên bản Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. Ram 3GB. Bộ xử lý Intel Core i5, tốc độ xung nhịp 2,5 GHz

Xin lưu ý, miền vấn đề được sử dụng cho thử nghiệm có thể được tranh luận và tôi đã cố gắng công bằng như kiến ​​thức Java của tôi cho phép :-)

Chúng tôi sử dụng Akka trong các hệ thống hộp thoại nói ( primetalk ). Cả bên trong và bên ngoài. Để chạy đồng thời nhiều kênh điện thoại trên một nút cụm đơn, rõ ràng cần phải có một số khung đa luồng. Akka hoạt động hoàn hảo. Chúng tôi có cơn ác mộng trước đó với java-concurrency. Và với Akka, nó giống như một chiếc xích đu - đơn giản là nó hoạt động. Mạnh mẽ và đáng tin cậy. 24 * 7, không ngừng.

Trong một kênh, chúng tôi có luồng sự kiện theo thời gian thực được xử lý song song. Cụ thể: - nhận dạng giọng nói tự động dài - được thực hiện với một diễn viên; - nhà sản xuất đầu ra âm thanh trộn một vài nguồn âm thanh (bao gồm cả lời nói tổng hợp); - chuyển đổi văn bản thành giọng nói là một tập hợp các tác nhân được chia sẻ giữa các kênh; - xử lý ngữ nghĩa và kiến ​​thức.

Để thực hiện kết nối xử lý tín hiệu phức tạp, chúng tôi sử dụng SynapseGrid . Nó có lợi ích của việc kiểm tra thời gian biên dịch của DataFlow trong các hệ thống tác nhân phức tạp.

Gần đây tôi đã triển khai ví dụ rút gọn bản đồ chính tắc trong Akka: Word Count. Vì vậy, đó là một trường hợp sử dụng của Akka: hiệu suất tốt hơn. Nó giống như một thử nghiệm của các diễn viên của JRuby và Akka hơn bất kỳ thứ gì khác, nhưng nó cũng cho thấy Akka không phải là Scala hay Java: nó hoạt động trên tất cả các ngôn ngữ trên JVM.