EP208: Cân bằng tải so với Cổng API

Thông tin cập nhật hệ thống tuần này:

• CƠ HỘI CUỐI CÙNG ĐỂ ĐĂNG KÝ: Trở thành Kỹ sư AI - Khóa 5

• 12 Tính năng Code của Claude mà Mọi Kỹ sư Cần Biết (Video Youtube)

• Load Balancer và API Gateway

• MCP là gì?

• REST và gRPC

• Xác thực dựa trên Session và JWT

• Bảng Tóm tắt Các Lệnh Linux Được Sử Dụng Nhiều Nhất

CƠ HỘI CUỐI CÙNG ĐỂ ĐĂNG KÝ: Trở thành Kỹ sư AI - Khóa 5

Khóa học thứ 5 của chương trình Becoming an AI Engineer bắt đầu hôm nay, ngày 28 tháng 3. Đây là một khóa học trực tiếp, theo nhóm được tạo ra với sự hợp tác của tác giả bán chạy nhất Ali Aminian và được xuất bản bởi ByteByteGo.

Xem tại đây

Điểm đặc biệt của khóa học này:

• Học đi đôi với hành: Xây dựng các ứng dụng AI thực tế, không chỉ xem video.

• Lộ trình học có cấu trúc, hệ thống: Đi theo một chương trình giảng dạy được thiết kế cẩn thận, đưa bạn từng bước, từ kiến thức cơ bản đến nâng cao.

• Phản hồi trực tiếp và cố vấn: Nhận phản hồi trực tiếp từ giảng viên và bạn bè.

• Cộng đồng hỗ trợ: Học một mình rất khó. Học cùng cộng đồng sẽ dễ dàng!

Chúng tôi tập trung vào việc xây dựng kỹ năng, không chỉ lý thuyết hay học thụ động. Mục tiêu của chúng tôi là mỗi học viên đều có một nền tảng vững chắc để xây dựng các hệ thống AI.

Nếu bạn muốn bắt đầu học AI từ con số 0, đây là nền tảng hoàn hảo để bạn bắt đầu.

Xem tại đây

12 Tính năng Code của Claude mà Mọi Kỹ sư Cần Biết

Load Balancer và API Gateway

Load balancer và API gateway đều nằm giữa máy khách và máy chủ backend của bạn. Nhưng chúng làm những việc rất khác nhau, và nhầm lẫn chúng sẽ gây ra các vấn đề thực sự trong kiến trúc của bạn.

Một load balancer có một nhiệm vụ duy nhất: phân phối lưu lượng truy cập. Các client gửi các yêu cầu HTTP(s) từ các ứng dụng web, di động hoặc IoT, và load balancer sẽ dàn trải các yêu cầu đó trên nhiều instance máy chủ để không có máy chủ nào bị quá tải.

Nó xử lý:

• Phân phối lưu lượng truy cập

• Kiểm tra sức khỏe để phát hiện các máy chủ bị lỗi

• Chuyển đổi dự phòng khi có sự cố

• Cân bằng tải L4/L7 tùy thuộc vào việc bạn đang định tuyến theo IP hay theo nội dung HTTP thực tế.

Một API gateway thực hiện nhiều việc hơn thế. Nó cũng nhận các yêu cầu HTTP(s) từ các loại client tương tự, nhưng thay vì chỉ chuyển tiếp lưu lượng, nó kiểm soát những gì được phép đi qua và bằng cách nào.

• Giới hạn tốc độ để ngăn chặn lạm dụng.

• Tổng hợp API để client của bạn không cần gọi năm dịch vụ khác nhau.

• Khả năng quan sát để ghi nhật ký và giám sát.

• Xác thực và ủy quyền trước khi yêu cầu chạm vào backend của bạn.

• Chuyển đổi yêu cầu và phản hồi để định hình lại payload giữa định dạng của client và dịch vụ.

Trong hầu hết các thiết lập production, load balancer và API gateway được đặt cùng nhau. API gateway xử lý các tác vụ thông minh ở phía trước, giới hạn tốc độ, xác thực, định tuyến đến microservice phù hợp. Sau đó, load balancer phía sau nó sẽ phân phối lưu lượng truy cập trên các instance của dịch vụ đó.

