Công cụ CLI Mã Nguồn Mở Miễn Phí Quản Lý API

Quản lý API trước đây thường có nghĩa là một giao diện điều khiển GUI và một hóa đơn từ nhà cung cấp. Điều đó vẫn còn tồn tại, nhưng phần lớn công việc thực tế hiện nay diễn ra từ terminal. Bạn định nghĩa các tuyến đường (routes), plugin và giới hạn tốc độ (rate limits) trong một tệp cấu hình, cam kết nó vào Git, và để một CLI đẩy nó lên gateway. Không cần nhấp qua bảng điều khiển, không có sự sai lệch giữa những gì đã triển khai và những gì đã được xem xét.

Góc độ mã nguồn mở rất quan trọng ở đây. Nếu bạn tự vận hành gateway của mình, giấy phép sẽ quyết định những gì bạn có thể tự lưu trữ (self-host), fork và phân phối mà không phải trả phí cho mỗi người dùng (per seat). Hầu hết các công cụ dưới đây đều là Apache 2.0 hoặc MPL 2.0, có nghĩa là mã nguồn có sẵn, bạn có thể chạy nó ở bất cứ đâu và không có chi phí cố định cho mỗi người dùng. Đây là một góc nhìn khác so với việc chọn binary nhỏ nhất; ở đây các câu hỏi là về giấy phép, khả năng tự lưu trữ và mức độ hoạt động của kho lưu trữ GitHub.

Đây là danh sách các gateway mã nguồn mở thực sự với khả năng làm việc mạnh mẽ qua dòng lệnh: Kong Gateway OSS với decK, Tyk, KrakenD Community Edition, Apache APISIX và Gravitee. Đối với mỗi cái, bạn sẽ biết giấy phép, những gì CLI thực sự làm và một lệnh cài đặt và chạy thực tế mà bạn có thể dán. Nếu bạn muốn tìm hiểu rộng hơn, bài tổng hợp các công cụ quản lý API mã nguồn mở bao gồm các nền tảng; bài viết này là phiên bản tập trung vào terminal của nó. Văn bản giấy phép chính thức Apache 2.0 rất đáng đọc lướt qua nếu bạn chưa từng đọc các điều khoản mà bạn đang dựa vào.

Một lưu ý chân thành ngay từ đầu. Apidog xuất hiện ở cuối, nhưng không phải là một mục mã nguồn mở, bởi vì nó không phải vậy. Đây là một sản phẩm thương mại có cấp độ miễn phí. Tôi sẽ giải thích vị trí của nó mà không giả vờ nó là thứ không phải.

Điều gì khiến một công cụ CLI "mã nguồn mở" cho quản lý API

Ba điều phân biệt một tùy chọn mã nguồn mở thực sự với một bản dùng thử miễn phí có đồng hồ đếm ngược.

Giấy phép. Hãy tìm Apache 2.0, MIT, hoặc MPL 2.0 trên gateway cốt lõi, không chỉ trên các SDK client. Apache 2.0 cho phép bạn tự lưu trữ và sửa đổi tự do. MPL 2.0 (lựa chọn của Tyk) là copyleft cấp độ tệp; bạn có thể kết hợp nó với mã độc quyền miễn là các tệp MPL vẫn mở. Bất cứ thứ gì được gắn nhãn “source-available” hoặc BSL đều không giống nhau, vì vậy hãy đọc tệp LICENSE thực tế trong kho lưu trữ.

Tự lưu trữ (Self-hosting). Gateway chạy trên hạ tầng của bạn mà không có máy chủ cấp phép nào "gọi về nhà". Bạn kiểm soát mặt phẳng dữ liệu (data plane). Nếu "phiên bản cộng đồng" bị hạn chế đến mức chỉ là một bản demo, thì nó không được tính.

