2013-06-22 20 views
5

Tôi đã tìm kiếm chi tiết về ưu điểm của I/O không đồng bộ trong Java, đặc biệt là từ thiết kế ngăn xếp ứng dụng.I/O không đồng bộ - Java

tôi gặp rất nhiều ví dụ về máy chủ sự kiện thúc đẩy như Node.js, Tornedo, vv

Những gì tôi không hiểu là tại sao ai đó sẽ có cả một đống ứng dụng trong Java EE với Migrate JBoss hoặc WebLogic máy chủ ứng dụng một kiến ​​trúc hướng sự kiện.

Ngay cả những máy chủ này cũng hỗ trợ I/O không chặn. Có, họ đang phân bổ một chủ đề cho mỗi yêu cầu, nhưng với một threadpool tại chỗ, sẽ không các nguồn lực được tốt trong các thông số hiệu suất tốt?

Vui lòng cung cấp cho tôi một số đầu vào dọc theo các dòng sau.

  1. Tại sao kiến ​​trúc Java EE truyền thống với Apache-Tomcat/JBoss/Weblogic xem xét di chuyển đến kiến ​​trúc hướng sự kiện.
  2. Kiến trúc hướng sự kiện có hữu ích không khi cung cấp trang web/ứng dụng độc lập về thiết bị.
  3. Khi thiết kế một ứng dụng trên đám mây, chúng tôi sẽ đi cho một I/O không đồng bộ.
  4. Hiệu suất kiến ​​trúc hướng sự kiện tốt hơn so với kiến ​​trúc Java EE truyền thống hay là một huyền thoại.

Trả lời

2

Một trong những khái niệm quan trọng mà bạn đã đề cập đến là:

Vâng, họ đang Giao đất a thread cho mỗi yêu cầu

Nó được hiển thị thời gian và một lần nữa rằng có một thread cho mỗi yêu cầu với một ứng dụng bị ràng buộc IO cuối cùng sẽ cạn kiệt thread-pool của bạn khi mục tiêu của bạn là hỗ trợ một số lượng lớn người dùng đồng thời. Khi nó quay ra, các khung công tác mà bạn đang nói về như Node.js, Tornado, v.v. nổi trội trong việc xử lý một số lượng lớn người dùng đồng thời, nơi ứng dụng của bạn có nhiều khả năng chỉ chờ đợi một điều gì đó xảy ra và không thực hiện bất kỳ CPU nào các nhiệm vụ bị ràng buộc. Nói cách khác, những công cụ này là tuyệt vời để xây dựng các ứng dụng thời gian thực như trò chơi trực tuyến, phòng chat, hệ thống ghi nhật ký, hệ thống thông báo nơi mục tiêu chính nhanh chóng điều phối thông điệp nhỏ, với nhiều người dùng càng nhanh càng tốt.

Thực tế, các công cụ này rất tuyệt vời khi viết các ứng dụng dựa trên websocket vì nó thực sự cung cấp trải nghiệm thời gian thực hoặc gần thời gian thực cho người dùng.

Mặc dù nhiều công ty đang sử dụng các nền tảng này từ khi bắt đầu, tôi nghĩ rằng các công ty có ngăn xếp truyền thống sử dụng các công cụ hướng sự kiện càng bổ sung cho hệ thống của họ thì càng phổ biến. Khi bạn đi với một cái gì đó như node.js hoặc Tornado, bạn có thể thấy mình từ bỏ rất nhiều phần mềm tích hợp mà bạn dựa vào có lợi cho việc phải cuộn api và trình điều khiển của riêng bạn. Bây giờ node.js đã có mặt, và thực sự có rất nhiều sự hỗ trợ tuyệt vời cho việc tìm kiếm cơ sở dữ liệu, nền tảng nosql và các hệ thống xây dựng nhưng phải mất một thời gian để nó đến đó.

Là một thử nghiệm, hãy thử viết một ứng dụng trò chuyện tcp đơn giản sử dụng một chuỗi cho mỗi yêu cầu và xem bạn có thể hỗ trợ bao nhiêu người dùng. Cuối cùng, bạn sẽ đạt đến giới hạn với số lượng chủ đề hệ điều hành mà bạn có thể quay lên, điều này thực sự tốn kém.

Sau đó, xem bạn có thể đi được bao xa với node.js bằng cách sử dụng chỉ một chuỗi, chuỗi mặc định của nó. Bạn sẽ thấy rằng bạn có thể hỗ trợ một số lượng lớn yêu cầu đồng thời mỗi giây. Nó được biết đến với quy mô trong hàng triệu vì nó không bị giới hạn bởi các chủ đề, nó chỉ bị giới hạn bởi bộ nhớ, số lượng các bộ mô tả tập tin và cpu tại thời điểm đó.

