Làm cách nào để phù hợp với công cụ quy tắc trong kiến ​​trúc microservice khi nó yêu cầu nhiều dữ liệu đầu vào?

Tình hình hiện tại

Chúng tôi đang triển khai (và hiện đang duy trì) một ứng dụng web mua sắm trực tuyến trong kiến ​​trúc microservice.

Một trong những yêu cầu là doanh nghiệp phải có khả năng áp dụng các quy tắc về những gì khách hàng của chúng tôi thêm vào giỏ hàng của họ, để tùy chỉnh trải nghiệm của họ và thứ tự cuối cùng. Rõ ràng, một công cụ quy tắc kinh doanh phải được đưa ra và chúng tôi đã triển khai một "microservice" cụ thể cho việc này (nếu chúng tôi vẫn có thể gọi nó như vậy).

Trong suốt một năm, công cụ quy tắc này ngày càng phức tạp hơn, đòi hỏi ngày càng nhiều dữ liệu (ví dụ: nội dung của giỏ hàng mà còn thông tin người dùng, vai trò của anh ấy, dịch vụ hiện tại của anh ấy, một số thông tin thanh toán, v.v.) để có thể tính các quy tắc đó.

Hiện tại, shopping-cartmicroservice của chúng tôi đang thu thập tất cả dữ liệu này từ các dịch vụ siêu nhỏ khác. Mặc dù một phần của dữ liệu này được sử dụng bởi shopping-cart, phần lớn thời gian nó chủ yếu được sử dụng để cung cấp cho công cụ quy tắc.

Yêu cầu mới

Bây giờ cần đến các ứng dụng / dịch vụ siêu nhỏ khác để sử dụng lại công cụ quy tắc cho các yêu cầu tương tự. Do đó, trong tình huống hiện tại, họ sẽ phải truyền cùng loại dữ liệu, gọi cùng một dịch vụ siêu nhỏ và xây dựng (gần như) cùng một tài nguyên để có thể gọi công cụ quy tắc.

Tiếp tục như vậy, chúng tôi sẽ phải đối mặt với một số vấn đề:

• mọi người (gọi công cụ quy tắc) phải thực hiện lại việc tìm nạp dữ liệu, ngay cả khi họ không cần nó cho chính mình;
• các yêu cầu cho công cụ quy tắc là phức tạp;
• Tiếp tục theo hướng này, chúng tôi sẽ phải vận chuyển dữ liệu này trên toàn mạng cho nhiều yêu cầu (nghĩ đến việc gọi A gọi B là công cụ quy tắc, nhưng A đã có một số dữ liệu mà công cụ quy tắc cần);
• shopping-cart đã trở nên rất lớn do tất cả các dữ liệu tìm nạp;
• Có lẽ tôi đã quên rất nhiều

Chúng ta có thể làm gì để tránh những rắc rối này?

Lý tưởng nhất, chúng tôi sẽ tránh thêm sự phức tạp hơn cho công cụ quy tắc. Chúng tôi cũng phải đảm bảo rằng nó không trở thành nút cổ chai - ví dụ: một số dữ liệu khá chậm để tìm nạp (10 giây hoặc thậm chí nhiều hơn) để chúng tôi triển khai tìm nạp trước shopping-cartsao cho dữ liệu có nhiều khả năng ở đó trước khi chúng tôi gọi các quy tắc động cơ, và giữ một trải nghiệm người dùng chấp nhận được.

Một vài ý tưởng

1. Hãy để công cụ quy tắc lấy dữ liệu cần thiết. Điều này sẽ làm tăng thêm sự phức tạp của nó, vi phạm nguyên tắc trách nhiệm duy nhất ( thậm chí nhiều hơn nữa );
2. Triển khai proxy trước công cụ quy tắc để tìm nạp dữ liệu;
3. Triển khai một "trình tải dữ liệu" mà công cụ quy tắc gọi để tìm nạp tất cả dữ liệu cần thiết cùng một lúc (truy vấn tổng hợp).

Chúng ta hãy lùi lại một giây và đánh giá nơi bắt đầu của chúng tôi trước khi viết ra câu trả lời có độ dài tiểu thuyết này. Bạn có:

• Một khối lớn (công cụ quy tắc)
• Một lượng lớn dữ liệu không được mô đun hóa được gửi đi hàng loạt
• Thật khó để có được dữ liệu đến và từ công cụ quy tắc
• Bạn không thể loại bỏ công cụ quy tắc

Ok, điều này không phải là tuyệt vời cho microservice. Một vấn đề rõ ràng ngay lập tức là các bạn dường như đang hiểu nhầm microservice là gì.

