Dịch vụ kính hiển vi xây dựng sách mô tả chi tiết các kiểu được đề cập bởi @RogerAlsing trong câu trả lời của ông.
Trên trang 43 dưới phần Dàn nhạc và Biên đạo, cuốn sách nói:
Khi chúng ta bắt đầu mô hình hóa logic ngày càng phức tạp hơn, chúng ta phải đối phó với vấn đề quản lý các quy trình kinh doanh trải dài qua ranh giới của các dịch vụ riêng lẻ. Và với microservice, chúng tôi sẽ đạt giới hạn này sớm hơn bình thường. [...] Khi thực sự thực hiện dòng chảy này, có hai phong cách kiến trúc chúng ta có thể làm theo. Với sự phối hợp, chúng tôi dựa vào một bộ não trung tâm để hướng dẫn và điều khiển quá trình, giống như nhạc trưởng trong một dàn nhạc. Với vũ đạo, chúng tôi thông báo cho từng bộ phận trong hệ thống công việc của mình và để nó giải quyết các chi tiết, giống như các vũ công đều tìm đường và phản ứng với những người khác xung quanh họ trong một vở ballet.
Cuốn sách sau đó tiến hành để giải thích hai phong cách. Phong cách phối hợp tương ứng nhiều hơn với ý tưởng về dịch vụ phối hợp / nhiệm vụ của SOA , trong khi phong cách vũ đạo tương ứng với các ống câm và các điểm cuối thông minh được đề cập trong bài viết của Martin Fowler.
Phong cách dàn nhạc
Theo phong cách này, cuốn sách trên có đề cập:
Chúng ta hãy nghĩ về một giải pháp phối hợp sẽ như thế nào cho dòng chảy này. Ở đây, có lẽ điều đơn giản nhất để làm là có dịch vụ khách hàng của chúng tôi đóng vai trò là bộ não trung tâm. Khi tạo, nó nói chuyện với ngân hàng điểm trung thành, dịch vụ email và dịch vụ bưu chính [...], thông qua một loạt các cuộc gọi yêu cầu / phản hồi. Bản thân dịch vụ khách hàng có thể theo dõi vị trí của khách hàng trong quy trình này. Nó có thể kiểm tra xem tài khoản của khách hàng đã được thiết lập chưa, hoặc email được gửi hoặc bài được gửi. Chúng ta có được sơ đồ [...] và mô hình hóa nó trực tiếp thành mã. Chúng tôi thậm chí có thể sử dụng công cụ thực hiện điều này cho chúng tôi, có lẽ sử dụng một công cụ quy tắc phù hợp. Các công cụ thương mại tồn tại cho mục đích này dưới dạng phần mềm mô hình hóa quy trình kinh doanh. Giả sử chúng tôi sử dụng yêu cầu / phản hồi đồng bộ, chúng ta thậm chí có thể biết nếu mỗi giai đoạn đã hoạt động [...] Nhược điểm của phương pháp phối hợp này là dịch vụ khách hàng có thể trở thành quá nhiều của một cơ quan quản lý trung ương. Nó có thể trở thành trung tâm ở giữa một trang web và một điểm trung tâm nơi logic bắt đầu sống. Tôi đã thấy cách tiếp cận này dẫn đến một số lượng nhỏ các dịch vụ thông minh của Thần thông minh nói với các dịch vụ dựa trên CRUD thiếu máu phải làm gì.
Lưu ý: Tôi cho rằng khi tác giả đề cập đến công cụ, anh ta đang đề cập đến một cái gì đó như BPM (ví dụ: Activity , Apache ODE , Camunda ). Trên thực tế, Trang web Mẫu quy trình làm việc có một bộ mẫu tuyệt vời để thực hiện kiểu phối hợp này và nó cũng cung cấp chi tiết đánh giá của các công cụ nhà cung cấp khác nhau để thực hiện theo cách này. Tôi không nghĩ rằng tác giả ngụ ý người ta bắt buộc phải sử dụng một trong những công cụ này để thực hiện kiểu tích hợp này, các khung công tác phối hợp nhẹ khác có thể được sử dụng, ví dụ như Spring Integration , Apache Camel hoặc Mule ESB
Tuy nhiên, những cuốn sách khác mà tôi đã đọc về chủ đề của microservice và nói chung, phần lớn các bài báo tôi tìm thấy trên web dường như làm mất phương pháp phối hợp này và thay vào đó đề nghị sử dụng cuốn tiếp theo.
Phong cách vũ đạo
Theo phong cách vũ đạo tác giả nói:
Với cách tiếp cận được biên đạo, thay vào đó chúng ta có thể chỉ cần dịch vụ khách hàng phát ra một sự kiện theo cách không đồng bộ, nói rằng Khách hàng đã tạo. Dịch vụ email, dịch vụ bưu chính và ngân hàng điểm trung thành sau đó chỉ cần đăng ký các sự kiện này và phản ứng tương ứng [...] Cách tiếp cận này được phân tách rõ rệt hơn. Nếu một số dịch vụ khác cần thiết để tiếp cận với việc tạo ra một khách hàng, nó chỉ cần đăng ký các sự kiện và thực hiện công việc của nó khi cần thiết. Nhược điểm là quan điểm rõ ràng về quy trình kinh doanh mà chúng ta thấy trong [quy trình công việc] hiện chỉ được phản ánh ngầm trong hệ thống của chúng tôi [...] Điều này có nghĩa là cần có thêm công việc để đảm bảo rằng bạn có thể theo dõi và theo dõi rằng những điều đúng đã xảy ra. Ví dụ, bạn có biết ngân hàng điểm khách hàng thân thiết có lỗi không và vì lý do nào đó đã không thiết lập đúng tài khoản? Một cách tiếp cận tôi thích để giải quyết vấn đề này là xây dựng một hệ thống giám sát phù hợp rõ ràng với quan điểm của quy trình kinh doanh trong [quy trình công việc], nhưng sau đó theo dõi những gì mỗi dịch vụ làm như các thực thể độc lập, cho phép bạn thấy các ngoại lệ kỳ lạ được ánh xạ lên dòng quy trình rõ ràng hơn. [Lưu đồ] [...] không phải là động lực, mà chỉ là một thấu kính mà qua đó chúng ta có thể thấy hệ thống đang hoạt động như thế nào. Nói chung, tôi đã thấy rằng các hệ thống có xu hướng hướng tới phương pháp biên đạo được kết nối lỏng lẻo hơn, và linh hoạt hơn và có thể thay đổi. Tuy nhiên, bạn cần phải làm thêm để theo dõi và theo dõi các quy trình qua ranh giới hệ thống. Tôi đã tìm thấy hầu hết các triển khai được phối hợp chặt chẽ là cực kỳ dễ vỡ, với chi phí thay đổi cao hơn. Với ý nghĩ đó, tôi rất thích nhắm đến một hệ thống được biên đạo, trong đó mỗi dịch vụ đủ thông minh để hiểu vai trò của nó trong toàn bộ điệu nhảy.
Lưu ý: Cho đến ngày nay tôi vẫn không chắc chắn nếu vũ đạo chỉ là một tên khác cho kiến trúc hướng sự kiện (EDA), nhưng nếu EDA chỉ là một cách để làm điều đó, thì những cách khác là gì? (Xem thêm làm bạn có ý nghĩa gì bởi "Event-Driven"? Và Ý nghĩa của Kiến trúc Event-Driven ). Ngoài ra, có vẻ như những thứ như CQRS và EventSource cộng hưởng rất nhiều với phong cách kiến trúc này, phải không?
Bây giờ, sau khi điều này đến niềm vui. Cuốn sách microservice không cho rằng microservice sẽ được triển khai với REST. Như một vấn đề thực tế trong phần tiếp theo của cuốn sách, họ tiến hành xem xét các giải pháp dựa trên RPC và SOA và cuối cùng là REST. Một điểm quan trọng ở đây là microservice không ngụ ý REST.
Vì vậy, những gì về HATEOAS? (Hypermedia là Công cụ của Trạng thái Ứng dụng)
Bây giờ, nếu chúng ta muốn theo cách tiếp cận RESTful, chúng ta không thể bỏ qua HATEOAS hoặc Roy Fielding sẽ rất hài lòng khi nói trong blog của anh ấy rằng giải pháp của chúng tôi không thực sự là REST. Xem bài đăng trên blog của anh ấy về API REST Phải là siêu văn bản :
Tôi cảm thấy thất vọng bởi số lượng người gọi bất kỳ giao diện dựa trên HTTP nào là API REST. Những gì cần phải được thực hiện để làm cho phong cách kiến trúc REST rõ ràng trên khái niệm rằng siêu văn bản là một hạn chế? Nói cách khác, nếu công cụ của trạng thái ứng dụng (và do đó API) không được điều khiển bởi siêu văn bản, thì nó không thể là RESTful và không thể là API REST. Giai đoạn = Stage. Có một số hướng dẫn bị hỏng ở một nơi nào đó cần phải được sửa chữa?
Vì vậy, như bạn có thể thấy, Fielding nghĩ rằng nếu không có HATEOAS thì bạn không thực sự xây dựng các ứng dụng RESTful. Đối với Fielding, HATEOAS là con đường để đi khi nói đến các dịch vụ điều phối. Tôi chỉ đang học tất cả những điều này, nhưng với tôi, HATEOAS không xác định rõ ràng ai hoặc động lực đằng sau thực sự theo các liên kết. Trong một giao diện người dùng có thể là người dùng, nhưng trong các tương tác giữa máy tính với máy tính, tôi cho rằng cần phải được thực hiện bởi một dịch vụ cấp cao hơn.
Theo HATEOAS, liên kết duy nhất mà người tiêu dùng API thực sự cần biết là liên kết bắt đầu giao tiếp với máy chủ (ví dụ: POST / order). Từ thời điểm này, REST sẽ tiến hành luồng, bởi vì, trong phản hồi của điểm cuối này, tài nguyên được trả về sẽ chứa các liên kết đến các trạng thái có thể tiếp theo. Người tiêu dùng API sau đó quyết định liên kết nào sẽ theo dõi và chuyển ứng dụng sang trạng thái tiếp theo.
Mặc dù âm thanh đó hay đến mức nào, khách hàng vẫn cần phải biết liệu liên kết phải được POST, PUTed, GET, PATCHed, v.v. Và khách hàng vẫn cần phải quyết định tải trọng nào sẽ vượt qua. Khách hàng vẫn cần phải biết phải làm gì nếu thất bại (thử lại, bù, hủy, v.v.).
Tôi khá mới đối với tất cả những điều này, nhưng đối với tôi, từ quan điểm của HATEOAs, khách hàng này hoặc người tiêu dùng API là một dịch vụ cao cấp. Nếu chúng tôi nghĩ rằng từ quan điểm của một con người, bạn có thể tưởng tượng người dùng cuối trên trang web, quyết định nên theo liên kết nào, nhưng vẫn vậy, lập trình viên của trang web phải quyết định sử dụng phương pháp nào để gọi liên kết, và tải trọng gì để vượt qua. Vì vậy, theo quan điểm của tôi, trong một tương tác giữa máy tính với máy tính, máy tính đóng vai trò của người dùng cuối. Một lần nữa, đây là những gì chúng tôi gọi là một dịch vụ điều phối.
Tôi cho rằng chúng ta có thể sử dụng HATEOAS với cả dàn nhạc hoặc vũ đạo.
Mẫu cổng API
Một mô hình thú vị khác được đề xuất bởi Chris Richardson, người cũng đã đề xuất cái mà ông gọi là Mẫu cổng API .
Trong kiến trúc nguyên khối, các máy khách của ứng dụng, chẳng hạn như trình duyệt web và ứng dụng gốc, thực hiện các yêu cầu HTTP thông qua bộ cân bằng tải đến một trong N phiên bản giống hệt của ứng dụng. Nhưng trong một kiến trúc microservice, khối đá nguyên khối đã được thay thế bằng một bộ sưu tập các dịch vụ. Do đó, một câu hỏi quan trọng chúng ta cần trả lời là khách hàng tương tác với cái gì?
Một ứng dụng khách, chẳng hạn như một ứng dụng di động gốc, có thể tạo các yêu cầu HTTP RESTful cho các dịch vụ riêng lẻ [...] Nhìn bề ngoài, điều này có vẻ hấp dẫn. Tuy nhiên, có thể có sự không phù hợp đáng kể về độ chi tiết giữa các API của các dịch vụ riêng lẻ và dữ liệu theo yêu cầu của khách hàng. Ví dụ: hiển thị một trang web có khả năng yêu cầu các cuộc gọi đến số lượng lớn dịch vụ. Amazon.com, ví dụ,
mô tả cách một số trang yêu cầu cuộc gọi đến hơn 100 dịch vụ. Thực hiện nhiều yêu cầu đó, thậm chí qua kết nối internet tốc độ cao, chứ chưa nói đến một mạng di động có băng thông thấp hơn, độ trễ cao hơn, sẽ rất kém hiệu quả và dẫn đến trải nghiệm người dùng kém.
Một cách tiếp cận tốt hơn là cho các khách hàng thực hiện một số lượng nhỏ yêu cầu trên mỗi trang, có lẽ chỉ một, qua Internet đến một máy chủ ngoại vi được gọi là cổng API.
Cổng API nằm giữa các ứng dụng khách của ứng dụng và microservice. Nó cung cấp các API phù hợp với khách hàng. Cổng API cung cấp API chi tiết thô cho các máy khách di động và API chi tiết hơn cho các máy khách để bàn sử dụng mạng hiệu suất cao. Trong ví dụ này, các máy khách để bàn thực hiện nhiều yêu cầu để truy xuất thông tin về một sản phẩm, trong khi máy khách di động thực hiện một yêu cầu duy nhất.
Cổng API xử lý các yêu cầu đến bằng cách thực hiện các yêu cầu đối với một số dịch vụ siêu nhỏ qua mạng LAN hiệu suất cao. Netflix, ví dụ,
mô tả
cách mỗi người hâm mộ yêu cầu trung bình sáu dịch vụ phụ trợ. Trong ví dụ này, các yêu cầu chi tiết từ máy khách để bàn chỉ đơn giản là được cung cấp cho dịch vụ tương ứng, trong khi mỗi yêu cầu chi tiết thô từ máy khách di động được xử lý bằng cách tổng hợp kết quả của việc gọi nhiều dịch vụ.
Cổng API không chỉ tối ưu hóa giao tiếp giữa khách hàng và ứng dụng mà còn gói gọn các chi tiết của microservice. Điều này cho phép microservice phát triển mà không ảnh hưởng đến khách hàng. Ví dụ: hai microservice có thể được hợp nhất. Một dịch vụ siêu nhỏ khác có thể được phân vùng thành hai hoặc nhiều dịch vụ. Chỉ cổng API cần được cập nhật để phản ánh những thay đổi này. Các khách hàng không bị ảnh hưởng.
Bây giờ chúng ta đã xem xét cách cổng API làm trung gian giữa ứng dụng và ứng dụng khách, bây giờ chúng ta hãy xem cách triển khai giao tiếp giữa các dịch vụ siêu nhỏ.
Điều này nghe có vẻ khá giống với phong cách phối hợp được đề cập ở trên, chỉ với một ý định hơi khác, trong trường hợp này, nó dường như là tất cả về hiệu suất và đơn giản hóa các tương tác.
.