Kho lưu trữ được duy trì và CLI hoạt động tốt. Hãy kiểm tra số sao trên GitHub, nhưng hãy kiểm tra lịch sử commit nhiều hơn. Một gateway mà bạn có thể cấu hình khai báo từ dòng lệnh, phiên bản trong Git và chạy trong CI là toàn bộ mục đích của danh sách này. Để biết các khái niệm quản lý chung đằng sau tất cả điều này, hãy xem những gì quản lý API thực sự bao gồm.

Kong Gateway OSS (với decK)

Kong Gateway OSS là phiên bản của Kong được cấp phép Apache 2.0. Kong Inc. tiếp tục phát hành các bản build OSS cho những người chỉ muốn sử dụng mã nguồn Apache 2.0, tách biệt khỏi phiên bản Enterprise. Gateway này được cấu hình thông qua Admin API của nó, nhưng công cụ mà bạn thực sự sử dụng là decK.

decK là CLI cấu hình khai báo của Kong. Bạn xuất trạng thái của gateway đang chạy ra một tệp YAML, chỉnh sửa nó và đồng bộ hóa lại. Nó sẽ so sánh trước, vì vậy bạn thấy chính xác những gì sẽ thay đổi trước khi nó thay đổi, điều này làm cho sự sai lệch cấu hình trở nên rõ ràng thay vì im lặng.

# Xuất cấu hình Kong hiện tại ra một tệp
deck gateway dump -o kong.yaml

# Đẩy một cấu hình khai báo trở lại gateway
deck gateway sync kong.yaml

Tốt nhất cho: hạ tầng dưới dạng mã (infrastructure-as-code) cho Kong. Nếu bạn đã chạy Kong và muốn đưa các routes và plugin của mình vào Git với tính năng xem xét và CI, decK là câu trả lời. Giới hạn thực tế: nó chỉ dành riêng cho Kong, và nó quản lý cấu hình chứ không làm tài liệu hay kiểm thử. Bạn cũng đang chạy toàn bộ stack của Kong, nặng hơn một gateway binary duy nhất.

Tyk

Gateway của Tyk là mã nguồn mở theo Giấy phép Công cộng Mozilla 2.0. MPL là copyleft cấp độ tệp: các thay đổi đối với các tệp được cấp phép MPL phải giữ nguyên trạng thái mở, nhưng bạn có thể đóng gói gateway với các plugin độc quyền miễn là chúng nằm trong các tệp riêng biệt. Gateway cốt lõi, được viết bằng Go, hỗ trợ REST, GraphQL, TCP và gRPC.

Phần dòng lệnh mà hầu hết mọi người sử dụng là bundler, được tích hợp trong binary của gateway kể từ phiên bản 2.8. Nó đóng gói các plugin middleware tùy chỉnh của bạn vào một gói (bundle) đã ký mà gateway có thể tải.

# Xây dựng một gói plugin từ các tệp manifest và middleware của bạn
tyk bundle build -o bundle.zip

Tốt nhất cho: các nhóm muốn mở rộng gateway bằng các plugin xác thực hoặc chuyển đổi tùy chỉnh và cần một cách lặp lại để đóng gói chúng. Giới hạn thực tế: CLI chỉ tập trung vào việc đóng gói, không phải cấu hình khai báo đầy đủ cho toàn bộ gateway; nhiều chức năng quản lý Tyk vẫn chạy thông qua Dashboard của nó (là phần trả phí) hoặc trực tiếp qua Gateway API.

KrakenD Community Edition

KrakenD là một gateway không trạng thái (stateless), hiệu suất cao, và phiên bản Community Edition cung cấp đầy đủ các tính năng cốt lõi theo giấy phép Apache 2.0. Không trạng thái là phần thú vị: không có cơ sở dữ liệu. Gateway được định nghĩa hoàn toàn bằng một tệp cấu hình, điều này làm cho nó rất phù hợp với Git và CI.

Binary krakend chính là CLI. Bạn xác thực cấu hình bằng lệnh check và chạy gateway bằng lệnh run. Vì nó là một binary Go duy nhất, việc cài đặt chỉ là một lần tải xuống.

