Nhắn tin, Hàng đợi và ESB - Tôi biết mình muốn ở đâu nhưng không biết cách đến đó

Question

Để cắt một câu chuyện dài, tôi đang làm việc trên một dự án mà chúng tôi đang viết lại một ứng dụng web lớn cho tất cả các lý do thông thường. Mục đích chính của việc viết lại là tách riêng ứng dụng đơn lớn này chạy trên một máy chủ đơn thành nhiều ứng dụng tách nhỏ hơn, có thể chạy trên nhiều máy chủ.

Ok đây là những gì tôi muốn:

Tôi muốn HTTP là cơ chế vận chuyển chính. Khi một ứng dụng ví dụ như các CMS đã được cập nhật nó sẽ liên lạc với người môi giới thông qua http và nói "I've changed", sau đó người môi giới sẽ gửi lại một 200 OK nói "thanks I got the message".

Nhà môi giới sau đó sẽ xem danh sách các ứng dụng khác muốn nghe về thay đổi CMS và chuyển thông báo tới url mà ứng dụng còn lại khi nó nói với nhà môi giới muốn nghe về thông báo.

Các ứng dụng khác sẽ trả về 200 OK khi họ nhận được tin nhắn, nếu không phải nhà môi giới lưu tin nhắn và xếp hàng cho lần tiếp theo ai đó cố liên lạc với ứng dụng đó.

Vấn đề là tôi thậm chí không biết bắt đầu từ đâu hoặc những gì tôi cần để làm cho nó xảy ra. Tôi đã nhìn vào XMPP, ActiveMQ, RabbitMQ, Mule ESB vv và có thể nhìn thấy tôi có thể dành những năm tiếp theo đi xung quanh trong vòng tròn với công cụ này.

Có ai có thể đưa ra bất kỳ lời khuyên nào từ kinh nghiệm cá nhân vì tôi rất muốn tránh học bài học một cách khó khăn.

Answer 1

Tôi đã làm việc với tin nhắn JMS trong các hệ thống phần mềm khác nhau kể từ khoảng năm 2003. Tôi có một ứng dụng web nơi khách hàng là người đăng ký chủ đề JMS hiệu quả. Bởi hành động chỉ xuất bản một tin nhắn vào một chủ đề, tin nhắn được máy chủ đẩy không phân biệt cho tất cả các khách hàng đăng ký web.

Máy khách web dựa trên Flex. trung cấp ngăn xếp của chúng tôi bao gồm:

• Java 6
• Tomcat 6
• BlazeDS
• mùa xuân-Khung
• ActiveMQ (broker nhắn JMS)

BlazeDS có khả năng được cấu hình như một cầu nối với JMS. Đó là một servlet Tomcat đáp ứng các cuộc gọi từ xa của máy khách Flex nhưng cũng có thể thực hiện thông báo đẩy tới các máy khách khi các thông báo mới xuất hiện trong chủ đề JMS mà nó được cấu hình.

BlazeDS thực hiện các mẫu Comet để thực hiện nhắn push server-side:

Asynchronous HTTP and Comet architectures An introduction to asynchronous, non-blocking HTTP programming

Systems Farata đã thông báo rằng họ đã sửa đổi BlazeDS để làm việc với các cách tiếp cận continuations Jetty để thực hiện mẫu Comet.Điều này cho phép nhân rộng hàng nghìn kết nối Comet trên một máy chủ vật lý đơn lẻ.

Farata Systems Achieves Performance Breakthrough with Adobe BlazeDS

Chúng tôi đang chờ đợi Adobe để thực hiện hỗ trợ của Servlet 3,0 trong BlazeDS mình là về cơ bản chúng ta đang khá gắn bó với sử dụng Tomcat và mùa xuân trong combo.

Chìa khóa cho kỹ thuật thực hiện mô hình Comet có thể mở rộng quy mô lớn là sử dụng trình nghe Java NIO HTTP kết hợp với một nhóm luồng (chẳng hạn như lớp Executor trong thư viện Java 5 Concurrency). Servlet 3.0 là một mô hình hướng sự kiện không đồng bộ cho các servlet có thể được gắn với nhau với một trình nghe HTTP như vậy. Hàng ngàn (số lượng từ 10.000 đến 20.000) kết nối Comet đồng thời sau đó có thể được duy trì chống lại một máy chủ vật lý duy nhất.

