🥇Không có máy chủ

Serverless không phải là sự vắng mặt vật lý của máy chủ. Đây không phải là kẻ giết container hay một xu hướng nhất thời. Đây là một cách tiếp cận mới để xây dựng hệ thống trên đám mây. Trong bài viết hôm nay, chúng ta sẽ đề cập đến kiến trúc của các ứng dụng Serverless, hãy xem nhà cung cấp dịch vụ Serverless và các dự án nguồn mở đóng vai trò gì. Cuối cùng, hãy nói về các vấn đề khi sử dụng Serverless.

Tôi muốn viết phần máy chủ của ứng dụng (hoặc thậm chí là cửa hàng trực tuyến). Đây có thể là cuộc trò chuyện, dịch vụ xuất bản nội dung hoặc bộ cân bằng tải. Trong mọi trường hợp, sẽ có rất nhiều vấn đề đau đầu: bạn sẽ phải chuẩn bị cơ sở hạ tầng, xác định các phần phụ thuộc của ứng dụng và suy nghĩ về hệ điều hành máy chủ. Sau đó, bạn sẽ cần cập nhật các thành phần nhỏ không ảnh hưởng đến hoạt động của phần còn lại của khối nguyên khối. Chà, đừng quên việc mở rộng quy mô khi chịu tải.

Điều gì sẽ xảy ra nếu chúng ta lấy các vùng chứa tạm thời, trong đó các phần phụ thuộc bắt buộc đã được cài đặt sẵn và bản thân các vùng chứa đó được cách ly với nhau và với hệ điều hành máy chủ? Chúng tôi sẽ chia khối nguyên khối thành các vi dịch vụ, mỗi vi dịch vụ có thể được cập nhật và mở rộng quy mô độc lập với các vi dịch vụ khác. Bằng cách đặt mã vào vùng chứa như vậy, tôi có thể chạy mã trên bất kỳ cơ sở hạ tầng nào. Đã tốt hơn rồi.

Nếu bạn không muốn định cấu hình vùng chứa thì sao? Tôi không muốn nghĩ đến việc mở rộng quy mô ứng dụng. Tôi không muốn trả tiền cho các container chạy không tải khi tải trọng dịch vụ ở mức tối thiểu. Tôi muốn viết mã. Tập trung vào logic kinh doanh và đưa sản phẩm ra thị trường với tốc độ ánh sáng.

Những suy nghĩ như vậy đã đưa tôi đến với máy tính không có máy chủ. Serverless trong trường hợp này có nghĩa là không phải là sự vắng mặt về mặt vật lý của máy chủ mà là sự vắng mặt của những vấn đề đau đầu về quản lý cơ sở hạ tầng.

Ý tưởng là logic ứng dụng được chia thành các hàm độc lập. Họ có một cấu trúc sự kiện. Mỗi chức năng thực hiện một “microtask”. Tất cả những gì nhà phát triển yêu cầu là tải các chức năng vào bảng điều khiển do nhà cung cấp đám mây cung cấp và đối chiếu chúng với các nguồn sự kiện. Mã sẽ được thực thi theo yêu cầu trong vùng chứa được chuẩn bị tự động và tôi sẽ chỉ trả tiền cho thời gian thực thi.

Chúng ta hãy xem quá trình phát triển ứng dụng bây giờ sẽ như thế nào.

Từ phía nhà phát triển

Trước đó chúng ta đã bắt đầu nói về một ứng dụng dành cho cửa hàng trực tuyến. Theo cách tiếp cận truyền thống, logic chính của hệ thống được thực hiện bởi một ứng dụng nguyên khối. Và máy chủ chứa ứng dụng sẽ liên tục chạy ngay cả khi không tải.

Để chuyển sang serverless, chúng tôi chia ứng dụng thành các nhiệm vụ vi mô. Chúng tôi viết chức năng riêng của chúng tôi cho mỗi người trong số họ. Các chức năng độc lập với nhau và không lưu trữ thông tin trạng thái (không trạng thái). Chúng thậm chí có thể được viết bằng các ngôn ngữ khác nhau. Nếu một trong số chúng “rơi”, toàn bộ ứng dụng sẽ không dừng lại. Kiến trúc ứng dụng sẽ trông như thế này:

Việc phân chia thành các chức năng trong Serverless tương tự như cách làm việc với microservice. Nhưng một microservice có thể thực hiện một số nhiệm vụ và một chức năng lý tưởng nhất phải thực hiện một nhiệm vụ. Hãy tưởng tượng rằng nhiệm vụ là thu thập số liệu thống kê và hiển thị chúng theo yêu cầu của người dùng. Theo cách tiếp cận microservice, một tác vụ được thực hiện bởi một dịch vụ với hai điểm đầu vào: viết và đọc. Trong điện toán không có máy chủ, đây sẽ là hai chức năng khác nhau không liên quan đến nhau. Ví dụ: nhà phát triển tiết kiệm tài nguyên máy tính nếu số liệu thống kê được cập nhật thường xuyên hơn số liệu được tải xuống.

Các chức năng không có máy chủ phải được thực thi trong một khoảng thời gian ngắn (thời gian chờ) do nhà cung cấp dịch vụ xác định. Ví dụ: đối với AWS, thời gian chờ là 15 phút. Điều này có nghĩa là các chức năng tồn tại lâu dài sẽ phải được thay đổi để phù hợp với yêu cầu - đây là điểm khác biệt của Serverless với các công nghệ phổ biến khác hiện nay (container và Platform as a Service).

Chúng tôi chỉ định một sự kiện cho mỗi chức năng. Một sự kiện là một sự kích hoạt cho một hành động:

Sự kiện
Hành động mà hàm thực hiện

Hình ảnh sản phẩm đã được tải lên kho lưu trữ.
Nén hình ảnh và tải lên một thư mục

Địa chỉ cửa hàng vật lý đã được cập nhật trong cơ sở dữ liệu
Tải vị trí mới vào bản đồ

Khách hàng thanh toán tiền hàng
Bắt đầu xử lý thanh toán

Sự kiện có thể là yêu cầu HTTP, truyền dữ liệu, hàng đợi tin nhắn, v.v. Nguồn sự kiện là những thay đổi hoặc sự xuất hiện của dữ liệu. Ngoài ra, các chức năng có thể được kích hoạt bằng bộ đếm thời gian.

Kiến trúc đã được hoàn thiện và ứng dụng gần như trở thành không có máy chủ. Tiếp theo chúng ta đến nhà cung cấp dịch vụ.

Từ phía nhà cung cấp

Thông thường, điện toán không có máy chủ được cung cấp bởi các nhà cung cấp dịch vụ đám mây. Chúng được gọi khác nhau: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Chúng tôi sẽ sử dụng dịch vụ thông qua bảng điều khiển hoặc tài khoản cá nhân của nhà cung cấp. Mã chức năng có thể được tải xuống theo một trong các cách sau:

viết mã trong trình soạn thảo tích hợp thông qua bảng điều khiển web,
tải xuống kho lưu trữ có mã,
làm việc với kho git công khai hoặc riêng tư.

Ở đây chúng ta thiết lập các sự kiện gọi hàm. Tập hợp các sự kiện có thể khác nhau đối với các nhà cung cấp khác nhau.

Nhà cung cấp đã xây dựng và tự động hóa hệ thống Chức năng như một Dịch vụ (FaaS) trên cơ sở hạ tầng của mình:

Mã chức năng sẽ được lưu trữ ở phía nhà cung cấp.
Khi một sự kiện xảy ra, các thùng chứa có môi trường đã chuẩn bị sẵn sẽ tự động được triển khai trên máy chủ. Mỗi phiên bản hàm có vùng chứa riêng biệt.
Từ bộ lưu trữ, hàm được gửi đến vùng chứa, tính toán và trả về kết quả.
Số lượng sự kiện song song ngày càng tăng - số lượng container ngày càng tăng. Hệ thống tự động cân. Nếu người dùng không truy cập chức năng, nó sẽ không hoạt động.
Nhà cung cấp đặt thời gian nhàn rỗi cho vùng chứa - nếu trong thời gian này, các chức năng không xuất hiện trong vùng chứa thì nó sẽ bị hủy.

Bằng cách này, chúng tôi có được Serverless ngay lập tức. Chúng tôi sẽ thanh toán cho dịch vụ bằng mô hình trả tiền theo mức sử dụng và chỉ cho những chức năng được sử dụng và chỉ trong thời gian chúng được sử dụng.

Để giới thiệu dịch vụ cho các nhà phát triển, các nhà cung cấp cung cấp thời gian thử nghiệm miễn phí lên tới 12 tháng, nhưng giới hạn tổng thời gian tính toán, số lượng yêu cầu mỗi tháng, kinh phí hoặc mức tiêu thụ điện năng.

Ưu điểm chính khi làm việc với nhà cung cấp là khả năng không phải lo lắng về cơ sở hạ tầng (máy chủ, máy ảo, vùng chứa). Về phần mình, nhà cung cấp có thể triển khai FaaS bằng cách sử dụng các phát triển của riêng mình và sử dụng các công cụ nguồn mở. Hãy nói về họ thêm.

