Cả hai dường như mạng MPI giao tiếp song song của các quá trình. Tôi xác định các diễn viên với các dịch vụ. Các diễn viên có năng động hơn không (bạn có thể tạo ra chúng và giết như thở trong khi mạng dịch vụ tĩnh hơn) hay sao?
Câu trả lời:
Mô hình diễn viên - là mô hình toán học cho các tính toán đồng thời và microservice - một triển khai của kiến trúc hướng dịch vụ. Những điểm tương đồng khá trùng hợp.
Chắc chắn có thể xây dựng các dịch vụ siêu nhỏ dựa trên một số mô hình diễn viên và mô hình hóa một số kiến trúc microservice với mô hình diễn viên, nhưng điều đó không có nghĩa là những điều này là tương đương. Thay thế "hệ thống microservice" bằng "hệ thống email", và nó vẫn sẽ đúng. Thay thế "mô hình diễn viên" bằng "Giao tiếp các quá trình tuần tự" (CSP), và nó cũng sẽ là "đúng", bởi vì các hệ thống mô hình diễn viên và CSP có thể được mô hình hóa bởi nhau.
Đưa ra mô hình diễn viên, bạn có thể thực hiện nó bằng microservice, hoặc SOA hoặc thậm chí email, nhưng điều đó không có nghĩa là họ ở cùng một mức độ trừu tượng để thực sự so sánh.
Ngoài ra, mô hình diễn viên nhấn mạnh bộ đệm (có thể được coi là hàng đợi tin nhắn trong thế giới microservice), vì vậy một số diễn viên / microservice không thể sẵn sàng trong khi vẫn có thể giao tiếp không đồng bộ.
Nói cách khác, so sánh với mô hình diễn viên có thể mang lại một số hiểu biết sáng tạo ở mức độ xem xét rất cao, nhưng chủ yếu là táo và cam.
Nếu mục tiêu là so sánh mô hình toán học của SOA / microservice với mô hình Actor, thì nó cũng không tầm thường, bởi vì: 1) không có mô hình toán học nào được thống nhất cho mô hình SOA, 2) thường bao gồm mục đích. Và mô hình hóa dịch vụ / microservice rất có thể khác với mục đích mô hình diễn viên. Một ví dụ về nỗ lực mô hình hóa SOA ở đây .
Tất nhiên, người ta có thể tạo hệ thống mô hình diễn viên với microservice và gọi mỗi dịch vụ là diễn viên (tham khảo định nghĩa chặt chẽ về mô hình diễn viên là gì). Nhưng điều này không có nghĩa là có bất kỳ mối quan hệ có ý nghĩa giữa hai bên theo nghĩa chung.
Microservice là một cách để tổ chức phần mềm bằng cách chia từng khu vực quan tâm thành tạo phẩm có thể triển khai của riêng nó (thực thi, tập lệnh, JAR, WAR, v.v.). Điều này mang lại cho bạn sự linh hoạt, ví dụ bằng cách cho phép bạn mở rộng quy mô bằng cách triển khai thêm các trường hợp cần thiết. Giả sử người dùng dành nhiều thời gian hơn để xem danh mục của bạn hơn là họ thêm mọi thứ vào giỏ hàng; một tạo phẩm có thể triển khai xử lý các chức năng danh mục, một chức năng khác xử lý các chức năng giỏ hàng - bạn có thể chạy nhiều bản sao của các dịch vụ danh mục để xử lý tải.
Nó cũng cách ly chúng khỏi những thay đổi bên trong. Giả sử bạn chuyển từ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu tài liệu để lưu trữ dữ liệu sản phẩm - tỷ lệ cược là dịch vụ giỏ hàng của bạn sẽ không cần thay đổi.
Mô hình diễn viên ở mức thấp hơn so với tạo phẩm có thể triển khai, nói thêm về loại đối tượng bạn đã triển khai dịch vụ. Tiếp tục với ví dụ trên, bạn có thể có các giỏ hàng trong hệ thống của mình được đại diện bởi các diễn viên, vì vậy mỗi giỏ hàng của người dùng là một diễn viên riêng biệt và thông báo yêu cầu họ thêm các mặt hàng, xóa các mặt hàng, phản hồi với nội dung hiện tại, thêm giao hàng, kiểm tra , v.v. Trong trường hợp này, bạn vẫn có một dịch vụ siêu nhỏ và nó được triển khai với mô hình diễn viên.
Tôi muốn nói rằng sự khác biệt chính là một trong những chi tiết.
Đối với mô hình diễn viên, nó tương đối tốt, trong đó một diễn viên có xu hướng đại diện tương đương với một đối tượng trong OOP.
Đối với các dịch vụ vi mô, nó tương đối thô, trong đó một dịch vụ vi mô có thể bao gồm một số lượng lớn các tác nhân hoặc đối tượng.
Lưu ý rằng bạn sẽ không thực sự cần phải kéo dài trí tưởng tượng của mình quá xa để nói rằng web hiện đại chỉ là điều tương tự ở mức độ chi tiết thậm chí còn lớn hơn ("dịch vụ vĩ mô"); và rằng (ví dụ) máy chủ HTTP là dịch vụ macro, máy chủ cơ sở dữ liệu là dịch vụ macro, trình duyệt web là dịch vụ macro, v.v.
Tất cả đều giống nhau - những mảnh bị cô lập giao tiếp. Chỉ có kích thước của các mảnh (và do đó số lượng mảnh) thay đổi.
Microservice quy mô theo chiều ngang bằng cách tạo nhiều bản sao, mỗi bản sao có khả năng phục vụ các yêu cầu do tính chất không trạng thái của dịch vụ. Họ kiên cường trước thất bại nhờ bản chất không quốc tịch của họ.
Các diễn viên mở rộng quy mô bằng cách di chuyển chúng đến các phân vùng với ít tải hơn hoặc nhiều tài nguyên có sẵn hơn. họ đang stateful . Họ kiên cường trước thất bại bởi vì - tùy thuộc vào khuôn khổ diễn viên - một diễn viên khác có thể được tạo ra một cách linh hoạt hoặc một bản sao lưu nóng của diễn viên có thể được duy trì mọi lúc để đối phó với thất bại của diễn viên chính.
Một lần nữa, microservice cũng có thể có trạng thái, nhưng nó đi ngược lại các nguyên tắc thiết kế của microservice.