Mặc dù trong trường hợp của chúng tôi, chúng tôi đang sử dụng công nghệ Adobe Flex để biến khách hàng web thành người đăng ký nhắn tin theo hướng sự kiện, tương tự có thể được thực hiện cho bất kỳ ứng dụng web AJAX chung nào. Trong vòng tròn AJAX, kỹ thuật thực hiện đẩy thông điệp phía máy chủ thường được gọi là Đảo ngược AJAX. Bạn có thể đã bắt được rằng Comet là một cách chơi chữ, giống như trong bản sao của Ajax (cả hai chất tẩy rửa gia dụng). Điều tốt đẹp cho chúng tôi, mặc dù, chúng tôi chỉ dây với nhau mảnh của chúng tôi và đi chúng tôi đi. Các trình lập trình web AJAX chung sẽ có nhiều công việc lập trình hơn để thực hiện. (Ngay cả một ứng dụng web chung có thể chơi với BlazeDS, mặc dù - nó chỉ sẽ không có bất kỳ sử dụng cho marshaling AMF mà BlazeDS có khả năng.)

Cuối cùng, Adobe và SpringSource đang hợp tác để thiết lập một mượt mà hơn, ngoài of-the-box hội nhập của BlazeDS kết hợp với mùa xuân-Khung:

Adobe Collaborates with SpringSource for Enhanced Integration Between Flash and SpringSource Platforms

Answer 2

Trước hết, đừng lo lắng về ESBS. Tình huống bạn đã mô tả nằm trong giới hạn của phần mềm trung gian hướng thông điệp đơn giản. Bạn chỉ "cần" một ESB nếu bạn đang làm những việc như hòa giải, định tuyến dựa trên nội dung, chuyển đổi giao thức; những thứ mà phần mềm trung gian làm công cụ với thông báo, trên cùng là định tuyến nó đến đúng nơi.

Nếu bạn có nhiều ứng dụng đích khác nhau cần nói chuyện với nhau - và có vẻ như bạn làm - bạn nói đúng rằng nhắn tin qua giao thức độc lập về ngôn ngữ (như XMPP, STOMP hoặc HTTP) là gọn gàng dung dịch. Về cơ bản nó có nghĩa là bạn không cần phải viết và tải các trình tiện ích Java để dịch các thông điệp vào hương vị ưa thích của bạn về JMS.

STOMP ngày càng được hỗ trợ bởi các nhà môi giới thư, đặc biệt là bởi các nhà cung cấp mã nguồn mở và có một số thư viện khách hàng khác nhau. Nó là một giao thức gọn nhẹ, được thiết kế đặc biệt cho việc nhắn tin để bạn có được một tính năng phong phú hơn nhiều so với tính năng của HTTP.

Đối với tôi, XMPP là một chút của một lựa chọn yếu vì nó không phải rất tốt hỗ trợ trên phía máy chủ, mặc dù nó là thú vị để có thể để nhắn tin môi giới của bạn :)

Nếu bạn đang đặt trên HTTP, OpenMQ rất tốt và cá nhân tôi đã sử dụng Universal Message Service - về cơ bản là trình bao bọc webapp quanh các đích JMS. Nó cung cấp một giao diện REST-ful, với một bộ động từ tương tự như STOMP cung cấp.

Answer 3

Bạn đang thực sự nói về xuất bản và đăng ký với giao hàng được đảm bảo. Hầu hết các phần mềm MOM nên dễ dàng hỗ trợ trường hợp sử dụng của bạn.

Answer 4

Như ai đó đã nói, mô tả của bạn về cơ bản là Mô hình nhà xuất bản/đăng ký. Điều này là rất dễ dàng đạt được bằng cách sử dụng hoặc một ESB hoặc một hàng đợi tin nhắn.Tôi đã có một số kinh nghiệm với RabbitMQ. Nó rất tốt. Không có gì bị mất và nó đề cập đến mô hình đăng ký xuất bản rất tốt. Trước đây tôi đã đi xuống tuyến đường trên các hệ thống quy mô nhỏ của việc phát triển nhà môi giới tin nhắn của riêng tôi với một giao thức riêng biệt qua http. Tôi sẽ không tư vấn cho điều này, lý do là khi bạn bắt đầu phát triển nó, bạn tiếp tục suy nghĩ về cách mở rộng nó.

