🥇Các trường hợp sử dụng lưới dịch vụ

Ghi chú. bản dịch.: Tác giả của bài viết này (Luc Perkins) là người ủng hộ nhà phát triển tại tổ chức CNCF, nơi có các dự án Nguồn mở như Linkerd, SMI (Service Mesh Interface) và Kuma (nhân tiện, bạn có thắc mắc tại sao Istio lại như vậy không? không có trong danh sách này?). Một lần nữa cố gắng giúp cộng đồng DevOps hiểu rõ hơn về xu hướng cường điệu thời thượng được gọi là "lưới dịch vụ", anh liệt kê 16 khả năng đặc trưng mà các giải pháp như vậy cung cấp.

Hôm nay lưới dịch vụ ― một trong những chủ đề nóng nhất trong lĩnh vực công nghệ phần mềm (và đúng như vậy!). Tôi nghĩ rằng công nghệ này cực kỳ hứa hẹn và muốn thấy nó được áp dụng rộng rãi (tất nhiên là khi nó có ý nghĩa). Tuy nhiên, nó vẫn được bao quanh bởi một bầu không khí bí ẩn đối với hầu hết mọi người. Đồng thời, ngay cả những người nổi tiếng với nó, thường rất khó để hình thành những ưu điểm của nó và chính xác nó là gì (thực sự bao gồm cả của bạn). Trong bài viết này, tôi sẽ cố gắng khắc phục tình trạng này bằng cách liệt kê nhiều trường hợp sử dụng "mạng lưới dịch vụ"*.

* Ghi chú dịch: ở đây và hơn thế nữa trong bài viết chính xác bản dịch này (“lưới dịch vụ”) sẽ được sử dụng cho lưới dịch vụ thuật ngữ vẫn còn mới.

Nhưng trước tiên tôi muốn đưa ra một vài nhận xét:

Tôi chưa bao giờ làm việc với các lưới dịch vụ hoặc sử dụng chúng ngoài các dự án bắt đầu cho quá trình học tập của chính tôi. Mặt khác, tôi là người đã viết rất nhiều tài liệu cho lưới dịch vụ nội bộ của Twitter vào năm 2015 (khi đó nó thậm chí còn chưa được gọi là "lưới dịch vụ") và tham gia phát triển trang web cũng như tài liệu cho liên kết, vậy điều đó có nghĩa gì đó.
Danh sách của tôi là gần đúng và không đầy đủ. Có thể có những trường hợp sử dụng mà tôi chưa biết và các tùy chọn mới có thể sẽ xuất hiện theo thời gian khi công nghệ phát triển và mức độ phổ biến của nó ngày càng tăng.
Đồng thời, không phải mọi triển khai lưới dịch vụ hiện có đều hỗ trợ tất cả các trường hợp sử dụng được liệt kê. Do đó, những phát biểu của tôi như “lưới dịch vụ có thể…” nên được đọc là “riêng lẻ và có lẽ tất cả việc triển khai lưới dịch vụ phổ biến đều có thể…”.
Thứ tự của các ví dụ không tạo nên sự khác biệt nào.

Danh sách ngắn:

khám phá dịch vụ;
mã hóa;
xác thực và ủy quyền;
cân bằng tải;
ngắt mạch;
tự động tính toán;
triển khai chim hoàng yến;
triển khai xanh-xanh;
kiểm tra sức khỏe;
sa thải tải;
phản chiếu giao thông;
vật liệu cách nhiệt;
giới hạn tốc độ yêu cầu, thử lại và hết thời gian chờ;
từ xa;
kiểm toán;
hình dung.

1. Khám phá dịch vụ

TL;DR: Kết nối với các dịch vụ khác trên mạng bằng tên đơn giản.

