Skip to main content

Command Palette

Search for a command to run...

Introduction to Istio, Part 3

Published
4 min read

Những Giải Pháp Ban Đầu

Netflix là một trong những công ty đầu tiên phải chuyển sang kiến trúc cloud native do nhu cầu tăng trưởng nhanh chóng. Netflix đối mặt với bài toán phải di chuyển toàn bộ hệ thống lên AWS chỉ trong vài tháng trước khi hết dung lượng tại trung tâm dữ liệu của mình.

Trong quá trình chuyển đổi này, Netflix gặp phải nhiều vấn đề như đã mô tả ở trên. Các nhóm phát triển tại Netflix đã bắt đầu giải quyết các vấn đề đó bằng cách tạo ra một loạt dự án và sau đó quyết định mở mã nguồn chúng:

  • Eureka: Giải quyết vấn đề service discovery (khám phá dịch vụ).

  • Ribbon: Hỗ trợ client-side load balancing (cân bằng tải phía client).

  • Hystrix: Một thư viện cùng với bảng điều khiển (dashboard) để ngăn ngừa lỗi dây chuyền (cascading failures).

  • Zuul proxy: Cung cấp khả năng định tuyến linh hoạt, hỗ trợ triển khai blue-green, failover, chẩn đoán lỗi và chaos engineering.

Sau đó, đội ngũ kỹ sư của Spring Framework đã tích hợp các dự án này vào hệ sinh thái của mình dưới cái tên Spring Cloud. Điều này giúp bất kỳ lập trình viên Spring nào cũng có thể truy cập các dịch vụ này bằng cách thêm các thư viện (client libraries) vào dự án của họ.

Tuy nhiên, việc sử dụng những dịch vụ này đi kèm với một số hạn chế:

  • Các dịch vụ phải được viết trên nền JVM và sử dụng Spring Framework.

  • Phải thêm ngày càng nhiều phụ thuộc (dependencies) vào ứng dụng, làm tăng footprint (tổng kích thước và sự phức tạp).

  • Các nhà phát triển cần thực hiện một số cấu hình thủ công: thêm các annotations hoặc sử dụng client API cụ thể để kích hoạt tính năng.

Mặc dù các dịch vụ hạ tầng này cải thiện đáng kể so với phương pháp cũ, chúng vẫn chưa thực sự tách biệt khỏi ứng dụng. Nhà phát triển phải gánh thêm các công việc bảo trì dependencies, đồng bộ phiên bản, và cấu hình phức tạp.

Điều gì sẽ xảy ra nếu những mối quan tâm về hạ tầng này có thể được đẩy xuống tầng nền tảng và tách biệt hoàn toàn khỏi từng ứng dụng microservices?

Service Meshes

Các kỹ sư tại Lyft, cũng đang chuyển đổi từ monolith sang kiến trúc cloud native, đã gặp phải các vấn đề tương tự.

Matt Klein và đội ngũ tại Lyft đề xuất một cách tiếp cận khác:

  • Tách rời các khả năng hạ tầng ra khỏi ứng dụng chính bằng cách sử dụng một proxy chạy độc lập (out-of-process proxy).

  • Mỗi dịch vụ trong hệ thống phân tán sẽ có một proxy chuyên dụng đi kèm, chịu trách nhiệm xử lý các yêu cầu ra/vào dịch vụ một cách minh bạch.

Tính năng của Proxy

Proxy này sẽ cung cấp các tính năng:

  • Retry khi yêu cầu thất bại.

  • Cấu hình network timeouts và logic circuit-breaking.

  • Thực hiện cân bằng tải phía client (client-side load balancing).

  • Đóng vai trò là cổng bảo mật (Policy Enforcement Point) để mã hóa kết nối (HTTP thành mutual TLS).

  • Thu thập và xuất các metrics (số lượng yêu cầu, thời gian phản hồi, mã trạng thái, v.v.) đến hệ thống giám sát, giảm bớt công việc cho các đội phát triển.

Cách tiếp cận này đã giúp Lyft giải quyết nhiều vấn đề và thành công trong việc chuyển đổi sang microservices. Matt Klein sau đó đã mở mã nguồn dự án này với tên gọi Envoy.

Kubernetes và Sự Ra Đời của Istio

Trong cùng thời gian đó, containerization (Docker) và các công cụ điều phối container như Kubernetes đã giúp giải quyết bài toán về quản lý tài nguyên. Kubernetes Pod là một cấu trúc trung gian quan trọng, cho phép:

  1. Cách ly giữa các container.

  2. Liên kết lỏng lẻo giữa nhiều container trong cùng một đơn vị triển khai.

Google, cha đẻ của Kubernetes, cũng muốn xây dựng một giải pháp hạ tầng tách biệt dựa trên Kubernetes. Dự án Istio ra đời với mục tiêu này.

Istio và Envoy

  • Envoy trở thành khối xây dựng hoàn hảo cho service mesh của Istio.

  • Control plane của Istio tự động cấu hình và đồng bộ các proxy được triển khai như các sidecar trong mỗi Pod của Kubernetes.

Các Lợi Thế của Kubernetes và Istio

  • Kubernetes API Server cung cấp khả năng tự động hóa service discovery và giao tiếp địa chỉ các điểm cuối (service endpoints) trực tiếp đến proxy.

  • Cấu hình chi tiết được thực hiện thông qua các Custom Resource Definitions (CRDs) của Kubernetes.

Từ đây, Istio chính thức được ra đời, trở thành một dự án dẫn đầu trong lĩnh vực service mesh.

More from this blog

LOKIAI

143 posts

Code for food