# Xác thực và lint cấu hình của bạn trước khi triển khai
krakend check -c krakend.json --lint

# Chạy gateway với cấu hình đó
krakend run -c krakend.json

Tính năng Cấu hình Linh hoạt (FC_ENABLE=1) cho phép bạn chia một cấu hình lớn thành các tệp mẫu với các biến, giúp bạn giữ môi trường "Khô ráo" (DRY). Tốt nhất cho: các gateway khai báo, không trạng thái, nơi tệp cấu hình là nguồn chân lý duy nhất. Giới hạn thực tế: không có tính năng lưu trữ cố định tích hợp hoặc giao diện người dùng quản trị trong CE; bạn tạo hành vi trong cấu hình thay vì nhấp vào các nút chuyển đổi, đây là một tính năng nếu bạn thích IaC và là một trở ngại nếu bạn không.

Apache APISIX

Apache APISIX là một dự án cấp cao của Apache Software Foundation, được cấp phép Apache 2.0. Việc quản trị đó rất quan trọng đối với vấn đề mã nguồn mở: nó là một dự án của quỹ, không phải phiên bản cộng đồng của một nhà cung cấp duy nhất, vì vậy bản build OSS là dự án thực sự chứ không phải một phiên bản rút gọn chỉ để giới thiệu.

APISIX có một CLI điều khiển cho các hoạt động vòng đời và một REST Admin API (mặc định liên kết với 127.0.0.1) để quản lý các routes và plugin. CLI khởi động, dừng và tải lại gateway; apisix reload cập nhật các thay đổi cấu hình mà không làm mất kết nối.

# Xem các lệnh điều khiển có sẵn
apisix help

# Khởi động gateway, sau đó hot-reload sau khi thay đổi cấu hình
apisix start
apisix reload

Tốt nhất cho: định tuyến động, thông lượng cao nơi bạn muốn thay đổi các routes và plugin trong thời gian chạy mà không cần khởi động lại, được điều khiển bởi Admin API. Giới hạn thực tế: cấu hình định tuyến nằm trong Admin API chứ không phải một lần đẩy CLI khai báo duy nhất, vì vậy quy trình làm việc "cấu hình trong Git" của bạn thường có nghĩa là viết script các lệnh gọi Admin API hoặc thêm một công cụ như ADC của APISIX vào.

Gravitee

Nền tảng Quản lý API cốt lõi của Gravitee là mã nguồn mở theo Apache 2.0. Nó không chỉ là một gateway: phiên bản Cộng đồng bao gồm APIM Gateway (thời gian chạy), APIM API (giao diện quản lý REST) và APIM Console. Các tính năng doanh nghiệp như API bất đồng bộ theo sự kiện (event-native async APIs) nằm trong phiên bản trả phí, nhưng lõi tập trung vào REST là OSS thực sự mà bạn có thể tự lưu trữ.

Câu chuyện về dòng lệnh cần một lưu ý chân thành. Quản trị hàng ngày của Gravitee chạy thông qua Management REST API và Console của nó, và việc cài đặt tự lưu trữ chính thức thường được điều khiển bằng Docker CLI. Có một công cụ graviteeio-cli được cộng đồng duy trì trên GitHub, bao bọc Management API để tự động hóa các hành động trên các module, nhưng đó là một công cụ cộng đồng, không phải binary của bên thứ nhất, vì vậy hãy xem xét trạng thái bảo trì của nó giống như bạn xem xét bất kỳ dự án cộng đồng nào trước khi bạn phụ thuộc vào nó.

# Chạy container gateway Gravitee APIM (tự lưu trữ, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Tốt nhất cho: các nhóm muốn có một lớp quản lý mã nguồn mở đầy đủ (gateway cộng với console cộng với một API quản lý để viết script) thay vì chỉ là một proxy. Giới hạn thực tế: bề mặt tự động hóa của bên thứ nhất là REST Management API, không phải một CLI duy nhất được trau chuốt; CLI của cộng đồng lấp đầy khoảng trống nhưng bạn đang chấp nhận rủi ro bảo trì của nó.

