Logic kinh doanh nên ngồi ở đâu trong kiến ​​trúc microservice?

Vẫn đang cố gắng xoay quanh kiến ​​trúc microservice vì tôi đã quen với cách tiếp cận nguyên khối

Giả sử chúng tôi cố gắng xây dựng một hệ thống đặt phòng Uber cực kỳ đơn giản . Để đơn giản hóa những điều chúng ta giả sử chúng ta có 3 dịch vụ và một api cửa ngõ cho các khách hàng: Booking, Drivers, Notificationvà chúng tôi có công việc sau đây:

Khi tạo đặt phòng mới:

1. Kiểm tra xem người dùng hiện tại đã có đặt chỗ chưa
2. Nhận danh sách các trình điều khiển có sẵn
3. Gửi thông báo cho các tài xế để nhận đặt phòng
4. Tài xế chọn đặt phòng

Giả sử tất cả nhắn tin được thực hiện thông qua một cuộc gọi http thay vì một xe buýt nhắn tin như kafka để mọi thứ đơn giản.

Vì vậy, trong trường hợp này, tôi nghĩ rằng Bookingdịch vụ có thể thực hiện việc kiểm tra đặt chỗ hiện tại. Nhưng sau đó ai sẽ nhận được danh sách các trình điều khiển có sẵn và thông báo? Tôi đang nghĩ đến việc thực hiện nó ở cấp độ cổng nhưng bây giờ logic được chia thành hai nơi:

• Gateway - nhận danh sách các trình điều khiển có sẵn + gửi thông báo
• Booking - kiểm tra đặt phòng hiện có

Và tôi khá chắc chắn rằng cổng không phải là nơi thích hợp để làm điều đó nhưng tôi cảm thấy nếu chúng ta làm điều đó trong Bookingdịch vụ, nó có trở nên gắn kết chặt chẽ không?

Để làm cho nó phức tạp hơn, điều gì xảy ra nếu chúng ta có một dự án khác muốn sử dụng lại hệ thống đặt phòng nhưng với logic kinh doanh riêng của nó trên đầu trang? Đó là lý do tại sao tôi nghĩ làm việc đó ở cấp độ cổng để cổng dự án mới có thể có logic kinh doanh riêng tách biệt với logic hiện có.

Một cách khác để làm điều đó tôi cho rằng mỗi dự án đều có dịch vụ đặt phòng riêng sẽ nói chuyện với dịch vụ đặt phòng cốt lõi nhưng tôi không chắc cách tiếp cận tốt nhất ở đây là :-)

Mọi người thường nghe "dịch vụ vi mô" và nghĩ "dịch vụ nano" và điều này có thể gây ra một số nhầm lẫn. Đây là các dịch vụ vi mô , vì vậy bạn không cần một dịch vụ riêng cho mỗi thực thể. Tất cả mọi thứ bạn đang cố gắng làm nên có trong bookingvà notificationdịch vụ. Bạn không cần driverdịch vụ (cho bất kỳ hoạt động nào bạn mô tả).

Nhận một danh sách các trình điều khiển có sẵn để đặt rơi vào bookingdịch vụ. Một cạm bẫy phổ biến là không nhóm các hoạt động liên quan vào cùng một dịch vụ, điều này được gọi là sự gắn kết thấp và nó rất tệ. Hãy nhớ rằng, bạn nhóm các thứ vào một dịch vụ theo miền vấn đề, không phải theo thực thể.

Bây giờ, như để tái sử dụng, lợi thế của việc có một dịch vụ vi mô riêng biệt, giờ đây bạn có thể có ba nhóm riêng biệt làm cho người tiêu dùng phải đối mặt với các ứng dụng. Một nhóm cho ứng dụng web html tiêu chuẩn, ứng dụng Android và ứng dụng ios. Tất cả các ứng dụng khác nhau này có thể được xây dựng hoàn toàn khác nhau và trông phù hợp với nền tảng cụ thể của chúng (không lặp lại mã). Các bookingmã dịch vụ được tái sử dụng bởi tất cả ba trong số những ứng dụng, bởi vì tất cả ba ứng dụng thực hiện cuộc gọi http với dịch vụ thay vì có mã đặt phòng riêng của họ.

Một luồng đặt phòng điển hình sẽ như thế này:

1. Ứng dụng android gọi bookingdịch vụ để nhận danh sách các trình điều khiển khả dụng
2. Dịch vụ đặt phòng trả về danh sách các trình điều khiển cho ứng dụng
3. Sau đó, người dùng chọn trình điều khiển của họ và ứng dụng gọi phương thức "sách" của bookingdịch vụ
4. Các bookingdịch vụ dịch vụ gọi là notificationdịch vụ với các chi tiết đặt phòng
5. Các notificationdịch vụ sẽ gửi một thông báo cho người lái xe, thông báo cho họ các đặt phòng
6. Ứng dụng trình điều khiển gửi tin nhắn đến notificationdịch vụ khi họ ở trong phạm vi một dặm của khách hàng
7. Các notificationdịch vụ sẽ gửi cảnh báo với khách hàng rằng tài xế của họ là gần như có

Hy vọng điều này sẽ giúp; hãy nhớ rằng, chúng là các dịch vụ vi mô, không phải dịch vụ nano, đừng cố phân chia cùng một miền vấn đề. Vì vậy, để trả lời tiêu đề của câu hỏi của bạn, khi bạn giữ một dịch vụ vi mô có kích thước phù hợp, tất cả hoặc hầu hết, logic nghiệp vụ cho miền vấn đề đó có thể nằm trong dịch vụ vi mô đó.

Tất cả phụ thuộc vào yêu cầu chính xác của bạn.

Giả sử bạn có hai ứng dụng khi đặt phòng:

1. Trường hợp đầu tiên: Một ứng dụng có thể cho phép một người dùng đặt nhiều lần, ứng dụng khác chỉ cho phép một người dùng. Điều này có nghĩa là hạn chế đặt phòng ở cấp ứng dụng, vì vậy bạn có hai điểm nhập cảnh trong hệ thống đặt phòng của mình (một điểm cho phép đặt nhiều, một điểm không) hoặc bạn chỉ cần kiểm tra xem trong các dịch vụ siêu nhỏ có liên quan ứng dụng.
2. Trường hợp thứ hai: đó là một phần định nghĩa của "Đặt chỗ" rằng người dùng không thể có nhiều ứng dụng cho dù ứng dụng là gì, quy tắc này đúng với toàn bộ hệ thống: điều này có nghĩa là bạn có thể đặt séc vào microservice đặt chỗ.

Đối với hệ thống thông báo, bạn có thể có các dịch vụ siêu nhỏ liên quan đến dịch vụ đặt phòng của bạn để lắng nghe bất kỳ đặt phòng mới nào. Do đó, microservice đặt phòng sẽ thông báo cho tất cả các thuê bao và họ sẽ hành động tương ứng.

Vấn đề duy nhất trong kiểu kiến ​​trúc này là điều gì xảy ra nếu có lỗi xảy ra sau khi thông báo được công bố, vì hai dịch vụ siêu nhỏ không hoạt động giống như hai hàm thực thi trong cùng một giao dịch cơ sở dữ liệu, bạn sẽ cần xử lý lỗi một cách duyên dáng và cuối cùng phát lại các quy trình đã thất bại (tự động hoặc thủ công)

Câu trả lời đơn giản là các khách hàng của microservice là những người quản lý logic kinh doanh trong kiến ​​trúc microservice 'thuần túy'. Để dễ hiểu hơn, hãy xem xét một ví dụ thậm chí đơn giản hơn. Một dịch vụ chỉ trả về các luồng byte dựa trên URI. Chính nó, nó không hữu ích lắm. Không có cách nào đó biết URI nào có những gì trong đó, bạn chỉ có thể đoán nơi để kéo mọi thứ. Bây giờ giả sử bạn có một dịch vụ siêu nhỏ khác nhau cung cấp khả năng tìm kiếm. Bạn gửi một yêu cầu với một chuỗi truy vấn và nó trả về các URI. Bây giờ mọi thứ trở nên thú vị hơn. Tôi có thể đặt các tham chiếu đến URI cho dịch vụ đầu tiên vào một chỉ mục.

Tuy nhiên, chúng ta cần phối hợp giữa hai thứ này. Có một câu trả lời đơn giản: bạn sử dụng trình duyệt để truy xuất URI từ dịch vụ chỉ mục và sau đó truy xuất dữ liệu từ dịch vụ dữ liệu. Cả hai dịch vụ đều 'không biết' về dịch vụ kia và hoàn toàn không có sự kết hợp nào giữa chúng. Tôi có thể sử dụng dịch vụ chỉ mục với bất kỳ dịch vụ dữ liệu nào khác và ngược lại.

Không nhất thiết là đây là cách tiếp cận tốt nhất trong tất cả các kịch bản nhưng có nhiều lợi ích khi xây dựng mọi thứ theo cách này đặc biệt là có thể sử dụng lại trong các tình huống hiện chưa được biết đến.