Điều gì thực sự khác biệt giữa SOA và microservice

Khước từ

Tôi hy vọng tôi không giẫm lên chân ai hoặc xúc phạm những người đam mê khái niệm

Lý lịch

Tôi đã tìm kiếm sự khác biệt thực sự giữa Kiến trúc hướng dịch vụ và Dịch vụ vi mô, mà không tìm thấy câu trả lời rõ ràng nào.

Tôi đọc những thứ như:

• tác dụng phụ của SOA
• SOA đang chống mẫu
• Microservice đã đến để sửa chữa các thất bại của SOA
• ESB không thực sự là ESB thay vào đó là EAI
• Quá phụ thuộc vào môi giới tin nhắn
• Các nhà cung cấp đang lạm dụng khái niệm về SOA và cố gắng bán sản phẩm của họ
• SOA phát triển không kiểm soát

Tuy nhiên, vẫn không có gì xác định rõ ràng sự khác biệt về kiến ​​trúc giữa Kiến trúc hướng dịch vụ (như một khái niệm) và microservice (như một khái niệm)

Theo những gì tôi hiểu, cả hai đều có:

• Nhà cung cấp dịch vụ, chỉ làm một việc
• Cổng dịch vụ / ESB trưng bày các dịch vụ đó cho người tiêu dùng
• Người tiêu dùng dịch vụ, truy cập dịch vụ qua ESB / Cổng dịch vụ

Câu hỏi

Vì vậy, có điều gì khác ngoài việc gắn nhãn lại vào dịch vụ microsoft không? nó có phải là một hạn chế công nghệ được đặt để hạn chế microservice trở thành vĩ mô không?

Lưu ý: Tôi không tìm kiếm ý kiến, chỉ những sự thật khó khăn, hy vọng ở những gạch đầu dòng

Người giới thiệu

• Câu hỏi Kỹ thuật phần mềm
• Trang web của Martin Fowler (Tôi nghĩ rằng anh ấy ghét thời gian lớn)
• Thế giới thông tin
• Trang web của Michael Fethers
• Câu hỏi chồng chéo

Cập nhật

Có vẻ như một cuộc tranh luận tương tự đã xảy ra trong một câu hỏi tràn Stack , với các ý kiến ​​được chia theo thời gian hoặc không phải là Dịch vụ vi mô là Kiến trúc hướng dịch vụ được ngụy trang.

Kết luận từ câu hỏi SO:

• MS là một trường hợp đặc biệt của SOA
• MS xác nhận kích thước nhỏ hơn của các ứng dụng dịch vụ lưu trữ
• MS phụ thuộc vào công nghệ (việc sử dụng HTTP thay vì tùy chọn giao thức mở)
• MS dựa vào công nghệ để thi hành kỷ luật (tự động triển khai dịch vụ)
• MS sử dụng ESB (ác), nhưng sử dụng API Gateways mà IMHO là một loại ESB

Điều đó kết luận rằng MS là SOA, nếu như sau đây là đúng:

• MS có ủng hộ khái niệm dàn nhạc không? Một hoặc nhiều quy trình tổng thể quản lý quy trình công việc
• Có một lớp môi giới tin nhắn trong MS? Một bộ các bộ điều hợp dịch các định dạng tin nhắn từ không gian tin nhắn của nhà sản xuất dịch vụ sang người tiêu dùng dịch vụ
• Microservice có thể đọc dữ liệu từ các ứng dụng doanh nghiệp nguyên khối? Nó có thể là API của một ứng dụng nguyên khối không? hoặc nó phải là các ứng dụng độc lập, có khả năng hoạt động độc lập?

Nếu câu trả lời cho câu hỏi cuối cùng là không, thì microservice sẽ không thể xử lý các hệ thống quy trình công việc phức tạp, ví dụ: Hệ thống quản lý thẻ tín dụng hoặc hệ thống đối chiếu

Nhà cung cấp dịch vụ, chỉ làm một việc

Sự khác biệt cốt lõi, có hậu quả lan rộng của dự án, là với microservice, các Nhà cung cấp dịch vụ này có thể triển khai độc lập và có thể mở rộng .

Điều này thật tuyệt, vì bạn có thể nhanh nhẹn hơn. Nếu một dịch vụ cần thay đổi, bạn chỉ cần thay đổi dịch vụ đó, không phải là dịch vụ của họ. Nếu bạn muốn thử một khung hoặc ngôn ngữ mới, chỉ cần thực hiện thay thế thả xuống cho một dịch vụ đó. Nếu bạn đột nhiên cần dung lượng 100 lần, hãy quay một số máy mới với dịch vụ đó để xử lý dòng tiền đó. Nếu bạn muốn phiên bản một cái gì đó, chỉ cần phiên bản mà không cần chạm vào toàn bộ ứng dụng. Và nó làm cho mọi thứ dễ dàng hơn để theo dõi, dụng cụ, phân chia giữa các đội, lỗi thời ...

Nhưng nó đi kèm với một số hàm ý nặng nề:

• Quá trình phát hành của bạn cần thay đổi, bởi vì việc triển khai một vài dịch vụ khác với cách triển khai vài chục dịch vụ.
• Quá trình phát hành của bạn cần thay đổi, bởi vì việc triển khai một dịch vụ cho một máy khác với cách triển khai đến vài chục máy.
• Thiết kế, sử dụng và triển khai cơ sở dữ liệu của bạn cần thay đổi vì việc triển khai một dịch vụ nếu việc triển khai DB được chia sẻ lớn này hoạt động là vô nghĩa (phá vỡ tất cả các dịch vụ khác của bạn).
• Thiết kế và cách sử dụng thư viện của bạn cần thay đổi vì việc triển khai một dịch vụ là vô nghĩa nếu nó cần cập nhật thư viện dùng chung này (phá vỡ tất cả các dịch vụ khác của bạn).
• Khai thác gỗ của bạn / cho phép / quản lý phiên / etc cần phải thay đổi vì nó khá dễ dàng để chia sẻ nội dung khi bạn chỉ là một dịch vụ, nhưng khác nhau khi bạn có một loạt các dịch vụ ít độc lập tạo nên sản phẩm - và họ đang đi tới muốn chia sẻ thứ. Ồ, và tất cả những thứ được chia sẻ đó cần phải đối phó với khả năng có trên các phiên bản khác nhau.
• Giao tiếp của bạn cần phải thay đổi. Với một vài dịch vụ, bạn có thể phá vỡ mọi thứ dọc theo đó giao tiếp không xảy ra thường xuyên và / hoặc có thể xảy ra chậm. Với microservice, họ sẽ nói chuyện với nhau rất nhiều và độ trễ cao sẽ không cắt giảm.

Đây là điểm mấu chốt Một điểm khác biệt rõ ràng giữa SOA và microservice là khái niệm về

Smart Endpoint Dumb Faucet

Không giống như SOA , điều đó phụ thuộc vào người tiêu dùng và nhà sản xuất dịch vụ lãng quên, ủy thác quản lý lưu lượng, dịch thuật định dạng tin nhắn và điều phối dịch vụ cho các hệ thống bên ngoài, ví dụ ESB, Nhà soạn nhạc dịch vụ, Nhà môi giới tin nhắn.