ESB là gì và nó tốt để làm gì?

Tại một công việc trước đây, đã có rất nhiều lời bàn tán về "Enterprise Service Bus" (ESB). Tôi đã đọc các phần của một cuốn sách khái niệm về nó, nhưng chưa bao giờ thực sự hiểu cách bạn sẽ triển khai / tích hợp nó một cách cụ thể. Tôi quen thuộc với SOA / hàng đợi / dịch vụ thư mục / vv. nhưng tôi không hiểu chính xác ESB là gì.

Đó có phải là một điều cụ thể (dịch vụ / máy chủ / nhà môi giới / v.v.) mà bạn chỉ kết nối tất cả các ứng dụng của mình với nó theo những cách khác nhau, hay nó chỉ là một cách khái niệm để thiết kế hệ thống?

Bất kỳ lời giải thích hoặc liên kết đến các ví dụ tốt sẽ được đánh giá rất cao. Cảm ơn.

Đó là một khái niệm trừu tượng khá cao. Khái niệm trung tâm là ESB cung cấp phần mềm trung gian và các giao diện cho phép các doanh nghiệp kết nối các ứng dụng của họ mà không cần viết mã.

Điều này có thể bao gồm dàn xếp để điều chỉnh các giao thức, dữ liệu và tương tác không tương thích.

Ý tưởng về một chiếc xe buýt trung tâm mà mọi thứ đi qua mang lại cơ hội cho các lớp trừu tượng bổ sung. Việc sử dụng các tiêu chuẩn công nghiệp để "cắm" các ứng dụng, máy khách, v.v. khác vào xe buýt này giúp cho việc kết nối các dịch vụ mới, nguồn dữ liệu, máy khách có nhu cầu khác nhau tương đối dễ dàng.

Triển khai thực tế

Theo như việc triển khai thực tế, đó là lĩnh vực của các doanh nghiệp hỗ trợ doanh nghiệp rất lớn. Mặc dù nó rất thông dụng, nhưng mục tiêu là một lý tưởng mà ở một mức độ nhỏ nào đó có thể hiểu được thông qua so sánh với internet:

Tương tự với Internet

Một bus truyền thông lớn với nhiều cách sử dụng và dữ liệu khác nhau, nhưng tất cả đều chạy chuẩn hóa các giao thức.

Trên thực tế, người ta có thể viết một trình kết nối HTTP sang FTP cho phép các trình duyệt truy cập các trang FTP mà không cần gọi một ứng dụng khách FTP (thường được tích hợp sẵn trong trình duyệt bây giờ).

Mashup

Mashup thể hiện một cách triển khai thú vị - lấy một số dữ liệu tuyến xe buýt từ chính quyền San Francisco, bản đồ từ google và các vị trí quán sushi từ yahoo với xếp hạng và chạy một truy vấn đơn giản cung cấp cho bạn quán sushi gần nhất, cân nó sao cho sẵn sàng đi xa hơn một chút để có một quán bar tốt hơn.

Tất cả các dịch vụ hoàn toàn khác nhau, không tương thích với nhau, nhưng sử dụng các đầu nối tiêu chuẩn (ví dụ: đường ống yahoo), chúng có thể được kết hợp với nhau thành một tổng thể gắn kết và hữu ích.

-Adam

Khước từ trách nhiệm: Tôi làm việc cho IBM và tham khảo ý kiến ​​trên WebSphere ESB, một sản phẩm của IBM được thiết kế để xây dựng các ESB với. Sau đây là ý kiến ​​của tôi và không nhất thiết phản ánh quan điểm của IBM.

Thật không may, một ESB là những thứ khác nhau đối với những người khác nhau.

Đối với tôi, ESB là một công nghệ bất kỳ mà bạn có thể chèn vào SOA (Kiến trúc hướng dịch vụ), cho phép bạn kết nối các hệ thống khác nhau với nhau. Nó thường thực hiện các chức năng chuyển đổi giao thức, sửa đổi thông báo, định tuyến, ghi nhật ký, hoạt động như một cổng bảo mật, v.v. Ví dụ: bạn có thể sử dụng ESB để hiển thị một dịch vụ trước đây chỉ có sẵn dưới dạng Dịch vụ Web cũng như một dịch vụ dựa trên JMS.