Từ phía nguồn mở

Cộng đồng nguồn mở đã tích cực làm việc trên các công cụ Serverless trong vài năm qua. Những người chơi lớn nhất trên thị trường cũng đóng góp vào việc phát triển nền tảng không có máy chủ:

Google cung cấp cho các nhà phát triển công cụ nguồn mở - knative. IBM, RedHat, Pivotal và SAP đã tham gia phát triển nó;
IBM đã làm việc trên nền tảng Serverless mởwhisk, sau đó trở thành một dự án của Quỹ Apache;
microsoft đã mở một phần mã nền tảng Chức năng Azure.

Sự phát triển cũng đang được tiến hành theo hướng các framework không có máy chủ. không thể tin được и Phân hạch được triển khai bên trong các cụm Kubernetes được chuẩn bị trước, OpenFaaS hoạt động với cả Kubernetes và Docker Swarm. Khung này hoạt động như một loại bộ điều khiển - theo yêu cầu, nó chuẩn bị môi trường thời gian chạy bên trong cụm, sau đó khởi chạy một chức năng ở đó.

Các khung dành chỗ cho việc định cấu hình công cụ phù hợp với nhu cầu của bạn. Vì vậy, trong Kubless, nhà phát triển có thể định cấu hình thời gian chờ thực thi hàm (giá trị mặc định là 180 giây). Fission, trong nỗ lực giải quyết vấn đề khởi động nguội, đề xuất giữ một số container luôn chạy (mặc dù điều này kéo theo chi phí thời gian ngừng hoạt động của tài nguyên). Và OpenFaaS cung cấp một bộ kích hoạt cho mọi sở thích và màu sắc: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT và những thứ khác.

Bạn có thể tìm thấy hướng dẫn bắt đầu trong tài liệu chính thức của khuôn khổ này. Làm việc với họ đòi hỏi phải có nhiều kỹ năng hơn một chút so với khi làm việc với nhà cung cấp - đây ít nhất là khả năng khởi chạy cụm Kubernetes thông qua CLI. Tối đa, bao gồm các công cụ nguồn mở khác (ví dụ: trình quản lý hàng đợi Kafka).

Bất kể chúng ta làm việc với Serverless như thế nào - thông qua nhà cung cấp hay sử dụng nguồn mở, chúng ta sẽ nhận được một số ưu điểm và nhược điểm của phương pháp Serverless.

Xét về mặt ưu điểm và nhược điểm

Serverless phát triển các ý tưởng về cơ sở hạ tầng container và cách tiếp cận dịch vụ vi mô, trong đó các nhóm có thể làm việc ở chế độ đa ngôn ngữ mà không bị ràng buộc với một nền tảng. Việc xây dựng một hệ thống được đơn giản hóa và dễ dàng sửa lỗi hơn. Kiến trúc microservice cho phép bạn thêm chức năng mới vào hệ thống nhanh hơn nhiều so với trường hợp ứng dụng nguyên khối.

Serverless còn giảm thời gian phát triển hơn nữa, cho phép nhà phát triển chỉ tập trung vào logic nghiệp vụ và mã hóa của ứng dụng. Kết quả là, thời gian tiếp thị cho sự phát triển bị giảm đi.

Như một phần thưởng, chúng tôi nhận được tính năng tự động chia tỷ lệ cho tải, và chúng tôi chỉ trả tiền cho những tài nguyên được sử dụng và chỉ vào thời điểm chúng được sử dụng.

Giống như bất kỳ công nghệ nào, Serverless đều có nhược điểm.

Ví dụ: nhược điểm như vậy có thể là thời gian khởi động nguội (trung bình lên tới 1 giây đối với các ngôn ngữ như JavaScript, Python, Go, Java, Ruby).

Một mặt, trên thực tế, thời gian khởi động nguội phụ thuộc vào nhiều biến số: ngôn ngữ viết hàm, số lượng thư viện, số lượng mã, giao tiếp với các tài nguyên bổ sung (cùng cơ sở dữ liệu hoặc máy chủ xác thực). Vì nhà phát triển kiểm soát các biến này nên anh ta có thể giảm thời gian khởi động. Nhưng mặt khác, nhà phát triển không thể kiểm soát thời gian khởi động của container - tất cả đều phụ thuộc vào nhà cung cấp.

Khởi động nguội có thể chuyển thành khởi động ấm khi một hàm sử dụng lại vùng chứa được khởi chạy bởi sự kiện trước đó. Tình huống này sẽ xảy ra trong ba trường hợp:

nếu khách hàng thường xuyên sử dụng dịch vụ và số lần gọi hàm tăng lên;
liệu nhà cung cấp, nền tảng hoặc khung có cho phép bạn duy trì một số vùng chứa luôn hoạt động hay không;
nếu nhà phát triển chạy các chức năng theo giờ (giả sử cứ 3 phút một lần).

Đối với nhiều ứng dụng, khởi động nguội không phải là vấn đề. Ở đây bạn cần xây dựng dựa trên loại và nhiệm vụ của dịch vụ. Độ trễ bắt đầu một giây không phải lúc nào cũng quan trọng đối với ứng dụng kinh doanh nhưng nó có thể trở nên quan trọng đối với các dịch vụ y tế. Trong trường hợp này, cách tiếp cận không có máy chủ có thể sẽ không còn phù hợp nữa.

Nhược điểm tiếp theo của Serverless là thời gian tồn tại ngắn của một chức năng (hết thời gian chờ trong thời gian đó chức năng phải được thực thi).

Tuy nhiên, nếu phải làm việc với các tác vụ có thời gian sử dụng lâu dài, bạn có thể sử dụng kiến trúc lai - kết hợp Serverless với công nghệ khác.

Không phải tất cả các hệ thống đều có thể hoạt động bằng cách sử dụng sơ đồ Serverless.

Một số ứng dụng vẫn sẽ lưu trữ dữ liệu và trạng thái trong quá trình thực thi. Một số kiến trúc sẽ vẫn nguyên khối và một số tính năng sẽ tồn tại lâu dài. Tuy nhiên (giống như công nghệ đám mây và sau đó là container), Serverless là một công nghệ có tương lai tươi sáng.

Theo hướng này, tôi muốn chuyển sang vấn đề sử dụng phương pháp Serverless một cách suôn sẻ.

Từ phía ứng dụng

Trong năm 2018, tỷ lệ sử dụng Serverless tăng gấp rưỡi. Trong số các công ty đã triển khai công nghệ này trong dịch vụ của họ có những gã khổng lồ trên thị trường như Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Đồng thời, bạn cần hiểu rằng Serverless không phải là thuốc chữa bách bệnh mà là công cụ để giải quyết một số vấn đề nhất định:

Giảm thời gian ngừng hoạt động của tài nguyên. Không cần phải liên tục giữ một máy ảo cho các dịch vụ có ít cuộc gọi.
Xử lý dữ liệu một cách nhanh chóng. Nén hình ảnh, cắt nền, thay đổi mã hóa video, làm việc với cảm biến IoT, thực hiện các phép toán.
“Dính” các dịch vụ khác lại với nhau. Kho Git với các chương trình nội bộ, bot trò chuyện trong Slack với Jira và lịch.
Cân bằng tải. Chúng ta hãy xem xét kỹ hơn ở đây.

Giả sử có một dịch vụ thu hút 50 người. Bên dưới nó có một máy ảo có phần cứng yếu. Theo thời gian, tải của dịch vụ tăng lên đáng kể. Khi đó phần cứng yếu không thể đối phó được.

Bạn có thể bao gồm một bộ cân bằng trong hệ thống sẽ phân phối tải trên ba máy ảo. Ở giai đoạn này, chúng tôi không thể dự đoán chính xác tải nên chúng tôi giữ một lượng tài nguyên nhất định đang chạy “dự trữ”. Và chúng ta trả quá nhiều cho thời gian ngừng hoạt động.

Trong tình huống như vậy, chúng tôi có thể tối ưu hóa hệ thống thông qua phương pháp kết hợp: chúng tôi để lại một máy ảo phía sau bộ cân bằng tải và đặt liên kết đến Điểm cuối Serverless với các chức năng. Nếu tải vượt quá ngưỡng, bộ cân bằng sẽ khởi chạy các phiên bản hàm đảm nhận một phần quá trình xử lý yêu cầu.

Do đó, Serverless có thể được sử dụng khi cần xử lý một số lượng lớn yêu cầu không quá thường xuyên nhưng với cường độ cao. Trong trường hợp này, việc chạy một số chức năng trong 15 phút sẽ có lợi hơn so với việc duy trì một máy hoặc máy chủ ảo mọi lúc.

Với tất cả những ưu điểm của điện toán serverless, trước khi triển khai, trước tiên bạn nên đánh giá logic ứng dụng và hiểu những vấn đề mà Serverless có thể giải quyết trong một trường hợp cụ thể.