Vị trí của Apidog (và tại sao nó không có trong danh sách mã nguồn mở)

Apidog không phải là mã nguồn mở, vì vậy nó không thuộc danh sách ở trên. Đây là một sản phẩm thương mại có cấp độ miễn phí, và tôi sẽ gây hiểu lầm cho bạn nếu xếp nó vào loại Apache 2.0.

Dù sao thì đây cũng là một lời giới thiệu chân thành. Các công cụ trên là các gateway; chúng quản lý lưu lượng, routes và plugin. Chúng không thiết kế lược đồ API của bạn, chạy các kiểm thử endpoint, tạo tài liệu hay tạo các phản hồi giả (mock responses) trước khi backend tồn tại. Kết nối các công việc đó lại với nhau thường có nghĩa là Spectral cộng với openapi-generator cộng với một máy chủ mock cộng với Newman, mỗi cái có cấu hình riêng. Apidog gộp thiết kế, kiểm thử, tạo mock và tài liệu vào một không gian làm việc, và apidog-cli cung cấp cho bạn một đường dẫn terminal để thực hiện tất cả những điều đó.

# Cài đặt và xác thực Apidog CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Chạy một kịch bản kiểm thử trong CI (thoát với mã lỗi nếu thất bại)
apidog run

CLI xuất JSON có cấu trúc với agentHints.nextSteps, vì vậy nó dễ dàng tích hợp vào CI và quy trình làm việc của các AI-agent; nếu bạn đang định tuyến công việc API thông qua Claude Code hoặc tương tự, quản lý API mà không cần rời khỏi AI agent của bạn bao gồm mẫu đó. Nó cũng hỗ trợ nhập và xuất OpenAPI, chạy các kịch bản và điều khiển mock từ dòng lệnh. Hướng dẫn hoàn chỉnh về Apidog CLI trình bày các nhóm lệnh. Hãy coi nó như một tùy chọn miễn phí tích hợp bên cạnh một gateway OSS tự lưu trữ, chứ không phải là một sự thay thế.

Cách lựa chọn

Hãy chọn dựa trên quy trình làm việc, không phải số sao. Nếu bạn đã chạy Kong, decK là giải pháp nhanh nhất. Nếu bạn muốn một gateway không trạng thái được định nghĩa hoàn toàn bằng một tệp, KrakenD rất phù hợp. APISIX vượt trội về các thay đổi định tuyến động trong thời gian chạy; Gravitee cung cấp cho bạn toàn bộ lớp quản lý với một console. Để có cái nhìn so sánh rộng hơn bao gồm các nền tảng thương mại, hãy xem các công cụ quản lý API tốt nhất cho năm 2026 và góc độ quản lý API không đầu (headless) nếu bạn đang xây dựng một stack API-first.

Tóm tắt

Quản lý API mã nguồn mở từ CLI đã trưởng thành. Kong Gateway OSS với decK, Tyk, KrakenD CE, Apache APISIX và Gravitee đều là Apache 2.0 hoặc MPL 2.0, đều có thể tự lưu trữ và đều có thể điều khiển từ terminal, điều này có nghĩa là Git, xem xét và CI thay vì nhấp vào bảng điều khiển. Hãy chọn cái mà mô hình của nó phù hợp với cách bạn triển khai.

Đối với việc thiết kế, kiểm thử, tạo mock và tài liệu mà các gateway không xử lý, một công cụ tích hợp sẽ lấp đầy khoảng trống. Tải xuống Apidog và chạy apidog run trong pipeline của bạn để xem đường dẫn CLI, sau đó kết nối nó vào CI bên cạnh bất kỳ gateway OSS nào bạn chọn.