2015-12-04 22 views
6

Ứng dụng của chúng tôi sẽ tích hợp như một người tiêu dùng đến một loạt các hệ thống bên ngoài.Thực tiễn tốt nhất về kiến ​​trúc tích hợp cho các ứng dụng Doanh nghiệp

Hầu hết các tích hợp này không chỉ là xử lý và định tuyến thư. Có rất nhiều logic phức tạp, như lưu trữ một trạng thái hiện tại, các thực thi theo lịch trình và các công cụ khác.

Bên cạnh đó, mỗi tích hợp không chia sẻ nhiều logic phổ biến.

Phương pháp hay nhất để xây dựng loại hệ thống này là gì?

Tôi có nên tạo lớp tích hợp tất cả trong một không? Nó có thể là một ứng dụng nguyên khối với các tuyến đường và bộ vi xử lý apache khác nhau cho mỗi tích hợp: enter image description here

Hoặc tôi nên chia nó thành các ứng dụng độc lập nhỏ và đơn giản để chúng có thể được thu nhỏ và triển khai độc lập?

enter image description here

Lợi ích và nhược điểm nào tôi có thể nhận được với mỗi giải pháp?

+0

Đối với tôi, mục tiêu ứng dụng ESB hoặc Camel Base là khả năng sử dụng lại và điểm duy nhất để tìm tài nguyên, trong trường hợp của bạn: truy cập ứng dụng chính, bảo mật và nhật ký. Ngay cả khi có logic khác nhau để cung cấp dịch vụ cho mỗi hệ thống bên ngoài. Vì vậy, các ứng dụng nguyên khối cho con đường của tôi. –

Trả lời

2

Có khá một vài tiêu chí để có trong tâm trí:

  • Kinh tế: chi phí dự án, chi phí hoạt động
  • Throughput: khối lượng dữ liệu mỗi lần
  • trễ: thời gian đi lại tin nhắn
  • Bảo mật: bảo vệ dữ liệu
  • Độ bền: mất ổn định của thất bại
  • linh hoạt: giảm bớt phản ứng về việc thay đổi yêu cầu
  • Process Hỗ trợ: kiểm soát luồng dữ liệu, sự kiện/lỗi xử lý

Việc lựa chọn một tốt kiến trúc giải pháp phụ thuộc vào tầm quan trọng của các tiêu chí đó đối với môi trường CNTT đã cho. Đối với các ứng dụng doanh nghiệp, nó khá phổ biến để sử dụng một nền tảng tích hợp hơn là xây dựng logic tích hợp vào các ứng dụng. một nền tảng như vậy thường bao gồm các thành phần cho kết nối, lập bản đồ tin nhắn, định tuyến, giám sát/cảnh báo, khai thác gỗ, kế toán, quản lý thay đổi, vv

Hỏi công cụ tìm kiếm ưa thích của bạn cho Integration Patterns hoặc Enterprise Application Integration.

+0

Cảm ơn bạn đã trả lời.Nhưng tôi vẫn không thể tìm thấy bất kỳ lợi ích nào cho phương pháp đầu tiên (tất cả trong một tích hợp ứng dụng). Với Spring Boot, cho một ví dụ, không có vấn đề lớn để bắt đầu, xây dựng và triển khai các ứng dụng nhỏ mới. Nó thực sự tiện dụng để kiểm tra các ứng dụng nhỏ này, để sửa đổi logic, quy mô và triển khai độc lập. Vậy, lợi ích của phương pháp đầu tiên có thể là gì? –

+0

Nếu bạn dịch tất cả trong một tích hợp thành "nền tảng tích hợp trung tâm", bạn sẽ nhận được khá nhiều lợi ích: hỗ trợ thân thiện, chất lượng, tài liệu, tư vấn có tay nghề trên thị trường, giám sát, ghi nhật ký, cảnh báo, linh hoạt, quy trình xử lý. Để sử dụng và vận hành một loạt các ứng dụng tích hợp khác nhau là khó khăn hơn nhiều và dễ bị lỗi. –

