Mẫu FLAME: cách tiếp cận mới cho mở rộng co giãn của ứng dụng
- Serverless/FaaS (Function as a Service) mang lại lợi ích về mở rộng co giãn và thanh toán theo mức sử dụng, nhưng trên thực tế lại gây ra nhiều độ phức tạp hơn.
- Nếu có thể bọc mã ứng dụng hiện có thành các hàm và chạy chúng trong các bản sao ứng dụng tạm thời, thì việc tự động mở rộng sẽ trở nên khả thi.
- Mẫu FLAME (Fleeting Lambda Application for Modular Execution) coi toàn bộ ứng dụng như một lambda và chạy các phần mô-đun trên hạ tầng ngắn hạn.
Mẫu FLAME
- Mẫu FLAME hướng tới mở rộng co giãn tinh vi theo nhu cầu cho các phần cụ thể của mã ứng dụng mà không cần quản lý máy chủ.
- Không cần viết lại ứng dụng hiện có hoặc viết lại từng phần trong runtime độc quyền.
- Thư viện
flamecủa Elixir hiện thực hóa mẫu FLAME và bao gồm backend adapter cho Fly.io, nhưng cũng có thể dùng trên bất kỳ đám mây nào cung cấp API để chạy mã ứng dụng.
Backend của FLAME
- Trên hạ tầng Fly.io,
FLAME.FlyBackendcó thể khởi động một Machine mới và kết nối nó với tác vụ cha trong khoảng 3 giây. - FLAME mặc định cung cấp
LocalBackendvàFlyBackend, nhưng bất kỳ host nào cung cấp API để cấp phát máy chủ và chạy mã ứng dụng đều có thể hoạt động như một backend FLAME. - Fly.io chạy ứng dụng bằng cách đóng gói thành Docker image, vì vậy chỉ cần khởi động một Machine mới bằng cùng image đó.
Elixir ngoài FLAME
- Elixir đặc biệt phù hợp với mô hình FLAME vì miễn phí có sẵn các tính năng như giám sát tiến trình và nhắn tin phân tán.
- Nếu ngôn ngữ có các primitive đồng thời hợp lý, thì có thể tận dụng mẫu này.
- Cũng có ví dụ triển khai mẫu FLAME trong ứng dụng JavaScript, bằng cách chuyển việc thực thi theo mô-đun sang một tệp mới để chạy.
Về bộ xử lý tác vụ nền
- FLAME hoạt động tốt trong bộ xử lý tác vụ nền, nhưng đây là vấn đề tách biệt với việc thư viện tác vụ mở rộng pool công việc.
- Điều quan trọng là tách riêng các tác vụ đảm bảo độ bền với phần thực thi co giãn.
Pooling cho mở rộng co giãn
- Thông qua triển khai FLAME của Elixir, có thể định nghĩa runner cho pool co giãn, từ đó co giãn máy chủ FLAME xuống 0 và mở rộng linh hoạt với giới hạn đồng thời tối đa.
Bố trí tiến trình
- Trong Elixir, các phần của ứng dụng có trạng thái được xây dựng xoay quanh primitive tiến trình và hoạt động tốt khi được bao bọc bằng
FLAME.callhoặcFLAME.cast.
Giám sát từ xa
- Khi tiến trình cha spin up runner, runner phải tự quản lý trạng thái idle khi không có tác vụ và kết thúc an toàn nếu mất kết nối với node cha.
Ý kiến của GN⁺
Điểm quan trọng nhất trong bài viết này là mẫu FLAME có thể đơn giản hóa việc mở rộng co giãn của ứng dụng trong khi giảm bớt độ phức tạp của cách tiếp cận serverless/FaaS truyền thống. Mẫu này cho phép các nhà phát triển nhanh chóng mở rộng chỉ những phần cần thiết mà không phải thay đổi lớn mã hiện có, và điều đó có thể trở thành một giải pháp hấp dẫn với nhiều kỹ sư phần mềm đang sử dụng hạ tầng đám mây. Mẫu FLAME đặc biệt có thể trở thành công cụ mạnh mẽ trong các ngôn ngữ như Elixir, đồng thời khả năng triển khai sang các ngôn ngữ khác cũng đang được khám phá, mở ra kỳ vọng áp dụng trong nhiều môi trường phát triển khác nhau.
1 bình luận
Ý kiến Hacker News
Bài viết này chỉ ra rất đúng những nhược điểm của kiến trúc FaaS serverless, phản ánh nỗi đau và sự phức tạp khi vận hành một ứng dụng gồm hơn 100 hàm Lambda trong 4 năm.
Với tư cách là tác giả bài viết, tôi hy vọng sẽ khơi gợi sự quan tâm của những người muốn triển khai mẫu FLAME bằng các ngôn ngữ khác như JavaScript, Go, và sẵn sàng trả lời câu hỏi.
Dịch vụ PiCloud từng sử dụng mô hình chuyển công việc tới worker một cách minh bạch, điều này cho thấy cách làm tương tự cũng có thể áp dụng với các ngôn ngữ ngoài Elixir.
Với FLAME, có thể bọc mã ứng dụng hiện có thành một hàm rồi chạy nó trong một bản sao ứng dụng tạm thời, tương tự như việc fork một tiến trình trong môi trường serverless.
Windmill.dev xem xét đơn vị trừu tượng ở cấp mã nguồn, phân tích các hàm chính và import để trích xuất đối số và phụ thuộc, rồi thực thi mã trên runtime mong muốn.
FLAME mang lại trải nghiệm phát triển cục bộ tốt trong môi trường serverless vì runner cho phát triển và kiểm thử chạy trên backend cục bộ.
Mỗi khi dùng
Flame.call, hệ thống sẽ khởi động một tiến trình ứng dụng mới và sao chép ngữ cảnh thực thi; đây là một cách giải quyết đơn giản cho bài toán scale, nhưng cần cân nhắc độ trễ tăng thêm vào thời gian khởi động ứng dụng và mức sử dụng bộ nhớ.Có ý kiến chỉ trích cách viết hoa trong tiêu đề của Hacker News, đồng thời bày tỏ hy vọng rằng điều được xem xét lại là công ty serverless.com chứ không phải các nguyên tắc serverless.
Inngest.com cung cấp một cách tiếp cận tương tự để dùng mã hiện có như các hàm serverless, quản lý trạng thái của mã từ bên ngoài, và nhấn mạnh tầm quan trọng của monitoring cũng như observability.
Có thể xây dựng một hệ thống tên là "Long Lambda" để nếu Lambda có thể chạy quá 15 phút thì mọi tác vụ đều có thể được xử lý bằng Lambda, đồng thời có thể chạy và debug cục bộ.
Bản tóm tắt này truyền đạt ngắn gọn nội dung chính của từng bình luận và được viết ở mức dễ hiểu với kỹ sư phần mềm mới vào nghề. Những phần cần kiến thức nền được giải thích ở mức tối thiểu, đồng thời giữ thái độ trung lập và không đi chệch chủ đề.