Các dịch vụ phải có khả năng tự động “tìm” nhau bằng cách sử dụng tên đầy đủ - ví dụ: service.api.production, pets/staging hoặc cassandra. Môi trường đám mây có tính co giãn và một tên duy nhất có thể ẩn nhiều phiên bản của một dịch vụ. Rõ ràng là trong tình huống như vậy về mặt vật lý thì không thể mã hóa cứng tất cả các địa chỉ IP.

Ngoài ra, khi một dịch vụ tìm thấy một dịch vụ khác, nó sẽ có thể gửi yêu cầu đến dịch vụ đó mà không sợ rằng chúng sẽ kết thúc ở đầu vào của phiên bản bị hỏng. Nói cách khác, lưới dịch vụ phải theo dõi tình trạng của tất cả các phiên bản dịch vụ và giữ cho danh sách máy chủ được cập nhật nhất có thể.

Mỗi lưới dịch vụ thực hiện cơ chế khám phá dịch vụ khác nhau. Hiện tại, cách phổ biến nhất là ủy quyền cho các quy trình bên ngoài như Kubernetes DNS. Trước đây trên Twitter chúng tôi đã sử dụng hệ thống đặt tên cho mục đích này tài chính. Ngoài ra, công nghệ lưới dịch vụ giúp xuất hiện các cơ chế đặt tên tùy chỉnh (mặc dù tôi chưa thấy bất kỳ triển khai SM nào có chức năng như vậy).

2. Mã hóa

TL;DR: Loại bỏ lưu lượng không được mã hóa giữa các dịch vụ và làm cho quá trình này trở nên tự động và có thể mở rộng.

Thật vui khi biết rằng những kẻ tấn công không thể xâm nhập vào mạng nội bộ của bạn. Tường lửa làm rất tốt công việc này. Nhưng điều gì sẽ xảy ra nếu một hacker đột nhập được vào bên trong? Liệu anh ta có thể làm bất cứ điều gì mình muốn với lưu lượng truy cập nội bộ dịch vụ không? Hãy hy vọng điều này không xảy ra sau cùng. Để ngăn chặn tình huống này, bạn nên triển khai mạng không tin cậy trong đó tất cả lưu lượng truy cập giữa các dịch vụ đều được mã hóa. Hầu hết các lưới dịch vụ hiện đại đều đạt được điều này thông qua TLS (TLS lẫn nhau, mTLS). Trong một số trường hợp, mTLS hoạt động trong toàn bộ đám mây và cụm (tôi nghĩ rằng một ngày nào đó liên lạc giữa các hành tinh sẽ được sắp xếp tương tự).

Tất nhiên, đối với lưới dịch vụ mTLS không bắt buộc. Mỗi dịch vụ có thể xử lý TLS riêng, nhưng điều này có nghĩa là bạn sẽ cần tìm cách tạo chứng chỉ, phân phối chúng trên các máy chủ dịch vụ và đưa mã vào ứng dụng sẽ tải các chứng chỉ này từ tệp. Có, đừng quên gia hạn các chứng chỉ này theo định kỳ. Lưới dịch vụ tự động hóa mTLS với các hệ thống như TUYỆT VỜI, từ đó, tự động hóa quá trình cấp và luân chuyển chứng chỉ.

3. Xác thực và ủy quyền

TL;DR: Xác định người yêu cầu là ai và xác định những gì họ được phép làm trước khi yêu cầu đến được dịch vụ.

Dịch vụ thường muốn biết ai thực hiện yêu cầu (xác thực) và sử dụng thông tin này để quyết định mà một thực thể nhất định được phép thực hiện (ủy quyền). Trong trường hợp này, đại từ “ai” có thể ẩn:

Các dịch vụ khác. Đây được gọi là "xác thực" ngang nhau" Ví dụ, dịch vụ web muốn truy cập dịch vụ db. Các lưới dịch vụ thường giải quyết các vấn đề như vậy bằng cách sử dụng mTLS: chứng chỉ trong trường hợp này đóng vai trò là mã định danh cần thiết.
Một số người dùng con người. Đây được gọi là "xác thực" lời yêu cầu" Ví dụ, người dùng haxor69 muốn mua một chiếc đèn mới. Lưới dịch vụ cung cấp nhiều cơ chế khác nhau, ví dụ: Mã thông báo web JSON.
Nhiều người trong chúng tôi đã làm điều này trong mã ứng dụng. Một yêu cầu đến, chúng tôi nhìn qua bảng users, tìm người dùng và so sánh mật khẩu, sau đó kiểm tra cột permissions vân vân. Trong trường hợp lưới dịch vụ, điều này xảy ra trước khi yêu cầu đến được dịch vụ.

Sau khi xác định được yêu cầu đến từ ai, chúng tôi cần xác định thực thể này được phép làm gì. Một số lưới dịch vụ cho phép bạn đặt các chính sách cơ bản (về ai có thể làm gì) dưới dạng tệp YAML hoặc trên dòng lệnh, trong khi các lưới dịch vụ khác cung cấp khả năng tích hợp với các khung như Đại lý chính sách mở. Mục tiêu cuối cùng là để các dịch vụ của bạn chấp nhận bất kỳ yêu cầu nào, giả định một cách an toàn rằng yêu cầu đó đến từ một nguồn đáng tin cậy и hành động này được cho phép.

4. Cân bằng tải

TL;DR: Phân phối tải trên các phiên bản dịch vụ theo một mẫu cụ thể.

Một “Dịch vụ” trong một phần dịch vụ thường bao gồm nhiều trường hợp giống hệt nhau. Ví dụ, ngày nay dịch vụ cache bao gồm 5 bản và ngày mai số lượng của chúng có thể tăng lên 11. Yêu cầu được gửi tới cache, phải được phân phối phù hợp với một mục đích cụ thể. Ví dụ: giảm thiểu độ trễ hoặc tối đa hóa khả năng tiếp cận phiên bản đang hoạt động. Thuật toán được sử dụng phổ biến nhất là Round-robin, nhưng cũng có nhiều thuật toán khác - ví dụ: phương pháp có trọng số (có trọng số) truy vấn (bạn có thể chọn mục tiêu ưa thích), đổ chuông (nhẫn) băm (sử dụng hàm băm nhất quán trên các máy chủ ngược dòng) hoặc phương thức yêu cầu ít nhất (ưu tiên cho phiên bản có ít yêu cầu nhất).

Bộ cân bằng cổ điển có các chức năng khác, chẳng hạn như bộ nhớ đệm HTTP và bảo vệ DDoS, nhưng chúng không phù hợp lắm với lưu lượng truy cập đông-tây (nghĩa là đối với lưu lượng truy cập trong trung tâm dữ liệu - xấp xỉ) (phạm vi điển hình của lưới dịch vụ). Tất nhiên, không cần thiết phải sử dụng lưới dịch vụ để cân bằng tải nhưng nó cho phép bạn thiết lập và kiểm soát các chính sách cân bằng cho từng dịch vụ từ lớp điều khiển tập trung, từ đó loại bỏ nhu cầu chạy và định cấu hình các bộ cân bằng tải riêng biệt trong ngăn xếp mạng .

5. Ngắt mạch

TL;DR: Dừng lưu lượng truy cập đến dịch vụ có vấn đề và kiểm soát thiệt hại trong trường hợp xấu nhất.

