Phương pháp tiếp cận thành phần Microservice

Question

Tôi có một câu hỏi cho cộng đồng microservices. Tôi sẽ đưa ra một ví dụ từ lĩnh vực giáo dục nhưng nó áp dụng cho mọi kiến ​​trúc microservices.

Giả sử tôi có dịch vụ sinh viên và giấy phép-dịch vụ với yêu cầu kinh doanh là số lượng sinh viên bị giới hạn bởi giấy phép. Vì vậy, mỗi khi một sinh viên được tạo ra một kiểm tra cấp phép đã được thực hiện. Có nhiều loại giấy phép nên loại giấy phép sẽ phải được bao gồm trong hoạt động.

Câu hỏi của tôi là có cách tiếp cận bạn đã tìm thấy là tốt hơn trong thực tế:

1. Xây dựng một dịch vụ tổng hợp mà các cuộc gọi 2 dịch vụ
2. nối sinh viên phục vụ để cấp giấy phép dịch vụ để khi createStudent được gọi là sinh-dịch vụ thực hiện cuộc gọi đến cấp phép dịch vụ và chỉ khi điều đó hoàn thành các sinh viên sẽ được tạo
3. Sử dụng một kiến ​​trúc dựa trên sự kiện

peop le nói về kiến ​​trúc microservice giống như một đồ thị hơn một hệ thống phân cấp và tùy chọn 1 kinda biến nó thành một hệ thống phân cấp nơi bạn nhận được vật liệu tổng hợp ngày càng thô. Nhược điểm khác là nó tạo ra sự nhầm lẫn như những gì khách hàng dịch vụ thực sự nên sử dụng và có một số trùng lặp xảy ra vì API tổng hợp sẽ phải bao gồm tất cả các tham số cần thiết để gọi các dịch vụ hạ nguồn. Nó có một lợi ích lớn bởi vì nó mang đến cho bạn một nơi tự nhiên để thực hiện việc xử lý lỗi, biên đạo và xử lý sự nhất quán.

Lựa chọn 2 có vẻ như nó có nhược điểm quá:

• API cấp phép sẽ phải bị rò rỉ vào API sinh viên để bạn có thể chỉ định hạn chế cấp phép.

• nó đặt rất nhiều gánh nặng cho học sinh-dịch vụ bởi vì nó có để xử lý thống nhất trên tất cả các dịch vụ phụ thuộc

• như các dịch vụ khác cần phải phản ứng khi một sinh viên được tạo ra tôi có thể xem đồ thị phụ thuộc một cách nhanh chóng ngoài tầm kiểm soát và dịch vụ sẽ phải xử lý sự phức tạp đó ngoài việc điều khiển từ logic riêng của mình để quản lý sinh viên.

Lựa chọn 3 Trong khi được tách trời, tôi không thực sự nghĩ rằng sẽ làm việc vì đây là tất cả được kích hoạt từ một giao diện người dùng và mọi người không thực sự sử dụng để "đi làm cái gì khác cho đến khi học sinh mới này xuất hiện " tiếp cận.

Cảm ơn bạn cấp phép ứng

Answer 1

và tạo sinh viên là trực giao nên phương án 2 không có ý nghĩa.

Tùy chọn 1 hợp lý hơn nhưng tôi sẽ cố gắng không xây dựng một dịch vụ khác. Thay vào đó, tôi sẽ cố gắng "lọc" các cuộc gọi đến dịch vụ sinh viên thông qua phần mềm trung gian cấp phép.

Bằng cách này, bạn có thể sử dụng phần mềm trung gian này cho các cuộc gọi dịch vụ khác (ví dụ:dịch vụ lớp học) và các thay đổi trong API của cả cấp phép và sinh viên có thể được thực hiện độc lập vì những điều đó thực sự độc lập. Nó chỉ xảy ra rằng cấp phép đang sử dụng số lượng sinh viên nhưng điều này có thể dễ dàng thay đổi.

Tôi không chắc cách tùy chọn 3, phương pháp dựa trên sự kiện có thể trợ giúp tại đây. Nó có thể giải quyết vấn đề khác mặc dù.

Answer 2

IMHO, tôi sẽ đi với tùy chọn 2. Một vài điều cần xem xét. Nếu bạn mua đầy đủ vào SOA và hơn nữa các dịch vụ nhỏ, bạn không thể nao núng mỗi khi một dịch vụ cần liên hệ với một dịch vụ khác. Hãy thoải mái với điều đó .... hãy nhớ đó là vấn đề. Điều tôi thực sự thích về phương án 2 là một câu trả lời thành công cho sinh viên-dịch vụ không được gửi cho đến khi yêu cầu cấp phép thành công. Hãy coi dịch vụ giấy phép là bất kỳ dịch vụ bên ngoài nào khác, nơi bạn có thể bọc giấy phép-dịch vụ trong một đối tượng máy khách có thể được JAR giấy phép dịch vụ xuất bản.

• API cấp phép sẽ phải rò rỉ vào API sinh viên để bạn có thể chỉ định hạn chế cấp phép.

Có API cấp phép dịch vụ sẽ được sử dụng. Bạn có thể gọi nó là rò rỉ (ai đó phải sử dụng nó) hoặc đóng gói để khách hàng yêu cầu dịch vụ sinh viên không cần phải lo lắng về việc cấp phép.

• nó đặt rất nhiều gánh nặng cho học sinh-dịch vụ bởi vì nó có để xử lý thống nhất trên tất cả các dịch vụ phụ thuộc

