Này Habr! Tôi trình bày với bạn chú ý bản dịch của bài báo tác giả Matt Klein.
Lần này, tôi “muốn và dịch” mô tả của cả các thành phần lưới dịch vụ, mặt phẳng dữ liệu và mặt phẳng điều khiển. Đối với tôi, mô tả này có vẻ dễ hiểu và thú vị nhất, và quan trọng nhất là dẫn đến sự hiểu biết về “Có cần thiết chút nào không?”
Khi ý tưởng về "Lưới dịch vụ" ngày càng trở nên phổ biến trong hai năm qua (Bài viết gốc ngày 10 tháng 2017 năm XNUMX) và số lượng người tham gia vào không gian này ngày càng tăng lên, tôi đã thấy sự nhầm lẫn ngày càng tăng tương ứng trong toàn bộ cộng đồng công nghệ về cách so sánh và đối chiếu các giải pháp khác nhau.
Tình hình được tóm tắt rõ nhất qua loạt tweet sau đây tôi đã viết vào tháng 7:
Nhầm lẫn lưới dịch vụ #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Không ai trong số họ có thể sánh ngang với Istio. Istio là một cái gì đó hoàn toàn khác. 1 /
Đầu tiên chỉ đơn giản là các mặt phẳng dữ liệu. Tự mình họ không làm gì cả. Chắc hẳn họ đang có tâm trạng muốn điều gì đó hơn thế. 2/
Istio là một ví dụ về mặt phẳng điều khiển liên kết các bộ phận lại với nhau. Đây là một lớp khác. /kết thúc
Các tweet trước đó đề cập đến một số dự án khác nhau (Linkerd, NGINX, HAProxy, Envoy và Istio), nhưng quan trọng hơn là giới thiệu các khái niệm chung về mặt phẳng dữ liệu, lưới dịch vụ và mặt phẳng điều khiển. Trong bài đăng này, tôi sẽ lùi lại một bước và nói về ý nghĩa của thuật ngữ "mặt phẳng dữ liệu" và "mặt phẳng điều khiển" ở mức rất cao, sau đó nói về cách áp dụng các thuật ngữ này cho các dự án được đề cập trong các tweet.
Lưới dịch vụ thực sự là gì?
Hình 1: Tổng quan về lưới dịch vụ
Hình 1 minh họa khái niệm về lưới dịch vụ ở mức cơ bản nhất. Có bốn cụm dịch vụ (AD). Mỗi phiên bản dịch vụ được liên kết với một máy chủ proxy cục bộ. Tất cả lưu lượng truy cập mạng (HTTP, REST, gRPC, Redis, v.v.) từ một phiên bản ứng dụng duy nhất được chuyển qua proxy cục bộ đến các cụm dịch vụ bên ngoài thích hợp. Bằng cách này, phiên bản ứng dụng không biết về toàn bộ mạng và chỉ biết về proxy cục bộ của nó. Trên thực tế, mạng hệ thống phân tán đã bị xóa khỏi dịch vụ.
Mặt phẳng dữ liệu
Trong lưới dịch vụ, máy chủ proxy được đặt cục bộ cho ứng dụng sẽ thực hiện các tác vụ sau:
- Khám phá dịch vụ. Những dịch vụ/ứng dụng nào có sẵn cho ứng dụng của bạn?
- Kiểm tra sức khỏe. Các phiên bản dịch vụ được trả về do khám phá dịch vụ có ổn định và sẵn sàng chấp nhận lưu lượng truy cập mạng không? Điều này có thể bao gồm cả kiểm tra tình trạng chủ động (ví dụ: phản hồi/kiểm tra tình trạng) và thụ động (ví dụ: sử dụng 3 lỗi 5xx liên tiếp làm dấu hiệu cho thấy trạng thái dịch vụ không tốt).
- Lộ trình. Khi nhận được yêu cầu "/foo" từ dịch vụ REST, yêu cầu đó sẽ được gửi đến cụm dịch vụ nào?
- Cân bằng tải. Khi một cụm dịch vụ đã được chọn trong quá trình định tuyến, yêu cầu sẽ được gửi đến phiên bản dịch vụ nào? Với thời gian chờ nào? Với cài đặt ngắt mạch nào? Nếu yêu cầu không thành công, có nên thử lại không?
- Xác thực và ủy quyền. Đối với các yêu cầu đến, dịch vụ gọi điện có thể được xác định/ủy quyền bằng mật mã bằng mTLS hoặc một số cơ chế khác không? Nếu nó được công nhận/ủy quyền, nó có được phép gọi thao tác được yêu cầu (điểm cuối) trên dịch vụ hay sẽ trả lại phản hồi không được xác thực?
- Khả năng quan sát. Số liệu thống kê chi tiết, nhật ký/nhật ký và dữ liệu theo dõi phân tán phải được tạo cho từng yêu cầu để người vận hành có thể hiểu được luồng lưu lượng phân tán và các vấn đề gỡ lỗi khi chúng phát sinh.
Mặt phẳng dữ liệu chịu trách nhiệm về tất cả các điểm trước đó trong lưới dịch vụ. Trên thực tế, proxy cục bộ của dịch vụ (sidecar) là mặt phẳng dữ liệu. Nói cách khác, mặt phẳng dữ liệu chịu trách nhiệm phát sóng, chuyển tiếp và giám sát có điều kiện mọi gói mạng được gửi đến hoặc đi từ một dịch vụ.
Mặt phẳng điều khiển
Sự trừu tượng hóa mạng mà proxy cục bộ cung cấp trong mặt phẳng dữ liệu thật kỳ diệu (?). Tuy nhiên, làm thế nào proxy thực sự biết về tuyến đường "/foo" tới dịch vụ B? Làm cách nào để sử dụng dữ liệu khám phá dịch vụ được điền bởi các yêu cầu proxy? Các thông số được cấu hình để cân bằng tải, thời gian chờ, ngắt mạch, v.v. như thế nào? Bạn triển khai một ứng dụng bằng phương pháp xanh dương/xanh lục hoặc phương pháp chuyển đổi lưu lượng truy cập một cách duyên dáng như thế nào? Ai định cấu hình cài đặt xác thực và ủy quyền trên toàn hệ thống?
Tất cả các mục trên đều nằm dưới sự kiểm soát của mặt phẳng điều khiển của lưới dịch vụ. Mặt phẳng điều khiển lấy một tập hợp các proxy không trạng thái bị cô lập và biến chúng thành một hệ thống phân tán.
Tôi nghĩ lý do khiến nhiều nhà công nghệ thấy khó hiểu các khái niệm riêng biệt về mặt phẳng dữ liệu và mặt phẳng điều khiển là vì đối với hầu hết mọi người, mặt phẳng dữ liệu quen thuộc trong khi mặt phẳng điều khiển lại xa lạ/không hiểu. Chúng tôi đã làm việc với các bộ định tuyến và chuyển mạch mạng vật lý trong một thời gian dài. Chúng tôi hiểu rằng các gói/yêu cầu cần phải đi từ điểm A đến điểm B và chúng tôi có thể sử dụng phần cứng và phần mềm để thực hiện việc này. Thế hệ proxy phần mềm mới chỉ đơn giản là những phiên bản ưa thích của những công cụ mà chúng ta đã sử dụng trong một thời gian dài.
Hình 2: Mặt phẳng điều khiển của con người
Tuy nhiên, chúng tôi đã sử dụng các mặt phẳng điều khiển trong một thời gian dài, mặc dù hầu hết các nhà khai thác mạng có thể không liên kết phần này của hệ thống với bất kỳ thành phần công nghệ nào. Lý do rất đơn giản:
Hầu hết các mặt phẳng điều khiển được sử dụng ngày nay là... chúng tôi.
Trên Hình 2 cho thấy cái mà tôi gọi là “Máy bay điều khiển của con người”. Trong kiểu triển khai này, vốn vẫn rất phổ biến, người vận hành con người có lẽ khó tính sẽ tạo các cấu hình tĩnh - có thể thông qua các tập lệnh - và triển khai chúng thông qua một số quy trình đặc biệt cho tất cả các proxy. Sau đó, các proxy bắt đầu sử dụng cấu hình này và bắt đầu xử lý mặt phẳng dữ liệu bằng cách sử dụng cài đặt đã cập nhật.
Hình 3: Mặt phẳng điều khiển lưới dịch vụ nâng cao
Trên Hình 3 hiển thị mặt phẳng điều khiển “mở rộng” của lưới dịch vụ. Nó bao gồm các phần sau:
- Con người: Vẫn còn một người (hy vọng là bớt tức giận hơn) người đưa ra các quyết định cấp cao liên quan đến toàn bộ hệ thống.
- Giao diện người dùng mặt phẳng điều khiển: Một người tương tác với một số loại giao diện người dùng để điều khiển hệ thống. Đây có thể là một cổng web, một ứng dụng dòng lệnh (CLI) hoặc một số giao diện khác. Sử dụng giao diện người dùng, người vận hành có quyền truy cập vào các tham số cấu hình hệ thống toàn cầu như:
- Kiểm soát triển khai, chuyển đổi giao thông xanh/xanh và/hoặc dần dần
- Tùy chọn xác thực và ủy quyền
- Thông số kỹ thuật của bảng định tuyến, ví dụ: khi ứng dụng A yêu cầu thông tin về "/foo" điều gì sẽ xảy ra
- Cài đặt cân bằng tải, chẳng hạn như thời gian chờ, thử lại, cài đặt ngắt mạch, v.v.
- Lập kế hoạch khối lượng công việc: Các dịch vụ được chạy trên cơ sở hạ tầng thông qua một số loại hệ thống lập lịch/điều phối, chẳng hạn như Kubernetes hoặc Nomad. Bộ lập lịch chịu trách nhiệm tải dịch vụ cùng với proxy cục bộ của nó.
- Khám phá dịch vụ. Khi bộ lập lịch khởi động và dừng các phiên bản dịch vụ, nó sẽ báo cáo trạng thái hoạt động cho hệ thống khám phá dịch vụ.
- API cấu hình proxy Sidecar : Proxy cục bộ tự động trích xuất trạng thái từ các thành phần hệ thống khác nhau bằng cách sử dụng một mô hình nhất quán cuối cùng mà không cần sự can thiệp của người vận hành. Toàn bộ hệ thống, bao gồm tất cả các phiên bản dịch vụ hiện đang chạy và máy chủ proxy cục bộ, cuối cùng sẽ hội tụ thành một hệ sinh thái. API mặt phẳng dữ liệu phổ quát của Envoy là một ví dụ về cách thức hoạt động của tính năng này trong thực tế.
Về cơ bản, mục đích của mặt phẳng điều khiển là thiết lập chính sách mà cuối cùng sẽ được mặt phẳng dữ liệu chấp nhận. Các mặt phẳng điều khiển tiên tiến hơn sẽ loại bỏ nhiều bộ phận hơn của một số hệ thống khỏi người vận hành và yêu cầu ít thao tác thủ công hơn, miễn là chúng hoạt động chính xác!...
Mặt phẳng dữ liệu và mặt phẳng điều khiển. Tóm tắt mặt phẳng dữ liệu và mặt phẳng điều khiển
- Mặt phẳng dữ liệu lưới dịch vụ: Ảnh hưởng đến mọi gói/yêu cầu trong hệ thống. Chịu trách nhiệm phát hiện ứng dụng/dịch vụ, kiểm tra tình trạng, định tuyến, cân bằng tải, xác thực/ủy quyền và khả năng quan sát.
- Mặt phẳng điều khiển lưới dịch vụ: Cung cấp chính sách và cấu hình cho tất cả các mặt phẳng dữ liệu đang chạy trong mạng dịch vụ. Không chạm vào bất kỳ gói/yêu cầu nào trên hệ thống. Mặt phẳng điều khiển biến tất cả các mặt phẳng dữ liệu thành một hệ thống phân tán.
Phối cảnh dự án hiện tại
Sau khi hiểu lời giải thích ở trên, chúng ta hãy xem hiện trạng của dự án lưới dịch vụ.
- Mặt phẳng dữ liệu: Linkerd, NGINX, HAProxy, Đặc phái viên, Traefik
- Mặt phẳng điều khiển: Istio, Nelson, SmartStack
Thay vì đi sâu phân tích từng giải pháp ở trên, tôi sẽ đề cập ngắn gọn một số điểm mà tôi tin rằng đang gây ra nhiều nhầm lẫn trong hệ sinh thái hiện tại.
Linkerd là một trong những máy chủ proxy mặt phẳng dữ liệu đầu tiên cho lưới dịch vụ vào đầu năm 2016 và đã thực hiện rất tốt công việc nâng cao nhận thức và sự chú ý đến mô hình thiết kế lưới dịch vụ. Khoảng 6 tháng sau đó, Envoy gia nhập Linkerd (mặc dù anh đã làm việc cho Lyft từ cuối năm 2015). Linkerd và Envoy là hai dự án thường được nhắc đến nhiều nhất khi bàn về lưới dịch vụ.
Istio được công bố vào tháng 2017 năm XNUMX. Các mục tiêu của dự án Istio rất giống với mặt phẳng điều khiển mở rộng được trình bày trong Hình 3. Đặc phái viên của Istio là proxy mặc định. Do đó, Istio là mặt phẳng điều khiển và Envoy là mặt phẳng dữ liệu. Trong một thời gian ngắn, Istio đã tạo ra rất nhiều sự phấn khích và các máy bay dữ liệu khác bắt đầu tích hợp để thay thế Envoy (cả Linkerd và NGINX đều thể hiện sự tích hợp với Istio). Thực tế là các mặt phẳng dữ liệu khác nhau có thể được sử dụng trong cùng một mặt phẳng điều khiển có nghĩa là mặt phẳng điều khiển và mặt phẳng dữ liệu không nhất thiết phải được kết hợp chặt chẽ với nhau. Một API như API mặt phẳng dữ liệu chung của Envoy có thể tạo thành cầu nối giữa hai phần của hệ thống.
Nelson và SmartStack giúp minh họa rõ hơn sự tách biệt giữa mặt phẳng điều khiển và mặt phẳng dữ liệu. Nelson sử dụng Envoy làm proxy và xây dựng mặt phẳng điều khiển đáng tin cậy cho lưới dịch vụ dựa trên ngăn xếp HashiCorp, tức là. Người du mục, v.v. SmartStack có lẽ là sản phẩm đầu tiên trong làn sóng lưới dịch vụ mới. SmartStack xây dựng mặt phẳng điều khiển xung quanh HAProxy hoặc NGINX, thể hiện khả năng tách mặt phẳng điều khiển khỏi lưới dịch vụ khỏi mặt phẳng dữ liệu.
Kiến trúc microservice với lưới dịch vụ ngày càng thu hút được nhiều sự chú ý (đúng vậy!), Và ngày càng có nhiều dự án và nhà cung cấp bắt đầu hoạt động theo hướng này. Trong vài năm tới, chúng ta sẽ thấy nhiều đổi mới trong cả mặt phẳng dữ liệu và mặt phẳng điều khiển, cũng như sự kết hợp sâu hơn của các thành phần khác nhau. Cuối cùng, kiến trúc microservice sẽ trở nên minh bạch và kỳ diệu hơn (?) cho người vận hành.
Hi vọng ngày càng bớt bực bội.
Bài học chính
- Một lưới dịch vụ bao gồm hai phần khác nhau: mặt phẳng dữ liệu và mặt phẳng điều khiển. Cả hai thành phần đều được yêu cầu và nếu không có chúng thì hệ thống sẽ không hoạt động.
- Mọi người đều quen thuộc với mặt phẳng điều khiển và tại thời điểm này, mặt phẳng điều khiển có thể là bạn!
- Tất cả các mặt phẳng dữ liệu cạnh tranh với nhau về tính năng, hiệu suất, khả năng cấu hình và khả năng mở rộng.
- Tất cả các mặt phẳng điều khiển đều cạnh tranh với nhau về tính năng, khả năng cấu hình, khả năng mở rộng và tính dễ sử dụng.
- Một mặt phẳng điều khiển có thể chứa các phần trừu tượng và API phù hợp để có thể sử dụng nhiều mặt phẳng dữ liệu.
Nguồn: www.habr.com