Mẹo và thủ thuật

Tài liệu này mô tả các phương pháp hay nhất để thiết kế, triển khai, kiểm thử và triển khai Cloud Functions.

Lưu ý: Một số đề xuất trong tài liệu này tập trung vào khởi động nguội. Các hàm không có trạng thái và môi trường thực thi thường được khởi chạy từ đầu, được gọi là khởi động nguội. Quá trình khởi động nguội có thể mất nhiều thời gian để hoàn tất. Phương pháp hay nhất là tránh khởi động nguội không cần thiết và đơn giản hoá quy trình khởi động nguội ở mức tối đa có thể (ví dụ: bằng cách tránh các phần phụ thuộc không cần thiết).

Tính chính xác

Phần này mô tả các phương pháp chung hay nhất để thiết kế và triển khai Cloud Functions.

Viết hàm idempotent

Các hàm của bạn phải cho ra cùng một kết quả ngay cả khi chúng được gọi nhiều lần. Điều này cho phép bạn thử lại một lệnh gọi nếu lệnh gọi trước đó không thành công trong quá trình thực thi mã. Để biết thêm thông tin, hãy xem phần thử lại các hàm do sự kiện điều khiển.

Không bắt đầu hoạt động trong nền

Hoạt động ở chế độ nền là mọi hoạt động xảy ra sau khi hàm của bạn chấm dứt. Lệnh gọi hàm sẽ kết thúc sau khi hàm trả về hoặc báo hiệu hoàn tất, chẳng hạn như bằng cách gọi đối số callback trong các hàm do sự kiện điều khiển của Node.js. Mọi mã chạy sau khi kết thúc mượt mà đều không thể truy cập vào CPU và sẽ không đạt được tiến trình nào.

Lưu ý: Nếu một hàm do sự kiện Node.js điều khiển trả về một Lời hứa, thì Cloud Functions sẽ đảm bảo rằng Lời hứa đó được giải quyết trước khi chấm dứt.

Ngoài ra, khi lệnh gọi tiếp theo được thực thi trong cùng một môi trường, hoạt động ở chế độ nền của bạn sẽ tiếp tục và cản trở lệnh gọi mới. Điều này có thể dẫn đến hành vi không mong muốn và các lỗi khó chẩn đoán. Việc truy cập mạng sau khi một chức năng chấm dứt thường dẫn đến việc kết nối bị đặt lại (mã lỗi ECONNRESET).

Hoạt động trong nền thường có thể được phát hiện trong nhật ký của từng lệnh gọi, bằng cách tìm mọi nội dung được ghi lại sau dòng cho biết lệnh gọi đã kết thúc. Đôi khi, hoạt động trong nền có thể bị chôn sâu hơn trong mã, đặc biệt là khi có các thao tác không đồng bộ như lệnh gọi lại hoặc bộ hẹn giờ. Xem lại mã của bạn để đảm bảo tất cả các thao tác không đồng bộ đều hoàn tất trước khi bạn chấm dứt hàm.

Luôn xoá tệp tạm thời

Bộ nhớ ổ đĩa cục bộ trong thư mục tạm thời là một hệ thống tệp trong bộ nhớ. Các tệp mà bạn viết sẽ tiêu tốn bộ nhớ có sẵn cho hàm và đôi khi vẫn tồn tại giữa các lệnh gọi. Việc không xoá rõ ràng các tệp này cuối cùng có thể dẫn đến lỗi hết bộ nhớ và khởi động nguội tiếp theo.

Bạn có thể xem bộ nhớ mà một hàm riêng lẻ sử dụng bằng cách chọn hàm đó trong danh sách hàm trong Google Cloud Console và chọn biểu đồ Mức sử dụng bộ nhớ.

Đừng tìm cách ghi bên ngoài thư mục tạm thời và đảm bảo sử dụng các phương thức độc lập với nền tảng/hệ điều hành để tạo đường dẫn tệp.

Bạn có thể giảm các yêu cầu về bộ nhớ khi xử lý các tệp lớn hơn bằng cách sử dụng quy trình tạo luồng. Ví dụ: bạn có thể xử lý một tệp trên Cloud Storage bằng cách tạo luồng đọc, truyền tệp đó qua một quy trình dựa trên luồng và ghi trực tiếp luồng đầu ra vào Cloud Storage.

Khung hàm

Khi bạn triển khai một hàm, Khung hàm sẽ tự động được thêm làm phần phụ thuộc bằng cách sử dụng phiên bản hiện tại của khung đó. Để đảm bảo các phần phụ thuộc giống nhau được cài đặt nhất quán trên nhiều môi trường, bạn nên ghim hàm của mình vào một phiên bản cụ thể của Khung hàm.

Để thực hiện việc này, hãy đưa phiên bản bạn muốn vào tệp khoá liên quan (ví dụ: package-lock.json cho Node.js hoặc requirements.txt cho Python).

Công cụ

Phần này đưa ra các nguyên tắc về cách sử dụng các công cụ để triển khai, kiểm thử và tương tác với Cloud Functions.

Phát triển cục bộ

Việc triển khai hàm mất một chút thời gian nên thường sẽ nhanh hơn nếu bạn kiểm thử mã của hàm cục bộ.

Nhà phát triển Firebase có thể sử dụng Trình mô phỏng Firebase CLI Cloud Functions.

Sử dụng Sendgrid để gửi email