mọi người (gọi công cụ quy tắc) phải thực hiện lại việc tìm nạp dữ liệu, ngay cả khi họ không cần nó cho chính mình;

Bạn cần xác định một số loại API hoặc phương thức giao tiếp mà microservice của bạn sử dụng và có phổ biến. Đây có thể là một thư viện tất cả trong số họ có thể nhập khẩu. Nó có thể được xác định một giao thức tin nhắn. Nó có thể đang sử dụng một công cụ hiện có ( tìm các bus tin nhắn microservice làm nơi khởi đầu tốt).

Câu hỏi về giao tiếp liên dịch vụ không phải là vấn đề "được giải quyết", nhưng nó cũng không phải là vấn đề "tự mình làm". Rất nhiều công cụ và chiến lược hiện có có thể làm cho cuộc sống của bạn trở nên dễ dàng hơn.

Bất kể bạn làm gì, hãy chọn một hệ thống duy nhất và cố gắng điều chỉnh API giao tiếp của bạn để sử dụng API này. Nếu không có một cách xác định để các dịch vụ của bạn tương tác, bạn sẽ có tất cả các nhược điểm của microservice và các dịch vụ nguyên khối và không có ưu điểm nào của một trong hai.

Hầu hết các vấn đề của bạn bắt nguồn từ điều này.

các yêu cầu cho công cụ quy tắc là phức tạp;

Làm cho chúng ít phức tạp hơn.

Tìm cách để làm cho chúng ít phức tạp hơn. Nghiêm túc. Các kiểu dữ liệu thông thường, chia công cụ quy tắc đơn của bạn thành các quy tắc nhỏ hơn hoặc một cái gì đó. Làm cho công cụ quy tắc của bạn làm việc tốt hơn. Đừng thực hiện phương pháp "kẹt mọi thứ vào truy vấn và cứ tiếp tục làm cho chúng phức tạp" - nghiêm túc nhìn vào những gì bạn đang làm và tại sao.

Xác định một số loại giao thức cho dữ liệu của bạn. Tôi đoán là các bạn không có kế hoạch API được xác định (theo như trên) và đã bắt đầu viết các cuộc gọi REST ad hoc bất cứ khi nào cần. Điều này ngày càng phức tạp khi bạn phải duy trì mọi dịch vụ siêu nhỏ mỗi khi có gì đó được cập nhật.

Tốt hơn nữa, bạn không chính xác là công ty đầu tiên thực hiện một công cụ mua sắm trực tuyến. Đi nghiên cứu các công ty khác.

Giờ thì sao...

Sau này, bạn ít nhất đã xử lý một số vấn đề lớn nhất.

Vấn đề tiếp theo là câu hỏi này của công cụ quy tắc của bạn. Tôi hy vọng rằng điều này là không hợp lý, để bạn có thể mở rộng nó. Nếu đúng như vậy, trong khi dưới mức tối thiểu, ít nhất bạn sẽ không chết trong ánh hào quang rực rỡ hoặc xây dựng những cách giải quyết điên rồ.

Bạn muốn công cụ quy tắc của bạn là không quốc tịch. Làm cho nó sao cho nó chỉ xử lý dữ liệu. Nếu bạn thấy nó là một nút cổ chai, hãy làm cho nó để bạn có thể chạy một số phía sau một bộ cân bằng proxy / tải. Không lý tưởng, nhưng vẫn khả thi.

Dành thời gian xem xét liệu có bất kỳ dịch vụ siêu nhỏ nào của bạn thực sự nên được đưa vào công cụ quy tắc của bạn hay không. Nếu bạn đang tăng chi phí hệ thống của mình một cách đáng kể chỉ để đạt được "kiến trúc microservice", bạn cần dành nhiều thời gian hơn để lên kế hoạch này.

Ngoài ra, công cụ quy tắc của bạn có thể được chia thành từng mảnh? Bạn có thể nhận được lợi nhuận chỉ bằng cách tạo ra các phần của dịch vụ cụ thể quy tắc của bạn.

Chúng tôi cũng phải đảm bảo rằng nó không trở thành nút cổ chai - ví dụ: một số dữ liệu khá chậm để tìm nạp (10 giây hoặc thậm chí nhiều hơn)

Giả sử vấn đề này tồn tại sau khi giải quyết các vấn đề trên, bạn cần nghiêm túc điều tra lý do tại sao điều này xảy ra. Bạn gặp ác mộng nhưng thay vì tìm hiểu tại sao (10 giây? Để gửi dữ liệu cổng mua sắm xung quanh? Hãy gọi tôi là hoài nghi, nhưng điều này có vẻ hơi vô lý) bạn dường như đang vá các triệu chứng thay vì nhìn vào vấn đề gây ra các triệu chứng trong nơi đầu tiên

