Việc xây dựng riêng gateway API đã giúp chúng tôi tiết kiệm được 38% chi phí gọi các dịch vụ bên thứ ba, nhưng chúng tôi lại gặp phải những vấn đề liên quan đến việc thích nghi giữa các khu vực khác nhau.

Tuần trước, nhóm công cụ thương mại điện tử Đông Nam Á của chúng tôi vừa hoàn tất việc xem xét hóa đơn chi phí kỹ thuật của Q1. Đồng nghiệp phụ trách giao diện thanh toán suýt nữa đã “nhảy lên vì ngạc nhiên”: Sau khi thay thế gateway bên thứ ba bằng gateway tự phát triển, chi phí gọi API hàng tháng giảm ngay 38%. Tuy nhiên, trong quá trình kiểm thử màu xám trước các chương trình khuyến mãi lớn, tỷ lệ thanh toán thành công của người dùng tại node Singapore đột ngột giảm 6 phần trăm. Phải mất nửa ngày mới phát hiện ra rằng lý do là do quy tắc ngắt kết nối (circuit breaking) giữa các khu vực của gateway chưa được điều chỉnh phù hợp.

Trước hết, hãy hiểu rõ: Một gateway tự xây dựng (self-built gateway) là gì?

Nói một cách đơn giản, bạn cần tự viết một bộ chương trình để kiểm soát lưu lượng truy cập, nơi tất cả các yêu cầu API ra ngoài, các phản hồi từ bên thứ ba, và các gọi điều hành giữa các dịch vụ đều phải đi qua bộ chương trình này trước, thay thế cho dịch vụ gateway bên thứ ba mà chúng ta đã mua trước đây. Phiên bản hiện tại của chúng ta đang chạy trên 4 máy chủ ngoại hạng sử dụng CPU 2 nhân (4G), mỗi máy chủ có thể xử lý 1200 yêu cầu mỗi giây, đủ để đáp ứng nhu cầu giao dịch thanh toán và đồng bộ hóa sản phẩm hàng ngày của chúng ta với số lượng 1,8 triệu lần.

Ba lợi ích thực tế mà bạn có thể nhận được

• Đầu tiên, chi phí thực sự có thể được giảm xuống. Trước đây, chúng tôi sử dụng một gateway bên thứ ba và phải trả phí theo số lượng lần gọi; mỗi tháng tiêu tốn khoảng 2100 đô la Mỹ. Bây giờ, với máy chủ tự xây dựng và hệ thống giám sát, chi phí hàng tháng chỉ dưới 1300 đô la Mỹ, và chúng tôi cũng không phải chịu sự ảnh hưởng của các chính sách tăng giá theo bậc thang.
• Tiếp theo là việc quy định các quy tắc hoàn toàn do chúng tôi tự quyết định. Trước đây, việc giới hạn lưu lượng truy cập thông qua các gateway bên thứ ba là thống nhất; trong các đợt khuyến mãi lớn, chúng tôi cần tạm thời tăng ngân sách dành cho việc giới hạn lưu lượng đối với các giao diện thanh toán, và mỗi lần cần phải đi qua quy trình xử lý yêu cầu (ticket) kéo dài 3 ngày làm việc. Giờ đây, chúng tôi có thể tự thay đổi cấu hình trong hệ thống nền và những thay đổi đó sẽ có hiệu lực chỉ trong vòng 10 giây.
• Cuối cùng, chúng tôi không cần sử dụng bên thứ ba để xử lý dữ liệu. Khi chúng tôi phát triển công cụ thương mại điện tử, chúng tôi cần tiếp nhận các phản hồi thanh toán từ nhiều người dùng. Trước đây, tất cả các yêu cầu đều phải đi qua các nút của nhà cung cấp dịch vụ bên thứ ba, nhưng bây giờ tất cả dữ liệu nhạy cảm đều được xử lý trên máy chủ của chúng tôi, giúp giảm đáng kể chi phí tuân thủ các quy định pháp lý.

Đừng vội vàng bắt tay vào xây dựng, hãy cùng xem những sai lầm mà chúng ta đã mắc phải trước đây đã.

Điểm hạn chế đầu tiên là vấn đề thích ứng mạng lưới giữa các khu vực. Ban đầu, chúng tôi đặt node chính của gateway tại Singapore, và khi mở trang web tại Malaysia, chúng tôi chuyển toàn bộ lưu lượng truy cập trực tiếp đến đó. Kết quả là các yêu cầu từ người dùng địa phương phải đi qua Singapore trước khi được chuyển tiếp đến Malaysia, làm tăng thời gian trễ mạng lên tới 200ms. Nhiều người dùng không chịu đựng được và đã đóng trang thanh toán. Chúng tôi mất một tuần để hoàn thành việc thiết lập các node edge tại Malaysia.

