Trong một kiến ​​trúc microservice kết hợp lỏng lẻo, làm thế nào để bạn theo dõi các phụ thuộc của bạn?


9

Một lựa chọn kiến ​​trúc cấp cao phổ biến trong chương trình hiện đại là hệ thống microservice dựa trên REST. Điều này có một số lợi thế như khớp nối lỏng lẻo, dễ sử dụng lại, hạn chế về các công nghệ có thể được sử dụng, khả năng mở rộng cao, v.v.

Nhưng một trong những vấn đề tôi thấy trước trong một kiến ​​trúc như vậy là khả năng hiển thị kém về sự phụ thuộc của ứng dụng là gì. Ví dụ: giả sử tôi có một ứng dụng sử dụng một bộ lệnh gọi REST hàng ngày. Ứng dụng này cũng sử dụng một nhóm các cuộc gọi REST thứ hai, nhưng chỉ một lần một phần tư. Nếu tôi quét các bản ghi trong tuần qua, tôi sẽ thấy tất cả các cals hàng ngày, nhưng tôi có thể sẽ không thấy các cuộc gọi hàng quý. Khi đến lúc tái cấu trúc, các cuộc gọi hàng quý có nguy cơ bị phá vỡ cao.

Những mô hình hoặc công cụ nào có thể được sử dụng để giảm rủi ro này và cung cấp khả năng hiển thị lớn hơn vào những gì phụ thuộc của kiến ​​trúc ghép lỏng lẻo là gì?


1
Đây chính xác là lý do tại sao khớp nối lỏng lẻo có thể xấu. Khi không có phụ thuộc thời gian biên dịch, cách duy nhất để phát hiện lỗi và bạn không bao giờ bắt tất cả chúng, là sử dụng kiểm tra tự động. Giải pháp là một số loại thử nghiệm tự động, có thể bao gồm thử nghiệm đơn vị cũng như thử nghiệm tích hợp.
Frank Hileman

@FrankHileman Thử nghiệm rõ ràng là có ích, nhưng tôi thấy khó tin rằng đây là giải pháp duy nhất ngoài kia. Ngoài ra, có nhiều ngôn ngữ không có kiểm tra thời gian biên dịch (ví dụ: JS hoặc Python), vì vậy ngay cả khi có sự kết hợp chặt chẽ, bạn vẫn sẽ gặp vấn đề.
David nói Phục hồi lại

1
hệ thống kiểu tĩnh có thể bắt được số lượng lớn lỗi trong giai đoạn biên dịch. Theo tôi, sự bù đắp duy nhất cho việc thiếu một hệ thống như vậy là kiểm tra tự động. Phát hiện lỗi tĩnh thông qua bằng chứng tự động hoặc đơn giản là biên dịch sẽ luôn đáng tin cậy hơn các thử nghiệm.
Frank Hileman

Một cách khả thi có thể là triển khai ứng dụng khách API của từng dịch vụ một cách riêng biệt và bao gồm cả những khách hàng này như là các phụ thuộc của dự án. Với các máy khách API sẽ dễ dàng hơn trong việc theo dõi phiên bản dịch vụ nào chúng tôi đang tiêu thụ.
Laiv

@Laiv Tôi đặc biệt tò mò về các dịch vụ RESTful, vì vậy đó không thực sự là một tùy chọn vì bất kỳ ai cũng có thể gửi yêu cầu HTTP nhiều hơn hoặc ít hơn.
David nói Phục hồi lại

Câu trả lời:


4

Những mô hình hoặc công cụ nào có thể được sử dụng để giảm rủi ro này

Giữ API và khả năng kinh doanh của bạn tương thích ngược.

cung cấp tầm nhìn rõ hơn về những gì phụ thuộc của kiến ​​trúc ghép lỏng lẻo

Kiểm tra sức khỏe.