Về mặt này, việc triển khai ESB (hay nói chính xác hơn, phần mềm được bán để xây dựng ESB - chẳng hạn như phần mềm mà tôi tham khảo) thường tương tự về mặt công nghệ với những gì từng được gọi là môi giới nhắn tin hoặc xếp hàng, mặc dù mục đích hơi khác , bởi vì (như các từ viết tắt ngụ ý) nó được định hướng xung quanh các dịch vụ hơn là chuyển thông điệp từ nơi này sang nơi khác. Mức độ quan trọng của sự khác biệt về mặt công nghệ là một vấn đề quan điểm.

Kinh nghiệm của tôi với ESB thương mại là nó là một công nghệ quá mức và đắt tiền, tạo ra nhiều vấn đề như nó có thể giải quyết được. ESB sẽ liên kết các hệ thống mới và di sản, tin nhắn sẽ bay qua xe buýt và mọi thứ sẽ có thể nói chuyện với mọi thứ khác một cách liền mạch. Ném vào một số khả năng phục hồi, điều phối và bạn có một phần mềm ứng dụng doanh nghiệp rất mạnh mẽ.

Vấn đề xảy ra khi bạn cố gắng sử dụng chúng thực sự, chi phí viết cho bus, tạo cấu trúc thông báo, v.v., có thể lớn hơn lợi ích. Là một mặt hàng có chi phí cao, ESB được coi là liều thuốc chữa bách bệnh cho tất cả các vấn đề công nghệ mà nó không phải là nó, dành quá nhiều thời gian trên xe buýt và không dành cho các ứng dụng / dữ liệu được kết nối. Thông thường, nhiều tiêu chuẩn cạnh tranh sẽ tranh giành quyền tối cao trong cùng một tổ chức, dẫn đến các hệ thống công nghệ cổ điển thống trị mà các hệ thống này thực sự nên sửa chữa.

IMHO tốt hơn là sử dụng tạo một số lượng nhỏ các giao diện cụ thể, thường chỉ sử dụng các dịch vụ web giữa những hệ thống cần nó.

Về cơ bản, đó là một cách thiết kế hệ thống theo khái niệm - các công ty phần mềm cố gắng bán cho bạn nhiều hơn bằng cách dán nhãn 'ESB' trên đó và các nhà quản lý thích bởi vì ESB trông đẹp từ 'cấp cao hơn'.

ESB về cơ bản là một MOM (phần mềm trung gian định hướng thông điệp) với một mô hình dữ liệu bổ sung và quản lý định nghĩa cấu trúc. Bạn có một định nghĩa dữ liệu chung cho tất cả các ứng dụng và bộ điều hợp trên bus đó (có thể là XML với XSD được chia sẻ). Bất cứ thứ gì kết nối PHẢI gửi thông tin đó tuân theo định nghĩa dữ liệu này. ESB hỗ trợ tải, chia sẻ và lập phiên bản của định nghĩa dữ liệu chung này. Khi kết nối một thành phần mới với ESB, bạn có thể mong đợi nhiều 'khả năng tương thích' hơn so với khi kết nối nó với MOM. Mỗi thành phần trên bus đó về mặt khái niệm được coi như một 'tài nguyên' - vì vậy có một phần trừu tượng bổ sung được giới thiệu để tách người gửi khỏi người nhận.

Ví dụ: giả sử bạn muốn kết nối ứng dụng A với ứng dụng B trong một phần mềm trung gian định hướng thông báo tiêu chuẩn, hãy sử dụng JMS. Bạn nói chuyện với đồng nghiệp của mình đang làm việc trên ứng dụng B, đồng ý về chủ đề, loại tin nhắn và các trường và gửi nó (mã giả): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101,4 vol = 100})

Nếu bạn làm điều tương tự trong kiến ​​trúc hướng dịch vụ, bạn cần