Chúng không phải là các công cụ cạnh tranh. Chúng hoạt động tốt nhất khi được sử dụng cùng nhau.

MCP là gì?

Model Context Protocol (MCP) là một hệ thống mới do Anthropic giới thiệu nhằm làm cho các mô hình AI mạnh mẽ hơn.

Đây là một tiêu chuẩn mở (cũng đang được triển khai dưới dạng dự án mã nguồn mở) cho phép các mô hình AI (như Claude) kết nối với cơ sở dữ liệu, API, hệ thống tệp và các công cụ khác mà không cần mã tùy chỉnh cho mỗi tích hợp mới.

MCP tuân theo mô hình client-server với 3 thành phần chính:

1. Host: Các ứng dụng AI như Claude cung cấp môi trường cho các tương tác AI để có thể truy cập các công cụ và nguồn dữ liệu khác nhau. Host chạy MCP Client.

2. MCP Client: MCP client là thành phần bên trong một mô hình AI (như Claude) cho phép nó giao tiếp với máy chủ MCP. Ví dụ, nếu mô hình AI muốn lấy dữ liệu từ PostgreSQL, MCP client sẽ định dạng yêu cầu thành một thông điệp có cấu trúc để gửi đến MCP Server.

3. MCP Server: Đây là cầu nối kết nối mô hình AI với một hệ thống bên ngoài như PostgreSQL, Google Drive hoặc API. Ví dụ, nếu Claude phân tích dữ liệu bán hàng từ PostgreSQL, MCP Server cho PostgreSQL sẽ hoạt động như bộ kết nối giữa Claude và cơ sở dữ liệu.

MCP có năm khối xây dựng cốt lõi (còn gọi là nguyên thủy). Chúng được chia giữa client và server.

1. Đối với client, các khối xây dựng là Roots (truy cập tệp an toàn) và Sampling (nhờ AI giúp đỡ với một tác vụ, chẳng hạn như tạo truy vấn DB).

2. Đối với server, có Prompts (hướng dẫn để điều khiển AI), Resources (Đối tượng dữ liệu mà AI có thể tham chiếu) và Tools (các chức năng mà AI có thể gọi, chẳng hạn như chạy truy vấn DB).

REST so với gRPC

Việc lựa chọn giữa REST và gRPC thoạt nhìn có vẻ đơn giản, nhưng cuối cùng nó ảnh hưởng đến cách các dịch vụ của bạn giao tiếp, mở rộng và thậm chí là bị lỗi.

Cả hai đều đang cố gắng giải quyết cùng một vấn đề: cách các dịch vụ giao tiếp với nhau. Nhưng cách tiếp cận của họ thì khác nhau.

1. Định dạng dữ liệu

   • REST thường sử dụng JSON. Nó dễ đọc, dễ gỡ lỗi và hoạt động ở mọi nơi.

   • gRPC sử dụng Protocol Buffers (Protobuf). Nó là định dạng nhị phân, kích thước nhỏ hơn và xử lý nhanh hơn.

Bạn sẽ nhận thấy sự khác biệt về hiệu suất này trong các hệ thống đòi hỏi hiệu năng cao. JSON thì tiện lợi, nhưng Protobuf được xây dựng để đạt hiệu quả.

2. Phong cách API

   • REST dựa trên tài nguyên: /users/101 với các phương thức GET, POST, PUT, DELETE.

   • gRPC dựa trên phương thức: GetUser(), CreateUser(), UpdateUser().
     REST rất phù hợp cho các API công khai. Ngược lại, gRPC giống như gọi một hàm trên một dịch vụ khác.

3. Mô hình giao tiếp

   • REST là yêu cầu/phản hồi đơn giản. Một yêu cầu, một phản hồi.

   • gRPC hỗ trợ nhiều mẫu hơn: đơn lẻ (unary), luồng máy chủ (server streaming), luồng máy khách (client streaming) và luồng hai chiều (bidirectional streaming).

Luồng dữ liệu trở nên thực sự hữu ích khi bạn cần cập nhật thời gian thực hoặc kết nối dài hạn.

4. Hợp đồng API & an toàn kiểu dữ liệu

   • Hợp đồng REST thường được định nghĩa riêng biệt (OpenAPI/Swagger), và vẫn có thể xảy ra sai lệch.

   • gRPC sử dụng tệp .proto chia sẻ với các kiểu dữ liệu nghiêm ngặt và tạo mã tự động.