Một số dịch vụ phải gánh vác gánh nặng này. Nhưng tôi sẽ quản lý nó một cách hữu cơ. Chúng tôi đang nói về 1 dịch vụ cần một dịch vụ khác. Nếu điều này phát triển và trở nên cụ thể rắc rối thì việc tái cấu trúc có thể được thực hiện. Nếu số lượng dịch vụ mà sinh viên dịch vụ yêu cầu tăng lên, tôi nghĩ rằng nó có thể được tái cấu trúc một cách thanh lịch và có thể dịch vụ sinh viên trở thành dịch vụ tổng hợp và các nhóm dịch vụ được sử dụng độc lập có thể được hợp nhất thành các dịch vụ mới nếu được yêu cầu. Nhưng nếu danh sách các dịch vụ phụ thuộc mà dịch vụ sinh viên sử dụng chỉ được sử dụng bởi dịch vụ sinh viên, thì tôi không biết liệu giá trị của nó có được nhóm chúng vào dịch vụ của riêng họ hay không. Tôi nghĩ thay vì gánh nặng và rò rỉ bạn có thể xem nó như là đóng gói và quyền sở hữu .... nơi mà sinh viên-dịch vụ là chủ sở hữu của gánh nặng đó để nó không cần phải rò rỉ cho các khách hàng/dịch vụ khác.

• vì nhiều dịch vụ hơn cần phản ứng khi sinh viên được tạo ra tôi có thể thấy biểu đồ phụ thuộc nhanh chóng vượt khỏi tầm kiểm soát và dịch vụ phải xử lý sự phức tạp đó ngoài logic.

Phương án thay thế sẽ là các dịch vụ tổng hợp khác nhau. Giống như phản ứng của tôi đối với điểm đạn trước đó, điều này có thể được giải quyết một cách tao nhã nếu nó là một vấn đề thực sự.

Nếu buộc mỗi tùy chọn của bạn có thể được chuyển thành giải pháp khả thi. Tôi đang đưa ra một trường hợp được đề xuất cho tùy chọn 2.

Answer 3

Tôi biết câu hỏi đã được hỏi một lúc trước đây, nhưng tôi nghĩ tôi có điều gì đó để nói rằng có thể có giá trị ở đây.
Trước hết, cách tiếp cận của bạn sẽ phụ thuộc vào kích thước tổng thể của sản phẩm cuối cùng của bạn. Tôi có xu hướng đi với một quy luật: nếu tôi có quá nhiều sự phụ thuộc giữa các dịch vụ vi mô riêng lẻ, tôi có xu hướng sử dụng cái gì đó sẽ đơn giản hóa và có thể loại bỏ những phụ thuộc này. Tôi không muốn kết thúc với một mạng nhện của các dịch vụ! Một điều tốt để xem xét ở đây là hàng đợi Tin nhắn, chẳng hạn như RabbitMQ chẳng hạn.
Tuy nhiên, nếu tôi chỉ có một vài dịch vụ nói chuyện với nhau, tôi sẽ chỉ yêu cầu họ gọi trực tiếp cho nhau, như bất kỳ giải pháp thay thế nào trong khi đơn giản hóa kiến ​​trúc, thêm một số tính toán và chi phí cơ sở hạ tầng.

Bất kỳ cách tiếp cận nào bạn sẽ quyết định thực hiện, hãy thiết kế các dịch vụ của bạn theo ý tưởng Hexagonal architecture! Điều này sẽ giúp bạn giải quyết vấn đề khi bạn quyết định chuyển từ giải pháp này sang giải pháp khác. Những gì tôi có xu hướng làm là thiết kế DAO của tôi là "bộ điều hợp", vì vậy một DAO gọi là Dịch vụ A sẽ gọi trực tiếp hoặc qua hàng đợi tin nhắn, độc lập với logic nghiệp vụ. Khi tôi cần thay đổi nó, tôi chỉ có thể thay đổi DAO này cho một cái khác, mà không cần phải chạm vào bất kỳ logic nghiệp vụ nào (vào cuối ngày logic nghiệp vụ không quan tâm đến cách nó lấy dữ liệu). Kiến trúc lục giác phù hợp thực sự tốt với dịch vụ vi mô, TDD và thử nghiệm hộp đen.

Answer 4

Tùy chọn 1 và 2 tạo khớp nối chặt chẽ cần tránh càng nhiều càng tốt vì bạn muốn dịch vụ của mình độc lập. Vì vậy, câu hỏi sẽ trở thành:

Làm cách nào để thực hiện điều này với kiến ​​trúc dựa trên sự kiện?

1. Sử dụng sự kiện để theo dõi thông tin cấp phép từ dịch vụ cấp phép trong dịch vụ sinh viên, thực tế là sao chép dữ liệu. Những hạn chế ở đây là: bạn chỉ có sự nhất quán cuối cùng khi sao chép dữ liệu là không đồng bộ.

2. Sử dụng các sự kiện không đồng bộ để kích hoạt chuỗi sự kiện và cuối cùng kích hoạt tạo sinh viên. Từ câu hỏi của bạn, có vẻ như bạn đã có ý tưởng, nhưng có một vấn đề đối phó với giao diện người dùng. Bạn có hai lựa chọn có thể ở đây: chờ sự kiện tạo (hoặc thất bại) của sinh viên với một lượng thời gian chờ nhỏ, hoặc (sự kiện tốt hơn), làm cho hệ thống của bạn phản ứng hoàn toàn (sử dụng cơ chế đẩy máy chủ-máy khách cho giao diện người dùng).