Dịch vụ kính hiển vi tự động, hàng đợi sự kiện và khám phá dịch vụ

Gần đây tôi đã đọc rất nhiều về các dịch vụ vi mô và đây là một số kết luận tôi đã nhận được cho đến nay (xin vui lòng sửa cho tôi nếu tôi sai ở bất kỳ điểm nào).

1. Kiến trúc vi dịch vụ phù hợp với thiết kế hướng tên miền. Thông thường một MS đại diện cho một bối cảnh giới hạn.
2. Nếu dịch vụ vi mô A yêu cầu chức năng cư trú trong dịch vụ vi mô B , mô hình của tôi có thể sai và A và B thực sự phải là một dịch vụ vi mô / BC.
3. Giao tiếp đồng bộ giữa các dịch vụ vi mô (yêu cầu HTTP trực tiếp) là không tốt, vì nó bất chấp mục đích của dịch vụ vi mô và giới thiệu khớp nối giữa các thành phần.
4. Giao tiếp không đồng bộ giữa các dịch vụ là mong muốn. Các dịch vụ nên xuất bản các sự kiện để xếp hàng tin nhắn, vì vậy các dịch vụ khác có thể đăng ký và xử lý một phần của sự kiện hoặc sử dụng nó để sao chép một phần dữ liệu cần thiết cho ngữ cảnh của chúng. Bằng cách này, các dịch vụ có thể xử lý các yêu cầu ngay cả các dịch vụ khác không hoạt động, điều này sẽ không xảy ra trong giao tiếp đồng bộ.
5. Nếu dịch vụ vi mô A xuất bản sự kiện, dịch vụ vi mô B đăng ký sự kiện đó và tạo ra một sự kiện mới là kết quả, thì dịch vụ vi mô A không phải là sự kiện mới được xử lý, vì đó sẽ là một sự phụ thuộc vòng tròn. Trong trường hợp này, chúng tôi nên giới thiệu dịch vụ vi mô thứ ba hoặc kết hợp A và B vào dịch vụ vi mô AB .
6. Dịch vụ vi mô thực sự là một thuật ngữ sai lệch. Chúng ta nên cố gắng cho các bối cảnh nhỏ, nhưng đó không phải là trường hợp. Thuật ngữ không nên là "dịch vụ vi mô", mà là " đủ lớn để thực hiện dịch vụ công việc ".
7. Các dịch vụ vi mô cho phép chúng tôi giới thiệu các chức năng mới dễ dàng hơn và không sợ rằng chúng tôi sẽ phá vỡ toàn bộ hệ thống. Nó có thể được thực hiện bằng cách giới thiệu một dịch vụ mới hoặc tái cấu trúc một trong những dịch vụ hiện có.
8. Mỗi dịch vụ vi mô nên có lưu trữ dữ liệu riêng. Sao chép / sao chép dữ liệu là hành vi mong muốn trong kiến ​​trúc này.

Khác với việc xác nhận sự hiểu biết của tôi về kiến ​​trúc này, phần khác của câu hỏi của tôi chủ yếu liên quan đến khám phá dịch vụ. Nếu các dịch vụ đang giao tiếp không đồng bộ và sử dụng hàng đợi sự kiện trung tâm như amazon SQS, điều đó có nghĩa là khám phá dịch vụ không có vị trí của nó trong kiến ​​trúc như vậy?

Dịch vụ không nên có bất kỳ kiến ​​thức nào về các dịch vụ khác trong hệ thống. Họ chỉ nhận thức được bối cảnh và sự kiện của họ mà họ nên xuất bản hoặc đăng ký?

Kết luận của bạn dường như chủ yếu được thành lập và tổng hợp rất độc đáo con đường dành cho microservice.

Tuy nhiên, tôi không hỗ trợ đầy đủ 2, 5 và 8:

• 2) Một phụ thuộc đơn giản không nên tự động dẫn đến sáp nhập. Bạn phải xem xét tần suất của các cuộc gọi phụ thuộc như vậy và tần suất của các cuộc gọi từ các dịch vụ khác.

  Vì vậy, nếu microservice A yêu cầu chức năng trong microservice B rất thường xuyên và microservice B hiếm khi cần bởi các dịch vụ siêu nhỏ khác, bạn nên thách thức cấu trúc dự kiến ​​và hỏi liệu có phù hợp hơn để nhóm cả hai dịch vụ micros micros không.