1. cài đặt phần mềm bổ sung
2. học rất nhiều khái niệm mới
3. xác định thành phần Java mới của bạn trong gui quản trị của ESB
4. triển khai một số giao diện được kiểm soát bởi ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101,4 vol = 100}) - lưu ý điểm đến được đưa vào từ ESB

Lần đầu tiên có lẽ hơi đau, nhưng tôi đoán bạn có thể quen với nó, giống như bạn có thể quen với EJB của ;-)

Bạn có thể nói hệ thống MOM là 'chưa định kiểu' (cấu trúc động) trong khi ESB là 'có kiểu' (cấu trúc tĩnh). Sự cân bằng giữa Nhắn tin thô so với ESB tương tự như các lựa chọn chưa định kiểu / đã nhập khác:

• REST so với SOAP
• XML chưa được xác thực so với XML được xác thực bằng XSD
• Groovy so với Java
• ngôn ngữ thông dịch so với ngôn ngữ biên dịch

Đối với các dự án nhỏ hơn, thật tốt khi băm chức năng một cách nhanh chóng (ví dụ như mã Groovy) nhưng đối với các dự án lớn hơn, tốt hơn nên có trình gỡ lỗi (ví dụ: Java), được cảnh báo trước khi mọi thứ bị hỏng và có tiêu chuẩn cho mọi người trước khi họ cam kết dự án.

Vì vậy, nếu dự án của bạn bị quá nhiều người phá vỡ hệ thống bằng cách kiểm tra các thay đổi chưa được xác nhận - hãy chuyển sang cấu trúc nhiều hơn (ESB thay vì MOM). Nếu các dự án của bạn gặp phải tình trạng không hoàn thành đủ công việc kịp thời - hãy chọn giải pháp đơn giản hơn, không kiểu cách. Nếu đó là cả hai - hãy nhờ một chuyên gia tư vấn (đùa thôi ;-)

Vâng, điều đó phụ thuộc vào người bạn hỏi ... Nhiều người sẽ nói rằng đó là một phần của "Phần mềm trung gian" kết nối các phần khác nhau của "logic nghiệp vụ" với nhau để lấy mã hóa ra khỏi thông điệp giữa các mô-đun này. Tôi nghĩ đó là một định nghĩa đủ chung chung, nhưng tôi chắc rằng bạn đã đến đó qua Wikipedia rồi còn gì không.

Những người muốn có ESB tuyệt vời cứu thế giới sẽ thấy nó vì nó được trình bày phổ biến nhất, một trung tâm để làm mọi thứ. Hầu hết các triển khai ESB đều nỗ lực để gói gọn tất cả các tác vụ lặp đi lặp lại mà chúng ta thấy trong phần mềm kinh doanh. Điều đó có nghĩa là hầu hết các ESB đảm nhận việc truyền dữ liệu, bảo mật, ghi nhật ký, dịch giao thức, hệ thống sự kiện, hiển thị api qua các dịch vụ web, v.v.

Tôi nghĩ điều đó rõ ràng nhất có thể của tôi ... Hy vọng điều đó sẽ hữu ích.

Hãy xem bài thuyết trình của tôi " Tha hồ lựa chọn - Cách chọn ESB phù hợp ".

Tôi giải thích khi nào nên sử dụng ESB, Integration Suite, hay chỉ là Integration Framework (chẳng hạn như Apache Camel). Tôi cũng thảo luận về sự khác biệt giữa mã nguồn mở và ESB độc quyền.

Ngoài định nghĩa tiêu chuẩn mà bạn có thể lấy từ Wikipedia . Tôi thấy nó là một công cụ tuyệt vời để kết nối một loạt các hệ thống kế thừa trên nhiều nền tảng và công nghệ. Nó cũng là một công cụ tốt để xây dựng quy trình làm việc phân tán và hệ thống quản lý nhà nước (chẳng hạn như sổ cái chung).

Tuy nhiên, nó khá đắt, phức tạp và không thuận tiện trong việc duy trì và mở rộng, khiến nó trở thành một lựa chọn công nghệ kém như một công cụ mục đích chung để mở rộng các ứng dụng của bạn.