Dịch vụ của tôi là một khách hàng cho khả năng api hàng tháng của bạn. Nhưng dịch vụ của tôi là khách hàng của bạn bất cứ khi nào dịch vụ của tôi đang chạy. Vì vậy, dịch vụ của tôi thức dậy cứ sau 10 phút, hoặc bất cứ điều gì, kết nối với api hàng tháng của bạn và chạy giao thức để đảm bảo rằng khả năng dịch vụ của tôi cần vẫn khả dụng.

Vì vậy, nhật ký của bạn sẽ cho bạn thấy tần suất một số dịch vụ khác đang kiểm tra để xem rằng mỗi dịch vụ cụ thể bạn cung cấp vẫn có sẵn, giống như nó cho bạn thấy tần suất mỗi dịch vụ cụ thể bạn cung cấp thực sự được sử dụng.


1

Có ít nhất hai địa điểm nơi bạn có thể tìm thấy các phụ thuộc:

  • Cấu hình. Truy cập các API bên ngoài đòi hỏi phải biết một loạt thông tin về từng API đó. ID truy cập, khóa bí mật, điểm cuối. Tất cả điều này không thể có trong mã, bởi vì thông tin như vậy sẽ thay đổi. Ví dụ, gần đây tôi đã bắt đầu chuyển tất cả các dịch vụ siêu nhỏ của mình sang SSL. Điều này có nghĩa là mọi dịch vụ dựa trên dịch vụ được di chuyển nên được cấu hình lại để trỏ đến https://phiên bản thay vì http://. Tôi rất vui vì các điểm cuối nằm trong cấu hình thay vì được mã hóa cứng.

  • Giao diện. Bạn không truy cập dịch vụ trực tiếp từ mã của mình, vì phiên bản API sẽ thay đổi và thậm chí bạn có thể quyết định chuyển sang một API khác. Thay vào đó, bạn tạo một lớp trừu tượng và sử dụng sự phụ thuộc thông qua một giao diện. Bằng cách tuân theo logic thông thường khi tạo các giao diện đó, bạn có thể làm cho cuộc sống của mình dễ dàng hơn sau này khi tìm kiếm các phụ thuộc.

Khi đến lúc tái cấu trúc, các cuộc gọi hàng quý có nguy cơ bị phá vỡ cao.

Đây là những gì kiểm tra hồi quy là cho.

Bạn không thể chỉ nhìn vào mã, thay đổi nó và tin tưởng bản thân rằng không có gì bị phá vỡ. Điều này sẽ không hoạt động trong một kiến ​​trúc microservice. Điều này sẽ không hoạt động trong một ứng dụng nguyên khối. Trình biên dịch có thể bắt được một số lỗi bạn sẽ giới thiệu khi sửa đổi mã. Trong một số ngôn ngữ, chẳng hạn như Haskell, trình biên dịch có thể rất có khả năng và bắt được hầu hết các lỗi; trình biên dịch cho các ngôn ngữ chính, tuy nhiên, sẽ không làm được gì nhiều cho bạn. Nếu bạn không có bài kiểm tra, bạn sẽ bị lừa. Sự hiện diện của microservice là không liên quan.


-2

API REST được chỉ định một cách lỏng lẻo nên đôi khi có thể hữu ích khi chuyển sang gRPC, google protobufs hoặc Thrift để xác định giao diện RPC và sau đó phiên bản nó.


2
Điều này có thể tốt hơn như một bình luận ... nhưng thành thật mà nói điều này không giải thích nhiều.
David nói Phục hồi Monica

Đủ công bằng. API còn lại không có phụ thuộc thời gian biên dịch cụ thể vào dịch vụ khác vì liên kết giữa hai chỉ là một cuộc gọi nghỉ HTTP, một cái gì đó giống như máy chủ lưu trữ và đường dẫn. Với gRPC hoặc Protobuf hoặc Thrift, một giao diện được xác định được sử dụng để tạo mã. Mã được tạo được biên dịch và phiên bản, và sau đó (các) dịch vụ của bạn được xây dựng dựa trên các giao diện đó. Kết quả là mỗi dịch vụ rõ ràng phụ thuộc vào một hoặc nhiều giao diện dịch vụ khác của bạn. Hy vọng rằng làm rõ câu trả lời của tôi!
Patrick
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.