• 5) tất nhiên, bạn cần tránh đi xe đạp vô tận trong việc xử lý tin nhắn.

  Nhưng việc thêm một trung gian sẽ không ngăn được nó: A có thể khởi chạy một tin nhắn được xử lý bởi C, người sẽ khởi chạy một tin nhắn được xử lý bởi B, người sẽ khởi chạy một tin nhắn được xử lý bởi A và ở đây bạn bị mắc kẹt trong một vòng lặp.

  Vấn đề không thể được đánh giá chỉ bằng cách xem xét mức độ dịch vụ vi mô: câu hỏi thực sự là về loại thông báo và nội dung có thể dẫn đến chu kỳ. Do đó, biểu đồ mô hình phân phối và xử lý tin nhắn trên các dịch vụ phải được phân tích tổng thể (thực tế điều này có thể phức tạp, vì vậy bạn có thể tưởng tượng một dịch vụ siêu nhỏ giám sát phát hiện các chu kỳ đó và phá vỡ chúng).

• 8) có, mỗi microservice sẽ có bộ lưu trữ / cơ sở dữ liệu chuyên dụng.

  Yêu cầu tối thiểu sao chép để cho phép các dịch vụ được độc lập. Tuy nhiên tôi sẽ không đi xa để nói rằng sao chép là mong muốn: nó phải được giữ ở mức tối thiểu để tránh khớp nối ẩn thông qua các quá trình sao chép.

  Microservice là về khớp nối lỏng lẻo. Điều này đôi khi có thể đạt được hiệu quả hơn bằng cách gọi một dịch vụ siêu nhỏ khác để lấy dữ liệu liên quan, thay vì sao chép dữ liệu.

Hai khẳng định cuối cùng không được đánh giá là quá rộng để được trả lời chắc chắn ở đây. Tôi nghĩ đề xuất của bạn là một điểm khởi đầu tốt, nhưng nó thực sự phụ thuộc vào yêu cầu và ràng buộc kiến ​​trúc.

Các dịch vụ vi mô là về việc tách các miền chức năng khác nhau. Mỗi dịch vụ có thể được phát triển ở một tốc độ khác nhau, bởi một nhóm khác nhau, sử dụng một chồng công nghệ khác nhau. Điều này tạo ra sự linh hoạt của tổ chức. Sự đánh đổi là sự phức tạp trong hoạt động, trong đó mỗi dịch vụ bổ sung tạo ra một điều nữa phải được quản lý trong môi trường hoạt động. Vì vậy, sự đánh đổi cơ bản của nguyên khối so với dịch vụ vi mô không phải là để tránh sự phụ thuộc, mà là tránh việc phát triển và triển khai bước khóa trong đó mọi thứ phải vận chuyển cùng một lúc, nhưng với chi phí phải vận chuyển thường xuyên hơn vì có nhiều bộ phận chuyển động.

Dịch vụ không nên có bất kỳ kiến ​​thức nào về các dịch vụ khác trong hệ thống. Họ chỉ nhận thức được bối cảnh và sự kiện của họ mà họ nên xuất bản hoặc đăng ký?

Vấn đề tránh phụ thuộc là cá trích đỏ. Bạn sẽ luôn có sự phụ thuộc giữa các phần của sản phẩm và việc chúng ở trong một dịch vụ riêng biệt hay một phần của cùng một mã không làm thay đổi thực tế là sự phụ thuộc có thể bị phá vỡ. Chúng có thể phá vỡ ở cấp độ hoạt động, bởi vì một máy chủ quan trọng bị hỏng và bạn quản lý điều đó thông qua dự phòng hoạt động và thực hành thất bại. Chúng cũng có thể phá vỡ ở cấp độ tích hợp, bởi vì các bộ phận thay đổi theo những cách không tương thích, mà bạn phát hiện thông qua thử nghiệm tích hợp. Việc xáo trộn mã giữa các dịch vụ không giải quyết được vấn đề phụ thuộc có khả năng bị hỏng. Các giải pháp để tránh phụ thuộc bị hỏng là dự phòng hoạt động và thử nghiệm tích hợp, không liên quan gì đến quy mô dịch vụ của bạn.

Nếu các dịch vụ đang giao tiếp không đồng bộ và sử dụng hàng đợi sự kiện trung tâm như amazon SQS, điều đó có nghĩa là khám phá dịch vụ không có vị trí của nó trong kiến ​​trúc như vậy?