Lỗi thứ hai là do thiếu các quy tắc bảo mật. Trước đây, các gateway bên thứ ba đã được cấu hình sẵn với chức năng chống DDoS và chặn các yêu cầu xấu. Khi chúng tôi xây dựng hệ thống riêng, chúng tôi quên bổ sung phần này, và chỉ ba ngày sau khi hệ thống được đưa vào sử dụng, nó đã bị các bot tấn công với 200.000 yêu cầu không hợp lệ, suýt nữa làm cho các giao diện quản lý hàng tồn kho bị sập.

Lỗi thứ ba là chi phí vận hành và bảo trì cao hơn dự kiến. Trước đây, khi có vấn đề với gateway của bên thứ ba, chúng tôi chỉ cần liên hệ với bộ phận chăm sóc khách hàng. Nhưng bây giờ, 3 nhân viên phía sau cần luân phiên trực đêm để theo dõi và giám sát hoạt động của gateway. Tháng trước, việc khắc phục sự cố của gateway đã chiếm tới 15% thời gian làm việc của mọi người.

Những đội ngũ nào phù hợp để hợp tác cùng nhau, những đội ngũ nào thì không nên lãng phí thời gian.

Nếu đội của bạn có số lượng lời gọi API trung bình mỗi ngày vượt quá 1 triệu lần, hoặc có nhiều dữ liệu nhạy cảm cần xử lý, hoặc bạn đã chán ngán các giới hạn về lưu lượng và quy trình xử lý đơn của các gateway bên thứ ba, thì việc xây dựng một gateway riêng chắc chắn là một đầu tư đáng giá.

Nhưng nếu nhóm của bạn chỉ có ít hơn 2 nhân viên phụ trách phần backend, hoặc doanh nghiệp vẫn đang ở giai đoạn thử nghiệm nhanh chóng, và quy tắc giao diện thay đổi hàng tuần, thì thực sự không cần phải dành thời gian để xử lý vấn đề này. Hãy sử dụng các gateway bên thứ ba tạm thời trước; khi doanh nghiệp ổn định hơn, bạn có thể thay đổi chúng sau.

3 lời khuyên thực hành dành cho người mới bắt đầu

1. Trước hết, hãy bắt đầu với một trường hợp cụ thể (single scenario), đừng thay thế toàn bộ ngay từ đầu. Ban đầu, chúng ta chỉ chuyển lưu lượng từ các giao diện thanh toán (payment interfaces) sang gateway tự xây dựng (self-built gateway), và mọi thứ hoạt động bình thường trong hai tuần trước khi chúng ta từ từ chuyển các giao diện khác. Ngay cả khi có sự cố xảy ra, nó chỉ ảnh hưởng đến trường hợp thanh toán mà thôi, không làm cho toàn bộ hệ thống ngừng hoạt động.
2. Bạn nhất định phải thực hiện các bài kiểm thử áp lực xuyên khu vực. Đặc biệt là đối với các dự án kinh doanh quốc tế, đừng vội vàng triển khai chỉ sau khi kiểm thử nội bộ. Hãy tìm các điểm kiểm thử tại thị trường mục tiêu và tiến hành kiểm thử áp lực trong 24 giờ để xem xét liệu có vấn đề về độ trễ hoặc tỷ lệ mất gói dữ liệu hay không.
3. Đừng tiết kiệm chi phí cho bảng điều khiển giám sát. Ít nhất bạn cũng nên theo dõi chặt chẽ ba chỉ số cốt lõi là lượng yêu cầu, tỷ lệ thành công và độ trễ, và thiết lập các ngưỡng cảnh báo phù hợp. Đừng đợi đến khi có khiếu nại từ người dùng mới phát hiện ra rằng gateway đã bị sập.

Các vấn đề nhỏ thường gặp

Câu hỏi: Liệu có bắt buộc phải sử dụng Go hoặc Rust để viết không?
Không cần đâu, phiên bản đầu tiên của chúng tôi được viết bằng Node.js và vẫn có thể chịu đựng được lượng công việc lớn nhất. Bạn chỉ cần sử dụng ngôn ngữ mà nhóm của bạn quen thuộc; việc thay đổi ngôn ngữ có thể được thực hiện sau này nếu xuất hiện vấn đề về hiệu năng.

Câu hỏi: So với các gateway của nhà cung cấp dịch vụ đám mây, cái nào tốt hơn?
Cổng thông tin của các nhà cung cấp dịch vụ đám mây (cloud providers) linh hoạt hơn so với các giải pháp của bên thứ ba, nhưng vẫn không bằng mức độ tự do mà bạn có khi tự xây dựng hệ thống. Nếu bạn không muốn bị ràng buộc bởi một nhà cung cấp dịch vụ đám mây cụ thể, việc tự xây dựng hệ thống sẽ là lựa chọn có lợi hơn.