Bạn đã sử dụng cụm từ "tìm nạp dữ liệu" nhiều lần. Là dữ liệu này trong một cơ sở dữ liệu? Nếu không, hãy cân nhắc thực hiện việc này - nếu bạn đang dành quá nhiều thời gian để "tìm nạp" dữ liệu theo cách thủ công thì có vẻ như sử dụng cơ sở dữ liệu thực sự sẽ là một ý tưởng tốt.

Bạn có thể có một thiết kế với cơ sở dữ liệu cho dữ liệu bạn tìm nạp (tùy thuộc vào mục đích này, bạn đã đề cập đến nó nhiều lần), một vài công cụ quy tắc và (các) khách hàng của bạn.

Một lưu ý cuối cùng là bạn muốn đảm bảo rằng bạn sử dụng phiên bản API và dịch vụ phù hợp. Một bản phát hành nhỏ không nên phá vỡ tính tương thích ngược. Nếu bạn thấy mình phát hành tất cả các dịch vụ của mình cùng một lúc để chúng hoạt động, bạn không có kiến ​​trúc microservice, bạn có kiến ​​trúc nguyên khối phân tán.

Và cuối cùng, microservice không phải là giải pháp một kích cỡ phù hợp cho tất cả. Xin vui lòng, vì tất cả những gì là thánh, đừng làm điều đó bởi vì đó là điều mới mẻ.

Với lượng thông tin được trình bày về công cụ quy tắc và đầu vào và đầu ra của nó, tôi nghĩ rằng đề xuất của bạn là không. 2 là đi đúng hướng.

Người tiêu dùng hiện tại của công cụ quy tắc có thể thuê ngoài quy trình thu thập thông tin cần thiết cho một thành phần mục đích đặc biệt hơn.

Ví dụ: Bạn hiện đang sử dụng công cụ quy tắc để tính toán giảm giá cần được áp dụng cho nội dung của giỏ hàng. Mua trước, địa lý và các yếu tố cung cấp hiện tại vào nó.

Yêu cầu mới là sử dụng nhiều thông tin tương tự để cung cấp e-mail cho các khách hàng trước dựa trên các ưu đãi đặc biệt sắp tới và các lần mua trước. Mua trước, cung cấp hiện tại và sắp tới yếu tố vào nó.

Tôi có hai dịch vụ riêng biệt cho việc này. Mỗi người sẽ dựa vào dịch vụ động cơ quy tắc cho một số công việc nặng nhọc của nó. Mỗi người trong số họ sẽ thu thập dữ liệu cần thiết cho yêu cầu của họ cho công cụ quy tắc.

Công cụ quy tắc chỉ áp dụng quy tắc, người tiêu dùng không cần lo lắng về dữ liệu chính xác mà công cụ quy tắc cần cho bối cảnh cụ thể và các dịch vụ trung gian mới này chỉ thực hiện một điều: Lắp ráp bối cảnh và chuyển yêu cầu đến công cụ quy tắc và trả về phản hồi không thay đổi.

Tổng hợp dữ liệu cần thiết cho quyết định nên được thực hiện bên ngoài công cụ quy tắc. Điều này là do chúng được thiết kế tốt nhất như các dịch vụ phi trạng thái khi có thể. Tìm nạp dữ liệu nhất thiết liên quan đến xử lý không đồng bộ và giữ trạng thái. Sẽ không có vấn đề gì nếu việc tìm nạp được thực hiện bởi một proxy đứng trước dịch vụ quyết định, bởi người gọi hoặc bởi một quy trình kinh doanh.

Là một vấn đề thực tế để triển khai, tôi sẽ đề cập rằng Trình quản lý quyết định hoạt động của IBM đang bắt đầu lập tài liệu và đã hỗ trợ việc sử dụng sản phẩm trong các thùng chứa docker . Tôi chắc chắn rằng các sản phẩm khác cũng cung cấp hỗ trợ này và nó sẽ trở thành chủ đạo.

Theo suy nghĩ đơn giản của tôi, tôi đoán, nó sẽ giúp tìm nạp trước tất cả dữ liệu cần thiết bằng cách thực hiện một bộ các cuộc gọi không đồng bộ đến các dịch vụ truy xuất dữ liệu ngay khi khách hàng bắt đầu mua và lưu trữ dữ liệu. Vì vậy, khi bạn phải gọi dịch vụ quy tắc, dữ liệu đã có sẵn. Và tiếp tục có sẵn cho các dịch vụ khác trong phiên.