Để trả lời câu hỏi đó, trước tiên hãy trả lời câu hỏi này: tại sao bạn muốn giao tiếp không đồng bộ? Là nó để dễ dàng phát triển độc lập của các thành phần riêng biệt? Có phải để cải thiện khả năng hoạt động cho một hệ thống 24/7? Giả sử nó là cái sau và bạn muốn sử dụng hàng đợi để sao chép dữ liệu vào cơ sở dữ liệu cục bộ. Vâng, bây giờ dữ liệu của bạn có thể cũ. Đến một lúc nào đó nó sẽ quá cũ. Làm thế nào để bạn đối phó với điều đó? Hơn nữa, làm thế nào để bạn đảm bảo tính khả dụng hoạt động của hàng đợi, một thành phần thời gian chạy khác? Và làm thế nào để bạn đảm bảo sự sẵn có của các cơ sở dữ liệu địa phương? Thay vì quản lý một cụm cơ sở dữ liệu, bây giờ bạn có một số. Nhóm ops của bạn có thể xử lý khối lượng công việc này? Và thực sự, sự phức tạp có đáng không, khi có thể người dùng của bạn sẽ hạnh phúc hơn với nhiều tính năng hơn và một vài giờ ngừng hoạt động mỗi tháng nếu bạn xây dựng một khối nguyên khối đơn giản?

Tôi nghĩ rằng bạn nhìn thấy quan điểm của tôi. Thiết kế hệ thống không phải là đúng và sai, mà là lựa chọn từ rất nhiều sự đánh đổi. Tất cả mọi thứ sai đều có thể đúng và ngược lại, nếu bạn nhưng chỉ nhìn thấy nó trong bối cảnh phù hợp. Ngữ cảnh của bạn là duy nhất đối với bạn, vì vậy trong khi chúng tôi có thể cung cấp cho bạn một câu trả lời, nó sẽ không có các câu trả lời. Hãy nhớ đối tượng của bạn là ai, nhu cầu của họ là gì và thiết kế phù hợp sẽ tự tiết lộ.

1. Kiến trúc vi dịch vụ phù hợp với thiết kế hướng tên miền. Thông thường một MS đại diện cho một bối cảnh giới hạn.

Không đồng ý. DDD có xu hướng rất OO. một đơn đặt hàng được giao? Order.Deliver () trong khi các dịch vụ vi mô sẽ có DeliveryService.Deliver (order)

2. Nếu dịch vụ vi mô A yêu cầu chức năng cư trú trong dịch vụ vi mô B, mô hình của tôi có thể sai và A và B thực sự phải là một dịch vụ vi mô / BC.

Không đồng ý, bạn nên thử và giữ cho bạn các dịch vụ vi mô. chia chúng ra nhỏ hơn nữa!

3. Giao tiếp đồng bộ giữa các dịch vụ vi mô (yêu cầu HTTP trực tiếp) là không tốt, vì nó bất chấp mục đích của dịch vụ vi mô và giới thiệu khớp nối giữa các thành phần.

Không đồng ý. các dịch vụ không nên quan tâm đến việc ai đang gọi họ và người gọi không nên quan tâm rằng logic được triển khai trong một dịch vụ siêu nhỏ.

4. Giao tiếp không đồng bộ giữa các dịch vụ là mong muốn. Các dịch vụ nên xuất bản các sự kiện để xếp hàng tin nhắn, vì vậy các dịch vụ khác có thể đăng ký và xử lý một phần của sự kiện hoặc sử dụng nó để sao chép một phần dữ liệu cần thiết cho ngữ cảnh của chúng. Bằng cách này, các dịch vụ có thể xử lý các yêu cầu ngay cả các dịch vụ khác không hoạt động, điều này sẽ không xảy ra trong giao tiếp đồng bộ.

Hàng đợi là tốt. Nhưng lý luận của bạn là sai. sự khác biệt duy nhất giữa phản hồi đồng bộ hóa và không đồng bộ là bạn chờ đợi đồng bộ hóa. Bạn có thể thực hiện các cuộc gọi kiểu RPC với hàng đợi và nhiều nhân viên không có thăm dò.

5. Nếu dịch vụ vi mô A xuất bản sự kiện, dịch vụ vi mô B đăng ký sự kiện đó và tạo ra một sự kiện mới là kết quả, thì dịch vụ vi mô A không phải là sự kiện mới được xử lý, vì đó sẽ là một sự phụ thuộc vòng tròn. Trong trường hợp này, chúng tôi nên giới thiệu dịch vụ vi mô thứ ba hoặc kết hợp A và B vào dịch vụ vi mô AB.

Không đồng ý. Nó không phải là một phụ thuộc tròn vì các dịch vụ vi mô của bạn không được ghép nối. Ngoài ra, bạn muốn phục vụ cho việc gửi lại các kịch bản, SendEmail, EmailFails, SendAgain không cần 3 dịch vụ vi mô

6. Dịch vụ vi mô thực sự là một thuật ngữ sai lệch. Chúng ta nên cố gắng cho các bối cảnh nhỏ, nhưng đó không phải là trường hợp. Thuật ngữ không nên là "dịch vụ vi mô", mà là "đủ lớn để thực hiện dịch vụ công việc".

Không đồng ý. Kiểm tra các dịch vụ nano.