Với gRPC, cả máy khách và máy chủ đều xuất phát từ cùng một định nghĩa, vì vậy bạn ít gặp sự cố hơn trong quá trình tích hợp.

5. Bộ nhớ đệm & hỗ trợ trình duyệt

   • REST hoạt động tốt với bộ nhớ đệm HTTP, CDN và trình duyệt.

   • gRPC có hỗ trợ trình duyệt hạn chế (thường thông qua gRPC-Web) và không phù hợp tự nhiên với bộ nhớ đệm HTTP.

Xác thực dựa trên phiên (Session-Based) so với JWT-Based

Mọi ứng dụng web đều cần xác thực. Nhưng cách bạn quản lý nó sau khi đăng nhập quan trọng hơn hầu hết các nhà phát triển nhận ra.

Có hai phương pháp tiếp cận chính: dựa trên phiên (session-based) và dựa trên JWT (JWT-based). Chúng giải quyết cùng một vấn đề theo những cách khác nhau.

Xác thực dựa trên phiên (Session-Based Authentication): Người dùng đăng nhập, máy chủ tạo một phiên (session) và lưu trữ nó trong một kho lưu trữ phiên (session store). Máy khách nhận được cookie session_id. Với mỗi yêu cầu tiếp theo, trình duyệt gửi cookie đó và máy chủ tra cứu phiên để xác thực.

Trạng thái nằm ở máy chủ. Đó là sự đánh đổi chính. Nó đơn giản và dễ dàng thu hồi, nhưng giờ đây backend của bạn phải quản lý kho lưu trữ phiên đó.

Xác thực dựa trên JWT (JWT-Based Authentication): Người dùng đăng nhập, máy chủ xác thực thông tin đăng nhập, sau đó tạo và ký một token bằng một khóa bí mật hoặc khóa riêng. Token đó được gửi trở lại cho máy khách. Với mỗi yêu cầu tiếp theo, máy khách gửi nó dưới dạng token Bearer trong tiêu đề Authorization. Máy chủ xác minh chữ ký và đọc các claims. Không cần kho lưu trữ phiên.

Trạng thái nằm trong chính token. Máy chủ vẫn stateless, giúp việc mở rộng theo chiều ngang trở nên dễ dàng.

Đến lượt bạn: phương pháp nào là lựa chọn ưu tiên của bạn cho việc xác thực trong microservices?

Tóm tắt các lệnh Linux được sử dụng nhiều nhất

Linux có hàng nghìn lệnh. Hầu hết các kỹ sư sử dụng khoảng 20 lệnh mỗi ngày, không phải vì Linux có hạn chế mà vì bộ lệnh cốt lõi đó xử lý phần lớn công việc thực tế: điều hướng tệp, kiểm tra nhật ký, gỡ lỗi quy trình, kiểm tra sức khỏe hệ thống và khắc phục sự cố dưới áp lực.

Bảng tóm tắt này tổng hợp các lệnh Linux được sử dụng nhiều nhất theo từng danh mục:

• Các lệnh quản lý tệp cơ bản như ls, cd, cp, mv và rm mà bạn sử dụng thường xuyên mà không cần suy nghĩ.

• Xem và chỉnh sửa tệp với cat, less, head, tail, nano và vim khi nhật ký (logs) rất lớn và thời gian eo hẹp.

• Xử lý văn bản với grep, awk, sort và diff để biến nhật ký thô thành câu trả lời.

• Quyền truy cập với chmod và chown, vì luôn có thứ gì đó bị lỗi do các vấn đề về quyền truy cập.

• Các lệnh mạng như ssh, scp, curl, ping, ss và ip để gỡ lỗi các hệ thống từ xa.

• Kiểm tra tiến trình và hệ thống bằng ps, top, htop, df, free và uname để xem máy đang thực sự làm gì.

• Các lệnh lưu trữ, quản lý gói, điều khiển hệ thống và trợ giúp để kết nối mọi thứ lại với nhau.

Đến lượt bạn: Bạn sử dụng lệnh Linux nào nhiều nhất trong các sự cố thực tế?