Thành phần dịch vụ SOA có thực sự hoạt động trong thực tế không?

Một trong những nguyên tắc thiết kế dịch vụ chính của SOA là nguyên tắc Khả năng kết hợp dịch vụ ( https://en.wikipedia.org/wiki/Service_composability_principl ).

Ý tưởng là bằng cách kết hợp các dịch vụ mới bằng cách sử dụng các dịch vụ hiện có làm các khối xây dựng, người ta có thể nhanh chóng phát triển các dịch vụ mới. Kiểu tương tự như cách bạn gọi các phương thức hiện tại của các đối tượng khi bạn thực hiện các phương thức mới. Đây là nơi mà phần lớn tăng năng suất từ ​​SOA được cho là đến từ.

Có ai thực sự làm điều này trong thực tế? Tôi đã thấy điều này lặp đi lặp lại vô tận trong văn bản bằng văn bản, nhưng bản thân tôi chưa có kinh nghiệm triển khai thế giới thực. Hầu hết các văn bản cũng bỏ qua bất kỳ đề cập nào về xử lý giao dịch , dường như là trở ngại lớn nhất trong việc hiện thực hóa các dịch vụ có thể kết hợp.

Đầu tiên, bạn thực sự cần phải giải quyết vấn đề giao dịch trước khi bạn có thể soạn bất kỳ dịch vụ không tầm thường nào. Chắc chắn, nếu ví dụ này có các dịch vụ "findCienTime ()" và "writeLogMessage ()" thì bạn không dễ lo lắng về các giao dịch, nhưng không phải khi có các ví dụ trong thế giới thực như "DepositMoney ()" và "drawMoney () ".

Tôi biết hai lựa chọn:

1. Thực hiện các giao dịch thực với Giao dịch nguyên tử WS hoặc tương tự
2. Thực hiện giải pháp dựa trên bù mà bù cho cuộc gọi đến A bằng "CancA ()" hoặc somesuch nếu cuộc gọi đến B không thành công

Cả hai điều này dường như rất có vấn đề / gần với không thể sử dụng với tôi:

• Giao dịch nguyên tử WS
  • một nhiều phức tạp, hầu hết các lời khuyên mà tôi tìm thấy chỉ cảnh báo "cơn đau ở ass, dont làm điều đó"
  • hỗ trợ bị hạn chế, ví dụ: nếu bạn sử dụng ESB nguồn mở, các lựa chọn thay thế chính ServiceMix, Mule hoặc WSO2 không hỗ trợ
• bồi thường
  • thực hiện việc xử lý bồi thường có vẻ rất phức tạp đối với tôi. Chúng ta phải làm gì nếu dịch vụ A thành công và chúng ta không bao giờ nhận được câu trả lời từ dịch vụ B và không biết liệu nó có thất bại hay thành công không? Xử lý logic như vậy bằng tay (với tư cách là người triển khai các dịch vụ tổng hợp) khiến tôi muốn rạch cổ tay - đây là công việc mà một số công cụ nên làm cho tôi!.
  • Tôi cũng không thấy làm thế nào bạn có thể có các phương thức bồi thường trong các dịch vụ không tầm thường. Giả sử dịch vụ của bạn A là "DepositMoney ()" và thành công, một số hành động khác nhanh chóng chuyển tiền đi nơi khác và sau đó chúng tôi nhận được "offsetDepositMoney ()", chúng ta phải làm gì bây giờ? Có vẻ như một lon giun lớn.

Đối với tôi, dường như thành phần dịch vụ là một nguyên tắc cơ bản của SOA đến nỗi bạn thực sự không nhận được lợi ích của SOA nếu bạn không thể (thuận tiện) soạn các dịch vụ . Thực tế là gì? 90% người dùng SOA sử dụng "SOA bị tê liệt" mà không có sự đồng bộ hóa dịch vụ thực sự? Hoặc hầu hết người dùng thực tế sử dụng thành phần dịch vụ và tôi đang phóng đại sự khó khăn của nó?

Câu trả lời ngắn gọn là có!

Tôi đã thấy điều này được thực hiện tại một số tổ chức tài chính lớn, và, nó đã hoạt động tốt.

Các vấn đề giao dịch rất phức tạp nhưng thường được xử lý bởi phần mềm trung gian (đắt tiền) như Oracles WebLogic EAI hoặc IBMs Websphere ESB.

Vâng, nó có thể được thực hiện để làm việc trong thực tế. Tuy nhiên, nó có thể không phải là cách tiếp cận tốt nhất và có lẽ được sử dụng làm tùy chọn mặc định nhiều hơn mức cần thiết. Theo tôi, SOA trở nên phổ biến như một cách tích hợp các hệ thống cũ khi các tổ chức phát triển CNTT của họ để tự động hóa các nhiệm vụ lớn hơn bao giờ hết. Nó có thể rất lộn xộn nhưng có thể có giá trị nếu hệ thống cũ có thể được sử dụng lại. Nếu bạn đủ may mắn để bắt đầu một dự án lĩnh vực xanh, các cách tiếp cận khác nên được xem xét trước khi cho rằng đó là cách tốt nhất để đi.

Để trả lời một số mối quan tâm cụ thể hơn của bạn ...

Bạn có thể sử dụng các giao dịch:

1. WS-TX là một PITA và tôi sẽ tránh nó.
2. Tất cả các dịch vụ của bạn có thể đang chạy trong một máy chủ ứng dụng, trong trường hợp đó bạn có thể mở rộng tất cả chúng bằng một giao dịch XA. Đây là lý do tại sao những thứ như máy chủ ứng dụng được phát minh.

Xem xét phương pháp bồi thường dựa trên:

Hành động bồi thường chỉ cần được xem xét khi đã có một thất bại. Công cụ thành phần dịch vụ có một cờ mà nó có thể kiểm soát bị xóa khi chạy bước công việc lần đầu tiên, nhưng được đặt trên các lệnh tiếp theo không? Giống như cờ gửi lại có thể trong JMS. Sau đó, bạn có thể sử dụng cái được gọi là cam kết 1,5 pha, về cơ bản có nghĩa là đi trước nếu cờ rõ ràng, nhưng nếu cờ được đặt, trước tiên hãy thực hiện cuộc gọi để kiểm tra xem trạng thái đã được cập nhật chưa và cần phải thực hiện lần thứ hai . Điều này vẫn yêu cầu xử lý lỗi thủ công và có thể phức tạp hoặc thậm chí là không thể như bạn chỉ ra.

Trong một số tình huống không quan trọng:

Đây là cách tiếp cận cuối cùng phù hợp. Giả sử một dịch vụ gửi email. Nếu thành phần dịch vụ không thành công và được khởi động lại, email sẽ được gửi lại. Điều đó hơi khó chịu cho người nhận, nhưng có lẽ họ nhận ra đó là một bản sao và mọi thứ có thể tiếp tục mà không gặp vấn đề gì.

Bạn cũng có thể giữ một bản ghi email được gửi và sử dụng nó để hủy bản sao khi cờ được đặt và theo cách đó chỉ gửi email một lần.

Bạn có thể sử dụng nhắn tin không đồng bộ để chia các giao dịch thành các phần nhỏ hơn:

Hãy xem xét một hàng đợi JMS là giao dịch. Điều phối viên dịch vụ của bạn có thể cập nhật trạng thái của nó và gửi tin nhắn đến hàng đợi trong một Tx. Các dịch vụ xuôi dòng có thể tắt tin nhắn và cập nhật trạng thái của chúng trong một Tx. Bây giờ bạn đang điều phối các dịch vụ trong nhiều đơn vị công việc, nhưng mỗi đơn vị là nguyên tử. Nếu bất cứ điều gì thất bại và phải được khởi động lại không có vấn đề.

Điều này vẫn có nghĩa là bạn đang thực hiện các giao dịch XA qua cơ sở dữ liệu và hàng đợi JMS, nhưng điều này vẫn có thể hiệu quả bằng cách sử dụng tài nguyên cuối cùng để tránh toàn bộ XA.

Ngoài ra, bạn có thể sử dụng mẫu này nhưng với cam kết 1,5 pha với cơ sở dữ liệu và JMS. HOẶC bạn có thể chạy JMS mà không cần giao dịch nhưng làm cho nó đáng tin cậy hơn bằng cách phân cụm.

Nhắn tin Async cũng có thể giúp tách rời các hệ thống, vì nhà sản xuất và người tiêu dùng có thể trở nên độc lập với nhau hơn, giảm số lượng khớp nối trong toàn bộ hệ thống và làm cho nó linh hoạt hơn. Loại tách rời này là khá cần thiết khi nói đến các tổ chức lớn với nhiều dịch vụ đa dạng.

Không, đó là một huyền thoại. Đây là ý định sai khi thiết kế kiến ​​trúc dịch vụ. Có cả đống vấn đề:

1. Khớp nối rất chặt. Nếu một dịch vụ được thay đổi, bạn cần kiểm tra toàn bộ hệ thống.
2. Các dịch vụ như vậy rất tốt nên có rất nhiều thông tin liên lạc nội bộ.
3. Kết quả là hạt mịn có rất nhiều dịch vụ. Hệ thống trở nên khó hiểu, các truy vấn ngày càng khó theo dõi.
4. Các dịch vụ thực thể được đóng gói kém: không có quy tắc kinh doanh nào được kiểm tra ở đó, logic này nằm trong các dịch vụ vận hành. Vì vậy, bất kỳ dịch vụ nào cũng có thể gọi bất kỳ dịch vụ thực thể nào và cập nhật dữ liệu của nó với truy vấn cập nhật chung có trong giao diện của nó. Các loại dịch vụ thực thể như vậy thường được gọi là trung tâm dữ liệu - trái ngược với các dịch vụ tập trung vào quá trình, tập trung vào hành vi.
5. Bản chất bẩm sinh của giao tiếp giữa các dịch vụ này là đồng bộ. Vì vậy, cơ hội là phương tiện giao thông được chọn sẽ là http. Do đó tất cả những nhược điểm của nó mà tôi sẽ nói về một lát sau.

Thậm chí có nhiều cách sai hơn để tiếp cận kiến ​​trúc dịch vụ . Vì vậy, hãy thận trọng.