Cloud Functions không cho phép kết nối đi trên cổng 25, vì vậy, bạn không thể tạo kết nối không an toàn với máy chủ SMTP. Bạn nên sử dụng SendGrid để gửi email. Bạn có thể tìm thấy các tuỳ chọn khác để gửi email trong hướng dẫn Gửi email từ một phiên bản cho Google Compute Engine.

Hiệu suất

Phần này mô tả các phương pháp hay nhất để tối ưu hoá hiệu suất.

Sử dụng phần phụ thuộc một cách khôn ngoan

Vì các hàm không có trạng thái nên môi trường thực thi thường được khởi tạo từ đầu (trong quá trình được gọi là khởi động nguội). Khi khởi động nguội, ngữ cảnh toàn cục của hàm sẽ được đánh giá.

Nếu các hàm của bạn nhập mô-đun, thì thời gian tải cho các mô-đun đó có thể làm tăng độ trễ lệnh gọi trong quá trình khởi động nguội. Bạn có thể giảm độ trễ này cũng như thời gian cần thiết để triển khai hàm bằng cách tải các phần phụ thuộc đúng cách và không tải các phần phụ thuộc mà hàm không sử dụng.

Sử dụng biến toàn cục để sử dụng lại các đối tượng trong các lệnh gọi trong tương lai

Không có gì đảm bảo rằng trạng thái của một hàm sẽ được giữ nguyên cho các lệnh gọi trong tương lai. Tuy nhiên, Cloud Functions thường tái chế môi trường thực thi của lệnh gọi trước đó. Nếu bạn khai báo một biến trong phạm vi toàn cục, thì giá trị của biến đó có thể được sử dụng lại trong các lệnh gọi tiếp theo mà không cần tính toán lại.

Bằng cách này, bạn có thể lưu các đối tượng vào bộ nhớ đệm mà có thể tốn kém để tạo lại trên mỗi lệnh gọi hàm. Việc di chuyển các đối tượng như vậy từ phần nội dung hàm sang phạm vi toàn cục có thể cải thiện đáng kể hiệu suất. Ví dụ sau đây chỉ tạo một đối tượng nặng một lần cho mỗi thực thể hàm và chia sẻ đối tượng đó trên tất cả các lệnh gọi hàm đến thực thể đã cho:

Node.js

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

Python

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

Hàm HTTP này nhận một đối tượng yêu cầu (flask.Request) và trả về văn bản phản hồi hoặc bất kỳ tập hợp giá trị nào có thể được chuyển đổi thành đối tượng Response bằng cách sử dụng make_response.

Điều này đặc biệt quan trọng đối với các kết nối mạng, tham chiếu thư viện và đối tượng ứng dụng API trong phạm vi toàn cục. Hãy xem phần Tối ưu hoá hoạt động kết nối mạng để biết ví dụ.

Lưu ý: Không được thực hiện tác vụ trong nền ngoài khoảng thời gian của một yêu cầu. Nếu bạn cần khởi chạy một biến toàn cục bằng kết quả của một tác vụ tốn kém ở chế độ nền, hãy thực hiện tác vụ đó trong quá trình thực thi hàm và lưu trữ kết quả của tác vụ đó trước khi gửi phản hồi.

Khởi chạy biến toàn cục theo kiểu lazy

Nếu bạn khởi tạo các biến trong phạm vi toàn cục, mã khởi tạo sẽ luôn được thực thi thông qua lệnh gọi khởi động nguội, làm tăng độ trễ của hàm. Trong một số trường hợp, điều này gây ra thời gian chờ gián đoạn cho các dịch vụ đang được gọi nếu các dịch vụ đó không được xử lý đúng cách trong khối try/catch. Nếu một số đối tượng không được dùng trong tất cả đường dẫn mã, hãy cân nhắc khởi chạy từng đối tượng theo yêu cầu:

Node.js

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

Python

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

Hàm HTTP này sử dụng các biến toàn cục được khởi tạo từng phần. Phương thức này lấy một đối tượng yêu cầu (flask.Request) và trả về văn bản phản hồi hoặc bất kỳ tập hợp giá trị nào có thể chuyển thành đối tượng Response bằng cách sử dụng make_response.

Điều này đặc biệt quan trọng nếu bạn xác định một số hàm trong một tệp và các hàm khác nhau sử dụng các biến khác nhau. Trừ phi sử dụng khởi chạy từng phần, bạn có thể lãng phí tài nguyên trên các biến được khởi tạo nhưng không bao giờ được sử dụng.

Lưu ý: Bạn cũng có thể sử dụng kỹ thuật này khi nhập các phần phụ thuộc trong Node.js và Python, mặc dù điều này sẽ làm giảm khả năng đọc mã.

Giảm số lần khởi động nguội bằng cách đặt số lượng thực thể tối thiểu

Theo mặc định, Cloud Functions điều chỉnh số lượng thực thể dựa trên số lượng yêu cầu đến. Bạn có thể thay đổi hành vi mặc định này bằng cách đặt số lượng thực thể tối thiểu mà Cloud Functions phải luôn sẵn sàng để phân phát yêu cầu. Việc đặt số lượng thực thể tối thiểu sẽ làm giảm số lần khởi động nguội của ứng dụng. Bạn nên đặt số lượng thực thể tối thiểu nếu ứng dụng của bạn nhạy cảm với độ trễ.

Hãy xem phần Kiểm soát hành vi điều chỉnh theo tỷ lệ để biết thêm thông tin về các tuỳ chọn thời gian chạy này.

Tài nguyên khác

Tìm hiểu thêm về cách tối ưu hoá hiệu suất trong video "Google Cloud Performance Atlas" – Cloud Functions Thời gian khởi động nguội.