Để trả lời câu hỏi của bạn tốt nhất mà tôi có thể:

  1. Tôi không nghĩ rằng đó là khả thi chỉ đơn giản là mương toàn bộ nền tảng của bạn chỉ vì bạn nghe thế nào Node.js tuyệt vời và kiến ​​trúc hướng sự kiện đang có. Bạn thực sự phải tự hỏi mình, nếu bạn có nhu cầu xây dựng một IO bị ràng buộc ứng dụng đồng thời cao. Nếu vậy, tại sao không chỉ sử dụng nó để bổ sung cho ngăn xếp hiện tại của bạn?
  2. Tôi không chắc chắn về câu hỏi thứ hai của bạn, ý của bạn là gì đối với thiết bị?
  3. Bạn có thể xây dựng một ứng dụng tuyệt vời trong đám mây dựa trên các công cụ truyền thống cũng giống như sử dụng các kiến ​​trúc hướng sự kiện. Thực tế là nó có thể là một ứng dụng "đám mây" thực sự không liên quan gì đến việc chọn nền tảng.
  4. Tôi có thể nói nó có quy mô hơn hiệu suất. Bạn có thể thấy rằng một ứng dụng node.js chạy chậm hơn hoặc nhanh hơn một ứng dụng java chạy cùng một mã. Nhưng những gì node.js có thể làm là cho phép một tỷ lệ thông lượng cao hơn nhiều bởi vì nó sẽ không đạt đến giới hạn luồng mà tôi đã đề cập. Và điều này cũng ngụ ý rằng bạn đã xây dựng một ứng dụng hướng sự kiện thích hợp, nơi bạn không chặn. Nếu bạn chặn, bạn gỡ toàn bộ hệ thống!
0

Hiệu suất sẽ phụ thuộc chủ yếu vào ứng dụng. Với nhiều yêu cầu, như bạn đã nói, có cần phải chạy một số chủ đề, những gì tiêu thụ bộ nhớ chính, như các chủ đề cần phải phục vụ yêu cầu trước khi phục vụ khác. Tôi không cảm thấy thoải mái để nói đó là nó, nhưng một sự khởi đầu của nó :-)

1

Tôi nghĩ hơn mình về việc thực hiện cơ bản, và giá rẻ trong chi phí chung nó mang lại:

Spinning của một thương hiệu mới chủ đề dành riêng để xử lý yêu cầu. Mỗi luồng không chặn I/O. Tuy nhiên, mang tính đồng thời như vậy ở cấp độ luồng là một mớ hỗn độn.

so

Sử dụng một thread, mà vẫn đáp ứng và hứa hẹn sẽ xử lý những thứ một chút thời gian trong tương lai. Không chặn trong khi thực hiện I/O, quản lý đồng thời không bắt buộc ở cấp luồng. Hãy để hệ điều hành xử lý điều đó.

Tại sao kiến ​​trúc Java EE truyền thống với Apache-Tomcat/JBoss/Weblogic xem xét di chuyển đến kiến ​​trúc có hướng sự kiện .

Có thể họ đang mệt mỏi vì các giải pháp quá chung chung, nặng cân và muốn kiểm tra các lựa chọn thay thế nhẹ mới. Những lựa chọn thay thế này là đơn giản để phát triển và triển khai, và quy mô rất tốt.

Kiến trúc điều khiển sự kiện có hữu ích khi cung cấp trang web/ứng dụng độc lập cho thiết bị không.

Tôi không nghĩ chúng có liên quan quá nhiều. Nhiều ngôn ngữ có thể chạy trên cùng một JVM. Đó là khả năng của JVM chạy trên nhiều máy chủ và hiển thị api tiêu chuẩn mang lại khả năng thuyết phục thiết bị.Một ví dụ khác là trình duyệt web.

Khi thiết kế ứng dụng trên đám mây, chúng tôi có thể sử dụng I/O không đồng bộ.

Phụ thuộc nhiều hơn vào các yêu cầu. I/O không đồng bộ không giải quyết được tất cả các vấn đề. Nhưng nó có thể giúp đỡ nếu bạn đang đi cho dễ dàng để tạo ra, giải pháp mở rộng nhanh chóng. Một lựa chọn tốt cho các phần khởi động mới với các giới hạn chặt chẽ.

Hiệu suất kiến ​​trúc hướng sự kiện tốt hơn so với kiến ​​trúc Java EE truyền thống hoặc là một huyền thoại.

Kiểm tra tốt hơn hiệu suất với một số good benchmarks, được điều chỉnh theo yêu cầu của doanh nghiệp của bạn.