7. Các dịch vụ vi mô cho phép chúng tôi giới thiệu các chức năng mới dễ dàng hơn và không sợ rằng chúng tôi sẽ phá vỡ toàn bộ hệ thống. Nó có thể được thực hiện bằng cách giới thiệu một dịch vụ mới hoặc tái cấu trúc một trong những dịch vụ hiện có.

Không đồng ý. Có, bạn có thể tách rời, nhưng việc phối hợp các dịch vụ vi mô có thể gây khó khăn như bất kỳ dự án nguyên khối nào

8. Mỗi dịch vụ vi mô nên có lưu trữ dữ liệu riêng. Sao chép / sao chép dữ liệu là hành vi mong muốn trong kiến ​​trúc này.

Không đồng ý. Mặc dù bạn không nên chia sẻ lưu trữ, các dịch vụ vi mô của bạn sẽ cố gắng không trạng thái nếu có thể. không trùng lặp dữ liệu trừ khi nó xuất hiện

Kết luận của bạn là quy tắc tốt đẹp, nhưng không phổ quát. Sẽ có trường hợp khi lựa chọn tốt nhất là phá vỡ các quy tắc này, ngay cả trong một dự án sân xanh. Trong một số trường hợp giao tiếp đồng bộ là lựa chọn tốt nhất. Trong một số trường hợp, việc hợp nhất hai dịch vụ thành một ngay cả khi chúng được kết hợp bằng giao tiếp đồng bộ là không tốt.

Và đối với câu hỏi khác của bạn, không cần phải khám phá dịch vụ cho giao tiếp dựa trên hàng đợi.

Ừm, bạn chỉ đang nói về lập trình hướng đối tượng. Hoặc ít nhất, những gì ban đầu được hình thành là: các đoạn mã chạy độc lập giao tiếp với nhau bằng các tin nhắn.

Alan Kay quan niệm OOP được mô phỏng theo các hệ thống sinh học, trong đó các tế bào tương đối độc lập với nhau và chỉ giao tiếp qua các thông điệp cắm vào giao diện bên ngoài trên các tế bào khác.

Vậy tại sao chúng ta ngừng nghĩ về nó như OOP chỉ vì tất cả các đối tượng không chạy trên cùng một máy tính? Nếu bất cứ điều gì, điều đó thậm chí còn hướng đối tượng nhiều hơn so với nếu chúng trên cùng một máy tính và một phần của cùng một ứng dụng, bởi vì nếu tất cả các đối tượng trong cùng một ứng dụng, thì các nhà phát triển thường phá vỡ OOP bằng cách sử dụng các biến toàn cục được chia sẻ bởi tất cả các lớp và bao gồm các tiêu đề giống nhau trong mỗi tệp, v.v. Khi tất cả các đối tượng phụ thuộc vào cùng một nội dung, chúng không được gói gọn như thể chúng hoàn toàn độc lập với nhau và đóng gói là toàn bộ điểm của OOP.

Ví dụ, tất cả những gì được nói trong các câu trả lời khác là một tuyên bố trong sách giáo khoa về OOP.

Vì tôi thường gặp phải hiểu sai về một khái niệm quan trọng như Bounded Context và Core Domain, tôi muốn giải thích một chút về nó.

Tôi thấy nó cực kỳ có lợi khi nghĩ về các tên miền phụ về khả năng kinh doanh. Khả năng kinh doanh là điều mà tổ chức của bạn làm. Đây là một trong những chức năng kinh doanh của nó. Vì mục tiêu của chúng tôi là liên kết doanh nghiệp-CNTT , tôi chắc chắn muốn họ có mối quan hệ 1: 1 với các dịch vụ kỹ thuật của tôi .

Vì vậy, quá trình này đi xuống sau đây. Đầu tiên, tôi xác định khả năng kinh doanh cấp cao hơn. Nó nên ở dạng danh từ và động từ (hoặc một số hình thức phái sinh). Thường có ít hơn 10 khả năng kinh doanh. Sau đó, tôi mênh mông sâu hơn, xác định các khả năng lồng nhau. Và cứ thế, cho đến khi không còn gì để chia. Các khả năng mà bạn đã sử dụng phương pháp này phản ánh miền thực, cách thức tổ chức của bạn hoạt động. Các khả năng này sẽ được kết nối một cách lỏng lẻo, vì vậy nếu bạn ánh xạ các dịch vụ kỹ thuật của mình với các khả năng này, chúng sẽ tự động và điều khiển theo sự kiện. Quá trình này được gọi là ánh xạ khả năng kinh doanh , nhưng có nhiều cách khác để tìm dịch vụ của bạn, trong đó nổi bật nhất có lẽ là Phân tích chuỗi giá trị .

Dưới đây là một ví dụ về việc xác định ranh giới dịch vụ bằng cách sử dụng phương pháp này.