2

Hãy để tôi chia sẻ ý kiến ​​của mình. Nói chung như Axel Kemper đã tuyên bố có rất nhiều yếu tố có thể ảnh hưởng đến quyết định của bạn và không có giải pháp viên đạn bạc ở đây.

tôi sẽ cố gắng giữ cho nó kỹ thuật, vì vậy:

Một ứng dụng Monolithic:

  • dễ dàng hơn để triển khai. Nói chung, bạn sẽ chỉ cần một/một vài máy chủ. Từ quan điểm của nhà phát triển, sự khác biệt có thể không rõ ràng, nhưng nói chuyện với nhóm dev-ops của bạn và họ sẽ ngay lập tức nói rằng việc triển khai một ứng dụng dễ dàng hơn nhiều cho họ

  • Dễ giám sát hơn. Về cơ bản cho cùng một lý do như trên. Hãy hỏi những câu trả lời về vấn đề này :)

  • Nó có thể nhanh hơn. Nếu các ứng dụng tích hợp khác nhau nên kết nối bằng cách nào đó (không được nêu trong lược đồ của bạn), thì có khả năng chúng có thể bị giao thức "qua mạng" chậm. Trong một ứng dụng nguyên khối, mọi thứ đều nằm trong cùng một JVM.

  • Có thể yêu cầu ít máy chủ hơn. Nếu bạn đang chạy trong một đám mây riêng tư/một số môi trường lỗi thời, nó có thể khá rắc rối khi cắm một máy chủ mới. Bạn có thể lấy 2-3 máy chủ cho các ứng dụng của bạn và đó là nó :)

"Nhiều ứng dụng tích hợp" kiến ​​trúc (trong sự hiểu biết của tôi nó thực sự giống như kiến ​​trúc vi-dịch vụ trong lĩnh vực hội nhập) có những ưu điểm sau:

  • Dễ dàng nâng cấp các phần khác nhau của nó. Nếu bạn có một ứng dụng nguyên khối, không có cách nào bình thường để nâng cấp chỉ một phần của API, cần có một nâng cấp lớn cho toàn bộ ứng dụng. Nếu "điểm tích hợp" khác nhau được phát triển bởi các Nhóm khác nhau, thì không rõ ràng để phối hợp giữa các bản phát hành.

  • Là kết quả của dấu đầu dòng, có khả năng sẽ mất ít thời gian hơn để sửa lỗi trong điểm tích hợp (từ thời điểm lỗi được phát hiện đến khi sửa lỗi được triển khai trong sản xuất). Chỉ cần sửa chữa trong một điểm tích hợp cụ thể và triển khai lại nó. Nó nhẹ hơn nhiều.

  • Cân "hết" tốt hơn. Nếu bạn trải nghiệm việc sử dụng chuyên sâu một số điểm tích hợp cụ thể, bạn có thể dễ dàng thêm một điểm khác (hoặc nhiều hơn) trên máy chủ khác. Trong phương pháp tiếp cận nguyên khối, bạn sẽ phải cài đặt toàn bộ ứng dụng để đạt được hiệu ứng tương tự. Một trường hợp sử dụng khác là nếu bạn được triển khai trong một đám mây và bạn có một khách hàng sẵn sàng trả tiền cho một quyền truy cập độc quyền vào một điểm tích hợp cụ thể.

  • Dễ kiểm tra hơn (có thể cho là). Nếu bạn đang chạy thử nghiệm tích hợp/hệ thống để kiểm tra điểm tích hợp của mình, thì bạn có thể tổ chức luồng CI để hệ thống sẽ chạy song song. Thêm vào đó một khởi động nhẹ hơn nhiều và bạn sẽ nhận được một dòng chảy linh hoạt hơn nhiều.

Tôi có thể đã bỏ lỡ một số khía cạnh so sánh (chắc chắn) nhưng đó là hướng IMO.

Hy vọng điều này sẽ giúp

Các vấn đề liên quan