RabbitMQ được phát triển trong Erlang nhưng nó có java, net, python vv khách hàng có thể móc vào nó rất dễ dàng. Tôi đã sử dụng các máy khách .net và python, nó hoạt động tốt. Tôi đã chọn nó cho danh tiếng của Erlangs để tạo ra các hệ thống vững chắc có thể đối phó với nhiều thứ đang diễn ra cùng một lúc, rất tốt. Tôi sẽ gọi họ là chủ đề nhưng tôi nghĩ rằng nó thông minh hơn chỉ đề, tôi nghĩ rằng tôi nhớ lẩm bẩm của các diễn viên Model và hộp thư, mà tôi nhớ là khá gọn gàng.

Tôi đã ở một vị trí tương tự như chính mình nhưng với kinh nghiệm rất xấu của các hệ thống nhắn tin khác (Biztalk và cộng sự) đã quá đắn đo buộc bạn vào một giải pháp. Nếu bạn có thể giữ các thông điệp tách biệt khỏi các cơ chế vận chuyển và phân phối, thì bạn có thể phát triển hệ thống của mình thành nội dung trái tim của bạn. Tôi đã sử dụng JSON cuối cùng vì kích thước gói nhỏ. Bạn có thể sử dụng bất kỳ thứ gì bạn thích, một số lựa chọn cho thông điệp SOAP, nhưng tôi cảm thấy rằng đây là cách quá nặng đối với hầu hết mọi thứ, mặc dù nó cho phép bạn đưa các lược đồ XSD vào bên ngoài một cách độc đáo để chúng có thể phát triển các hệ thống tương tác với bạn hệ thống trong tương lai.

http://www.rabbitmq.com/tutorials/tutorial-three-java.html, đây là liên kết đến hướng dẫn trên mô hình Xuất bản/Đăng ký và cách bạn sẽ đạt được nó bằng cách sử dụng hệ thống xếp hàng thư. Nó cho rabbitMQ, nhưng thành thật mà nói nó sẽ làm việc với ESB và bất kỳ hệ thống tin nhắn nào khác trên mạng.

Answer 5

ESB (Enterprise Serial Bus) - Hãy xem xét điều này khi ứng dụng của bạn có nhiều tương tác với hai hoặc nhiều ứng dụng bên ngoài/riêng biệt, mỗi ứng dụng này sẽ không giao tiếp ở định dạng dữ liệu tương tự. Ví dụ: Một số hệ thống có thể chấp nhận các đối tượng, XML, JSON, SMTP, TCP/IP, HTTP, HTTPS, v.v.

ESB có nhiều tính năng như: Định tuyến, địa chỉ, kiểu nhắn tin, Giao thức truyền tải.

Xem xét hệ thống xếp hàng nếu ứng dụng của người sản xuất - người tiêu dùng tuân theo cùng một loại định dạng dữ liệu.

Dịch vụ web (SOAP/REST) ​​là tốt nhất nếu một ứng dụng cần ứng dụng khác để hoàn thành luồng công việc. Sử dụng Hàng đợi nếu ứng dụng cần truyền dữ liệu không đồng bộ.

Answer 6

Như đã nói ở trên, có một ESB cho trường hợp hiện tại của bạn có vẻ như tôi muốn đập vỡ một con ruồi bằng búa.

Bản thân phần mềm ESB sẽ tốn thời gian và sẽ yêu cầu bảo trì. Nếu bạn đi đến giải pháp nguồn mở, nó có thể mất nhiều thời gian hơn việc sử dụng một giải pháp được cấp phép (IBM, ORACLE, ...).

Tất nhiên ESB sẽ thực hiện công việc, và sẽ rất dễ dàng để phát triển giải pháp, nhưng việc thiết lập ESB sẽ khó khăn hơn so với thực hiện giải pháp.

Nếu vấn đề của bạn được giới hạn trong các trường hợp được mô tả, tôi sẽ đánh giá cao đề nghị bạn để xây dựng một kiến ​​trúc đơn giản hơn OpenMQ (hoặc tương tự), và sử dụng nó thông qua JMS