Nếu vì lý do nào đó mà dịch vụ không thể đáp ứng được lưu lượng, lưới dịch vụ sẽ cung cấp một số tùy chọn để giải quyết vấn đề này (các tùy chọn khác sẽ được thảo luận trong các phần thích hợp). Ngắt mạch là lựa chọn nghiêm trọng nhất để ngắt kết nối dịch vụ khỏi lưu lượng truy cập. Tuy nhiên, bản thân nó không có ý nghĩa gì - cần có một kế hoạch dự phòng. Áp lực ngược có thể được cung cấp (áp suất ngược) tới các dịch vụ đưa ra yêu cầu (chỉ cần đừng quên định cấu hình lưới dịch vụ của bạn cho việc này!), hoặc, ví dụ: tô màu đỏ cho trang trạng thái và chuyển hướng người dùng đến một phiên bản khác của trang có hình “cá voi rơi” (“Twitter là xuống").

Lưới dịch vụ không chỉ cho phép bạn xác định khi nào tắt máy sẽ theo sau và mà điều này sẽ theo sau. Trong trường hợp này, “khi” có thể bao gồm bất kỳ sự kết hợp nào của các tham số được chỉ định: tổng số yêu cầu trong một khoảng thời gian nhất định, số lượng kết nối song song, yêu cầu đang chờ xử lý, số lần thử lại đang hoạt động, v.v.

Có thể bạn không muốn lạm dụng việc ngắt mạch nhưng thật vui khi biết rằng bạn có kế hoạch dự phòng trong trường hợp khẩn cấp.

6. Tự động chia tỷ lệ

TL;DR: Tăng hoặc giảm số lượng phiên bản dịch vụ tùy theo tiêu chí đã chỉ định.

Lưới dịch vụ không phải là bộ lập lịch, vì vậy chúng không thực hiện tự mình mở rộng quy mô. Tuy nhiên, họ có thể cung cấp thông tin về cơ sở để các nhà quy hoạch đưa ra quyết định. Vì các lưới dịch vụ có quyền truy cập vào tất cả lưu lượng giữa các dịch vụ nên chúng có thông tin rộng rãi về những gì đang xảy ra: dịch vụ nào đang gặp sự cố, dịch vụ nào được tải rất nhẹ (dung lượng được phân bổ cho chúng bị lãng phí), v.v.

Ví dụ: Kubernetes chia tỷ lệ các dịch vụ dựa trên mức sử dụng CPU và bộ nhớ của nhóm (xem báo cáo của chúng tôi "Tự động hóa quy mô và quản lý tài nguyên trong Kubernetes" - khoảng. dịch.), nhưng nếu bạn quyết định mở rộng quy mô dựa trên bất kỳ số liệu nào khác (trong trường hợp của chúng tôi là liên quan đến lưu lượng truy cập), bạn sẽ cần một số liệu đặc biệt. Sự quản lý như thế này cho thấy cách thực hiện việc này với Đặc phái viên, Istio и Prometheus, nhưng bản thân quá trình này khá phức tạp. Chúng tôi muốn lưới dịch vụ đơn giản hóa việc này bằng cách cho phép chúng tôi chỉ cần đặt các điều kiện như “tăng số lượng phiên bản dịch vụ auth, nếu số lượng yêu cầu đang chờ xử lý vượt quá ngưỡng trong vòng một phút."

7. Triển khai Canary

TL;DR: Thử nghiệm các tính năng hoặc phiên bản dịch vụ mới trên một nhóm nhỏ người dùng.

Giả sử bạn đang phát triển một sản phẩm SaaS và có ý định tung ra một phiên bản mới thú vị của sản phẩm đó. Bạn đã thử nghiệm nó trong dàn dựng và nó hoạt động rất tốt. Nhưng vẫn có những lo ngại nhất định về hành vi của cô ấy trong điều kiện thực tế. Nói cách khác, bạn cần thử nghiệm phiên bản mới về các vấn đề thực tế mà không gây nguy hiểm cho lòng tin của người dùng. Triển khai Canary là tuyệt vời cho việc này. Chúng cho phép bạn trình diễn một tính năng mới cho một nhóm nhỏ người dùng. Tập hợp con này có thể bao gồm những người dùng trung thành nhất hoặc những người làm việc với phiên bản miễn phí của sản phẩm hoặc những người dùng đã bày tỏ mong muốn trở thành “chuột lang”.

Lưới dịch vụ thực hiện điều này bằng cách cho phép bạn chỉ định tiêu chí xác định ai sẽ xem phiên bản nào của ứng dụng và định tuyến lưu lượng truy cập tương ứng. Tuy nhiên, không có gì thay đổi đối với bản thân các dịch vụ. Phiên bản 1.0 của dịch vụ tin rằng tất cả các yêu cầu đều đến từ những người dùng nên xem nó và phiên bản 1.1 cũng tin như vậy đối với người dùng. Trong khi đó, bạn có thể thay đổi tỷ lệ phần trăm lưu lượng truy cập giữa phiên bản cũ và phiên bản mới, chuyển hướng số lượng người dùng ngày càng tăng sang phiên bản mới nếu nó hoạt động ổn định và “chuột lang” của bạn tiếp tục.

8. Triển khai xanh-xanh

TL;DR: Ra mắt một tính năng mới thú vị nhưng hãy sẵn sàng thu hồi mọi thứ ngay lập tức.

Ý nghĩa triển khai xanh lam là triển khai dịch vụ “xanh” mới, ra mắt song song với dịch vụ “xanh” cũ. Nếu mọi thứ diễn ra suôn sẻ và dịch vụ mới hoạt động tốt thì dịch vụ cũ có thể bị vô hiệu hóa dần dần. (Than ôi, một ngày nào đó, dịch vụ “xanh lam” mới này sẽ lặp lại số phận của dịch vụ “xanh” và biến mất...) Việc triển khai Blue-green khác với dịch vụ canary ở chỗ chức năng mới bao gồm tất cả trong một người dùng (không phải một phần); Vấn đề ở đây là phải chuẩn bị sẵn một “bến đỗ an toàn” trong trường hợp có sự cố xảy ra.

Lưới dịch vụ cung cấp một cách rất thuận tiện để thử nghiệm dịch vụ “xanh” và ngay lập tức chuyển sang dịch vụ “xanh” đang hoạt động trong trường hợp có sự cố. Chưa kể đến thực tế là trong quá trình thực hiện, họ cung cấp rất nhiều thông tin (xem phần “Từ xa” bên dưới) về hoạt động của “màu xanh”, giúp hiểu được liệu nó đã sẵn sàng để vận hành đầy đủ hay chưa.

Ghi chú. bản dịch.: Bạn có thể đọc thêm về các chiến lược triển khai khác nhau trong Kubernetes (bao gồm cả chim hoàng yến, xanh lam/xanh lục và các chiến lược khác đã đề cập) trong bài viết này.

9. Kiểm tra sức khỏe

TL;DR: Theo dõi phiên bản dịch vụ nào đang hoạt động và phản hồi những phiên bản dịch vụ không còn hoạt động.

Kiểm tra sức khỏe (kiểm tra sức khỏe) giúp quyết định xem các phiên bản dịch vụ có sẵn sàng chấp nhận và xử lý lưu lượng truy cập hay không. Ví dụ: trong trường hợp dịch vụ HTTP, kiểm tra tình trạng có thể trông giống như một yêu cầu NHẬN tới điểm cuối /health. Trả lời 200 OK sẽ có nghĩa là phiên bản đó vẫn hoạt động tốt, bất kỳ phiên bản nào khác - rằng phiên bản đó chưa sẵn sàng nhận lưu lượng truy cập. Lưới dịch vụ cho phép bạn chỉ định cả cách thức kiểm tra chức năng và tần suất thực hiện việc kiểm tra này. Thông tin này sau đó có thể được sử dụng cho các mục đích khác - ví dụ: để cân bằng tải và ngắt mạch.

Vì vậy, kiểm tra sức khỏe không phải là trường hợp sử dụng riêng lẻ mà thường được sử dụng để đạt được các mục tiêu khác. Ngoài ra, tùy thuộc vào kết quả kiểm tra tình trạng, có thể cần phải thực hiện các hành động bên ngoài đối với các mục tiêu lưới dịch vụ khác: ví dụ: cập nhật trang trạng thái, tạo sự cố trên GitHub hoặc điền vào phiếu JIRA. Và lưới dịch vụ cung cấp một cơ chế thuận tiện để tự động hóa tất cả điều này.

10. Sa thải tải

TL;DR: Chuyển hướng lưu lượng truy cập để đáp ứng mức sử dụng tăng đột biến tạm thời.

Nếu một dịch vụ nào đó bị quá tải lưu lượng, bạn có thể tạm thời chuyển hướng một số lưu lượng này đến một vị trí khác (nghĩa là “đổ”, “chuyển” (túp lều) anh ấy ở đó). Ví dụ: tới dịch vụ dự phòng hoặc trung tâm dữ liệu hoặc tới một địa chỉ cố định báo chí đề tài. Do đó, dịch vụ sẽ tiếp tục xử lý một số yêu cầu thay vì gặp sự cố và ngừng xử lý mọi thứ hoàn toàn. Giảm tải tốt hơn là ngắt mạch, nhưng vẫn không nên lạm dụng nó. Nó giúp ngăn chặn các lỗi xếp tầng khiến các dịch vụ hạ nguồn bị hỏng.

11. Song song/phản chiếu giao thông

TL;DR: Gửi một yêu cầu tới nhiều nơi cùng một lúc.

Đôi khi có nhu cầu gửi yêu cầu (hoặc một số yêu cầu nhất định) đến một số dịch vụ cùng một lúc. Một ví dụ điển hình là gửi một phần lưu lượng truy cập sản xuất đến dịch vụ dàn dựng. Máy chủ web sản xuất chính gửi yêu cầu đến dịch vụ hạ nguồn products.production và chỉ với anh ấy. Và lưới dịch vụ sao chép yêu cầu này một cách thông minh và gửi nó đến products.staging, mà máy chủ web thậm chí không biết đến.

Một trường hợp sử dụng lưới dịch vụ liên quan khác có thể được triển khai bên cạnh việc song song hóa lưu lượng là kiểm tra hồi quy. Nó liên quan đến việc gửi cùng một yêu cầu đến các phiên bản khác nhau của dịch vụ và kiểm tra xem tất cả các phiên bản có hoạt động giống nhau hay không. Tôi chưa từng triển khai lưới dịch vụ với hệ thống kiểm tra hồi quy tích hợp như khác biệt, nhưng bản thân ý tưởng này có vẻ đầy hứa hẹn.

12. Cách nhiệt

TL;DR: Chia lưới dịch vụ của bạn thành các mạng nhỏ.

Còn được biết là phân đoạnCô lập là nghệ thuật chia lưới dịch vụ thành các phân đoạn riêng biệt về mặt logic mà không biết gì về nhau. Sự cô lập hơi giống việc tạo ra các mạng riêng ảo. Sự khác biệt cơ bản là bạn vẫn có thể tận hưởng tất cả lợi ích của lưới dịch vụ (như khám phá dịch vụ) nhưng được tăng cường bảo mật. Ví dụ: nếu kẻ tấn công có thể xâm nhập một dịch vụ trên một mạng con, hắn sẽ không thể biết dịch vụ nào đang chạy trên các mạng con khác hoặc chặn lưu lượng truy cập của chúng.

Ngoài ra, lợi ích cũng có thể mang tính tổ chức. Bạn có thể muốn chia mạng con các dịch vụ của mình dựa trên cấu trúc công ty của mình và giúp các nhà phát triển giảm bớt gánh nặng nhận thức khi phải ghi nhớ toàn bộ mạng lưới dịch vụ.

13. Giới hạn tốc độ yêu cầu, thử lại và hết thời gian chờ

TL;DR: Bạn không cần phải đưa các tác vụ quản lý yêu cầu chi tiết vào cơ sở mã của mình nữa.

Tất cả những thứ này có thể được coi là trường hợp sử dụng riêng biệt, nhưng tôi quyết định kết hợp chúng vì một đặc điểm chung: chúng đảm nhận các nhiệm vụ quản lý vòng đời yêu cầu thường được các thư viện ứng dụng xử lý. Nếu bạn đang phát triển một máy chủ web trong Ruby on Rails (không được tích hợp với lưới dịch vụ) sẽ đưa ra yêu cầu tới các dịch vụ phụ trợ thông qua gRPC, ứng dụng sẽ phải quyết định phải làm gì nếu N yêu cầu không thành công. Bạn cũng sẽ phải tìm hiểu xem các dịch vụ này có thể xử lý và mã hóa cứng các tham số này bằng cách sử dụng một thư viện đặc biệt bao nhiêu lưu lượng truy cập. Ngoài ra, ứng dụng sẽ phải quyết định khi nào nên từ bỏ và để yêu cầu kết thúc (dựa trên thời gian chờ). Và để thay đổi bất kỳ tham số nào ở trên, máy chủ web sẽ phải dừng, cấu hình lại và khởi động lại.

Việc giảm tải các tác vụ này vào lưới dịch vụ không chỉ có nghĩa là các nhà phát triển dịch vụ sẽ không phải suy nghĩ về chúng mà còn có thể xem chúng theo cách toàn cầu hơn. Nếu sử dụng một chuỗi dịch vụ phức tạp, chẳng hạn như A -> B -> C -> D -> E, thì toàn bộ vòng đời của yêu cầu phải được tính đến. Nếu nhiệm vụ là kéo dài thời gian chờ trong dịch vụ C, thì việc thực hiện tất cả cùng một lúc chứ không phải từng phần là hợp lý: bằng cách cập nhật mã dịch vụ và đợi cho đến khi yêu cầu kéo được chấp nhận và hệ thống CI triển khai dịch vụ đã cập nhật.

14. Đo từ xa

TL;DR: Thu thập tất cả thông tin cần thiết (và không hoàn toàn) từ các dịch vụ.

Đo từ xa là một thuật ngữ chung bao gồm số liệu, theo dõi phân tán và nhật ký. Lưới dịch vụ cung cấp cơ chế thu thập và xử lý cả ba loại dữ liệu. Đây là lúc mọi thứ trở nên hơi mờ nhạt vì số lượng các lựa chọn khả thi quá lớn. Để thu thập số liệu có Prometheus và các công cụ khác có thể được sử dụng để thu thập nhật ký trôi chảy, Loki, vector vv (ví dụ ClickHouse với nhà gỗ cho K8 - khoảng. dịch.), để theo dõi phân tán có Jaeger và như thế. Mỗi lưới dịch vụ có thể hỗ trợ một số công cụ chứ không phải các công cụ khác. Sẽ rất thú vị để xem liệu dự án có thể Mở từ xa cung cấp một số sự hội tụ.

Trong trường hợp này, lợi thế của công nghệ lưới dịch vụ là về nguyên tắc, các container sidecar có thể thu thập tất cả dữ liệu trên từ dịch vụ của họ. Nói cách khác, bạn có thể tùy ý sử dụng một hệ thống thu thập dữ liệu đo từ xa và lưới dịch vụ có thể xử lý tất cả thông tin này theo nhiều cách khác nhau. Ví dụ:

nhật ký đuôi từ một dịch vụ nhất định trong CLI;
giám sát khối lượng yêu cầu từ bảng điều khiển lưới dịch vụ;
thu thập các dấu vết được phân phối và chuyển tiếp chúng đến một hệ thống như Jaeger.

Chú ý, đánh giá chủ quan: Nói chung, đo từ xa là một lĩnh vực không mong muốn có sự can thiệp mạnh từ mạng lưới dịch vụ. Việc thu thập thông tin cơ bản và theo dõi nhanh chóng một số số liệu vàng như tỷ lệ thành công của yêu cầu và độ trễ là ổn, nhưng hãy hy vọng chúng ta không thấy các ngăn xếp Frankenstein xuất hiện nhằm cố gắng thay thế các hệ thống chuyên dụng, một số trong đó đã tự chứng minh và được nghiên cứu kỹ lưỡng .

15. Kiểm toán

TL;DR: Những người quên bài học lịch sử chắc chắn sẽ lặp lại chúng.

Kiểm toán là nghệ thuật quan sát các sự kiện quan trọng trong một hệ thống. Trong trường hợp lưới dịch vụ, điều này có thể có nghĩa là theo dõi ai đã thực hiện yêu cầu tới các điểm cuối cụ thể cho các dịch vụ cụ thể hoặc số lần xảy ra một số sự kiện liên quan đến bảo mật trong tháng trước.

Rõ ràng là kiểm toán có liên quan rất chặt chẽ với đo từ xa. Sự khác biệt là phép đo từ xa thường liên quan đến những thứ như năng suất và tính toàn vẹn về mặt kỹ thuật, trong khi kiểm toán có thể liên quan đến các vấn đề pháp lý và các vấn đề khác vượt ra ngoài phạm vi kỹ thuật nghiêm ngặt (ví dụ: tuân thủ GDPR - Quy định chung của EU về bảo vệ dữ liệu).

16. Hình dung

TL;DR: React.js tồn tại lâu dài - một nguồn giao diện lạ mắt vô tận.

Có thể có một thuật ngữ tốt hơn, nhưng tôi không biết. Ý tôi đơn giản là biểu diễn đồ họa của lưới dịch vụ hoặc một số thành phần của nó. Những hình ảnh trực quan này có thể bao gồm các chỉ báo như độ trễ trung bình, thông tin cấu hình sidecar, kết quả kiểm tra tình trạng và cảnh báo.

Làm việc trong môi trường hướng tới dịch vụ đòi hỏi tải trọng nhận thức cao hơn nhiều so với His Majesty the Monolith. Vì vậy, áp lực nhận thức phải được giảm bớt bằng mọi giá. Giao diện đồ họa đơn giản cho lưới dịch vụ với khả năng nhấp vào nút và nhận được kết quả mong muốn có thể mang tính quyết định cho sự phát triển phổ biến của công nghệ này.

Không có trong danh sách

Ban đầu tôi dự định đưa thêm một số trường hợp sử dụng vào danh sách nhưng sau đó quyết định không làm như vậy. Đây là những lý do cho quyết định của tôi:

Trung tâm đa dữ liệu. Theo ý kiến của tôi, đây không phải là một trường hợp sử dụng mà là một lĩnh vực ứng dụng hẹp và cụ thể của các lưới dịch vụ hoặc một số tập hợp chức năng như khám phá dịch vụ.
Lối vào và ra. Đây là một lĩnh vực liên quan, nhưng tôi đã giới hạn bản thân (có lẽ là một cách giả tạo) trong trường hợp sử dụng "giao thông đông-tây". Lối vào và lối ra xứng đáng có một bài viết riêng.

Kết luận

Đó là tất cả cho bây giờ! Một lần nữa, danh sách này rất tùy tiện và rất có thể không đầy đủ. Nếu bạn cho rằng tôi đã bỏ sót điều gì đó hoặc có điều gì sai sót, vui lòng liên hệ với tôi trên Twitter (@luckerkins). Hãy tôn trọng các quy tắc lịch sự.

Tái bút từ người dịch

Hình minh họa tiêu đề cho bài viết dựa trên hình ảnh từ bài viết “Lưới dịch vụ là gì (và khi nào nên sử dụng)?"(bởi Gregory MacKinnon). Nó cho thấy một số chức năng từ các ứng dụng (màu xanh lá cây) đã chuyển sang lưới dịch vụ cung cấp kết nối giữa chúng như thế nào (màu xanh lam).

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com