Kiến thức

Case study : Ứng dụng serverless trên AWS phục vụ Olympic Tokyo 07 tháng 03, 2022 – 74 lượt xem AWS Đầu mục bài viết Bài viết liên quan Khoá học hay

Lời nói đầu

Ở đâu ấy bạn có thể đã nghe tới định nghĩa serverless hoặc các phần mềm đang chạy nhưng mà ko cần sử dụng server (chẳng hề máy chủ). Ngày nay, với sự tăng trưởng mạnh bạo của các nền móng đám mây công cộng như AWS, Azure, Alibaba…, định nghĩa serverless đang dần phát triển thành thân thuộc hơn với các lập trình viên. Ngoài ra, bạn đã bao giờ tự xây dựng 1 hệ thống API nhưng mà ko cần phải sử dụng tới máy chủ chưa? Theo mình thấy thì trải nghiệm hiện nay của các dev với serverless thực thụ là ko nhiều, 1 phần là do mọi người vẫn tin vào các server truyền thống hơn (Cái gì sờ được cũng cứng cáp hơn). Trong loạt bài viết này, tôi sẽ thể hiện 1 dự án nhưng mà nhóm của tôi đã xây dựng 1 API 100% bằng cách sử dụng serverless. Tôi sẽ vào kiến ​​trúc hệ thống, giảng giải các thành phần và phạm vi cung cấp khai triển serverless!

Nội dung

Tiểu truyện

Người mua của tôi đã xây dựng hệ thống trên môi trường AWS, sử dụng EC2 làm máy chủ, tiếng nói là Java và sử dụng framework là Struts. Chi tiêu cho hệ thống hiện nay quá béo (Bao gồm chi tiêu AWS cũng như các chi tiêu liên can khác), thời kì sử dụng và chạy công tác trong 1 ngày ko cố định (do công tác), nhiều lúc ko có người nào. sử dụng cũng như ko chạy job nhưng mà còn phải trả phí cho 1 máy chủ API và 1 máy chủ Job. Người mua đã đề nghị chuyển hệ thống cũ sang serverless và tăng trưởng thêm các tác dụng dựa trên kiến ​​trúc mới này. Hệ thống này tôi đã xây dựng hoàn toàn trên Amazon Web Service, thành ra các dịch vụ mặc định là AWS!

Mẫu hình hệ thống ko máy chủ

Có nhẽ nhiều người cũng đã coi xét kiến ​​trúc serverless như thế này:

Vâng, ấy là kiến ​​trúc chung của 1 hệ thống ko máy chủ được khai triển trên AWS. Dòng chảy sẽ là:

Phần mềm gọi API qua API Gateway

API Gateway kích hoạt lambda

Dữ liệu truy hỏi Lambda từ DB, trả về kết quả

Dữ liệu phản hồi API Gateway cho người mua

Bla… Bla…

Ngoài ra, để vận dụng nó vào 1 dự án chi tiết cần nhiều hơn thế, hãy theo dõi phần tiếp theo!

Tham khảo khóa học “TÌM HIỂU CÁCH THỨC CỨNG”

Hệ thống ko máy chủ trong thực tiễn

Mỗi hệ thống sẽ có những điểm giống và không giống nhau tùy thuộc vào vấn đề cần khắc phục. Ko ngần ngừ, tôi sẽ hiển thị kiến ​​trúc nhưng mà tôi đã xây dựng (Đã loại trừ 1 số cụ thể, vào phần ko có máy chủ)

Tổng quan về hệ thống này:

Phần màu đỏ là lưu trữ cho Frontend (được viết bằng Angular xxx). Phần FrontEnd sẽ bao gồm Nhóm S3 được đặt làm web tĩnh, Hỗ trợ mặt tiền đám mây để lưu trữ các khoáng sản tĩnh TOÀN CẦU.

Phần màu xanh là hệ thống API ko máy chủ. Chúng tôi sẽ ân cần tới phần này nhiều hơn vì nó là trọng điểm của bài viết này. Nó bao gồm những dịch vụ gì, chúng ta hãy tuần tự đi:

WAF: Tường lửa phần mềm web – Đây được coi là tường lửa trước nhất bảo vệ web. Nhiệm vụ của nó là bảo vệ app phê duyệt các luật lệ do người mua khái niệm, thí dụ Whitelist IP, Blacklist IP… Quan trọng hơn, nó có thể phát hiện và chặn các đề nghị có tín hiệu tấn công như XSS, SQL Injection….

Cổng API: Điểm nhận tất cả các đề nghị từ client. AWS cho phép định con đường dẫn của từng đề nghị tới trình xử lý tương ứng.

Nhận thức: Dịch vụ này hỗ trợ chính xác, giao cho và điều hành người mua.

Lambda (Authenticate): Vì phần mềm của tôi có tác dụng authen đặc trưng nên tôi phải sử dụng hàm lambda này để bổ sung thêm 1 số tác dụng nhưng mà Cognito ko phục vụ đủ. Hàm lambda này sẽ được gắn trực tiếp vào API Gateway, vào vai trò giống như 1 middleware, cũng được đặt trong private subnet, mà được vẽ tương tự để tránh lầm lẫn.

VPC, Public subnet và private subnet: Cái này, nếu người nào đã từng làm với AWS và mạng của nó thì có thể hiểu được. Mạng con công cộng có thể đối diện với internet, mạng con riêng là nơi đặt các máy chủ EC2, RDS, Lambda. Chẳng thể truy cập trực tiếp từ internet tới các dịch vụ nằm trong mạng con riêng tây.

InternetGateway cho phép VPC truy cập Internet, VPC Endpoint cho phép kết nối với các dịch vụ AWS khác nhưng mà ko cần kết nối internet.

Máy chủ proxy Squid: Hoạt động như 1 proxy cho phép các khoáng sản từ mạng con riêng tây kết nối với Internet (Nhiều người sẽ sử dụng NAT Gateway hoặc NAT Instance).

Lambda (Đặt trong mạng con riêng): Đây là vong hồn của Serverless, vào vai trò giống như 1 máy chủ. Mỗi đường dẫn của API Gateway sẽ được xử lý bởi 1 hàm lambda. Lambda sẽ nhận các đề nghị từ API Gateway, xử lý và trả lại phản hồi cho API Gateway -> Phản hồi cho người mua

S3: Nếu ko có máy chủ, tệp được lưu trữ ở đâu, tải lên / tải xuống như thế nào? Thông thường, nếu hệ thống sử dụng tỉ lệ tự động, nó cũng cần 1 nơi lưu trữ tệp chung (EFS hoặc S3 …). Gần giống với Lambda, tôi chọn S3 để lưu trữ các tập tin. Nhưng mà làm thế nào để tải lên và tải xuống tệp qua lambda? Câu giải đáp là nó sẽ ko upload / download file qua lambda, lambda chỉ là bên trung gian, tạo ra URL được ký sẵn để client upload và download trực tiếp bằng S3.

DynamoDB: Đây là cơ sở dữ liệu NoSQL được tăng trưởng bởi AWS. Lưu dữ liệu dưới dạng Khóa-Trị giá. Nếu cần sử dụng cơ sở dữ liệu quan hệ, tôi khuyên bạn nên sử dụng AWS Aurora serverless (MySQL hoặc PostgreSQL), cung cấp tốt nếu sử dụng serverless

CloudWatch: Phần này có 1 số dịch vụ bé hơn. Ngoài ra, có 2 dịch vụ chính là Nhật ký và Luật lệ. Logs là nơi xem và truy hỏi log nhưng mà hàm Lambda đã ghi trong công đoạn chạy, Rules dùng để lên lịch chạy 1 số công tác cố định hàng ngày, lúc tới thời khắc sẽ gọi hàm lambda tương ứng.

SQS: Hàng đợi được sử dụng cho các công tác muốn chạy ngay tức khắc. SQS kích hoạt tính năng Lambda (Công tác) mỗi lúc 1 công bố mới được đẩy vào hàng đợi.

X-Ray: Dịch vụ này khá tốt, nó giúp theo dõi phần mềm cụ thể hơn, hiển thị trực giác trên bảng điều khiển AWS, giúp gỡ lỗi phần mềm, chẩn đoán lỗi và cải thiện phần mềm tốt hơn. Tỉ dụ: Thời kì truy hỏi dữ liệu từ DynamoDb, thời kì tải lên tệp S3 …….

SNS: Gửi công bố.

Phạm vi ko máy chủ

Nếu đã từng làm việc với lambda, chắc hẳn mọi người sẽ biết rằng mỗi hàm Lambda đều độc lập với hàm kia nên mã nguồn cũng hoàn toàn tách biệt. Vậy với 1 dự án béo bao gồm hàng trăm API thì chúng ta điều hành mã nguồn và khai triển như thế nào, chẳng thể build và upload build cho từng hàm lambda được. Vì thế, nhóm đã quyết định sử dụng serverless framework (https://www.serverless.com)

Serverless framework là 1 fw cung cấp nhiều nhà hỗ trợ đám mây bình thường như AWS, Azure, GPC, Alibaba… Nó hỗ trợ cho chúng ta 1 dụng cụ để điều hành toàn thể vòng đời của các phần mềm serverless. Serverless framework cũng cung cấp nhiều tiếng nói như Java, Nodejs, Go, Python …

Cấu hình ko máy chủ:

Ý nghĩ của framework hiểu 1 cách dễ ợt là chúng ta cần map API Gateway Path với lớp, tệp logic cho hàm tương ứng.

Đây là tệp cấu hình mẫu của dự án ko máy chủ. 1 số thành phần chính bao gồm:

các nhà hỗ trợ

tên: Tên của nhà hỗ trợ đám mây (aws, gpc, azure)

runtime: Môi trường thực thi (java8, java11, nodejs12 …)

Bưu kiện:

tạo tác: Đường dẫn tới tệp xây dựng

Công dụng: Liệt kê API của dự án

Tên hàm Lambda:

handler: lớp xử lý logic cho API

sự kiện:

http: (nếu là HTTP, hàm lambda này sẽ được kích hoạt từ API Gateway)

path: Đường dẫn API

method: HTTP method (get, post …)

Mình vừa giới thiệu qua cấu hình căn bản của serverless. Ích lợi của nó là giúp chúng tôi dễ ợt điều hành vòng đời của 1 dự án ko có máy chủ, sử dụng các kiểu lưu trữ có sẵn lúc tạo dự án.

Tóm lược

Tóm lại, để nói về hệ thống serverless, 1 bài báo là ko đủ. Trong phần này, tôi chỉ giới thiệu nói chung về hệ thống, các dịch vụ và vai trò của nó. Chờ đợi qua bài viết này các bạn có thể hiểu căn bản về kiến ​​trúc của 1 hệ thống ko bằng máy chủ truyền thống, bình chọn xem nó có thể vận dụng trực tiếp cho các dự án tiếp theo hay ko. Hi vọng sẽ có thêm nhiều dự án sử dụng serverless trong đơn vị để mọi người có thêm nhiều trải nghiệm mới.


Xem link bài viết gốc tại đây


Thông tin thêm

Case study : Phần mềm serverless trên AWS dùng cho Olympic Tokyo

07 tháng 03, 2022 – 74 lượt xem

AWS

Đầu mục bài viết

Bài viết liên can

Khoá học hay

#Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
[rule_3_plain] #Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
Lời nói đầu
Ở đâu ấy có thể các bạn đã nghe thấy định nghĩa serverless hay chạy phần mềm ko nhưng mà ko cần sử dụng 1 server nào (non-server). Ngày nay với sự tăng trưởng mạnh bạo của các nền móng public cloud như AWS, Azure, Alibaba…, định nghĩa serverless đang dần phát triển thành quen thuộc hơn với những lập trình viên. Ngoài ra bạn đã bao giờ tự tay xây dựng 1 hệ thống API nhưng mà chẳng hề sử dụng server bao giờ chưa? Theo mình thấy thì hiện nay sự trải nghiệm của các dev với serverless thực thụ chưa nhiều, 1 phần có nhẽ do người ta vẫn tin cậy ở server truyền thống hơn(Cái gì sờ thấy được cũng cứng cáp hơn). Ở loạt bài này, mình sẽ thể hiện về 1 dự án team mình xây dựngAPI 100% sử dụng serverless . Mình sẽ vào kiến trúc hệ thống, giảng giải các thành phần và framework cung cấp deploy serverless nhé!
Nội dung
Bối cảnh
Người mua của mình đã xây dựng hệ thống trên môi trường AWS, sử dụng EC2 làm server, tiếng nói là Java và sử dụng framework là Struts . Hệ thống hiện nay chi tiêu đang quá béo (Bao gồm cả chi tiêu AWS cũng như các chi tiêu liên can khác), thời kì sử dụng và chạy job trong ngày là ko cố định(do nghiệp vụ), nhiều lúc ko có người sử dụng cũng như ko có job nào chạy mà cũng phải thanh toán cho 1 server API và 1 server Job. Người mua đã đề nghị chuyển hệ thống cũ sang serverless và tăng trưởng thêm tác dụng dựa trên kiến trúc mới này. Hệ thống này mình xây dựng hoàn toàn trên Amazon Web Service, nên các dịch vụ cứ mặc định là của AWS nhé!
Mẫu hình hệ thống Serverless
Có nhẽ nhiều người cũng đã nhìn qua kiến trúc serverless như thế này:

Đúng, nó là 1 kiến trúc chung thường thấy của 1 serverless system khai triển trên AWS. Flow sẽ là:
App call API qua API Gateway
API Gateway trigger lambda
Lambda query data từ DB, trả về kết quả
API Gateway response data cho client
Bla…Bla…
Ngoài ra, để phần mềm nó vào 1 dự án chi tiết cần nhiều hơn thế này, theo dõi phần tiếp theo nhé!
Tham khảo khóa học “LEARN AWS THE HARD WAY”
Hệ thống Serverless trong thực tiễn
Mỗi hệ thống sẽ có những điểm giống và không giống nhau tuỳ thuộc vào bài toán cần khắc phục. Ko ngùng ngoằng mình sẽ đưa ra kiến trúc mình đã xây dựng luôn (Đã lược bỏ 1 số cụ thể, chính vào phần serverless)

Overview hệ thống này nhé:
Phần màu đỏ là hosting cho Frontend(được viết bằng Angular xxx). Phần FrontEnd sẽ bao gồm 1 S3 Bucket được setting làm static web, 1 Cloudfront Distribution để cache lại các resource tĩnh GLOBAL.
Phần màu xanh là hệ thống API serverless. Chúng ta sẽ ân cần tới phần này nhiều hơn vì nó là trọng điểm của bài viết này. Nó bao gồm những dịch vụ gì, đi tuần tự nhé:
WAF: Web Application Firewall – Đây được coi là bức tường lửa trước nhất để bảo vệ web. Nhiêm vụ của nó là bảo vệ app qua rule do người mua thiết lập, thí dụ Whitelist IP, Blacklist IP… Quan trọng hơn là nó có thể phát hiện và chặn những request có tín hiệu tấn công như XSS, SQL Injection….
API Gateway: Điểm nhận tất cả các request từ phía client. AWS cho phép route từng path của request tới những handler tương ứng.
Cognito: Dịch vụ này hỗ trợ phương thức chính xác, phân quyền và điều hành người mua.
Lambda (Authenticate): Vì app của mình có tác dụng authen hơi đặc trưng, bởi thế mình phải dùng lambda function này để add thêm 1 số feature nhưng mà Cognito ko phục vụ đủ. Lambda function này sẽ được đính trực tiếp vào API Gateway, vào vai trò gần giống như 1 middleware, cũng đặt trong private subnet nhé, mà vẽ như thế để tránh rối
VPC, Public subnet và private subnet: Cái này nếu người nào đã làm qua với AWS và network của nó thì có thể nắm được rồi. Public subnet thì có thể internet facing, private subet là nơi đặt các server EC2, RDS, Lambda là private. Chẳng thể truy cập trực tiếp từ internet vào các dịch vụ được đặt trong private subnet.
InternetGateway cho phép VPC có thể truy cập Internet, VPC Endpoint cho phép kết nối tới các dịch vụ khác của AWS nhưng mà không qua đường truyền internet
Squid Proxy Server: Nhập vai trò là proxy cho phép các resource từ private subet kết nối ra ngoài Internet(Nhiều người sẽ dùng NAT Gateway hoặc NAT Instance).
Lambda (Đặt trong private subnet): Đây chính là vong hồn của Serverless, vào vai trò gần giống 1 server. Mỗi path của API Gateway sẽ được xử lý bởi 1 lambda function. Lambda sẽ nhận request từ API Gateway, xử lý, trả response về API Gateway -> Response về Client
S3: Nếu không có server thì file được lưu trữ ở đâu, up/down thế nào? Thông thường nếu hệ thống sử dụng autoscale thì cũng cần 1 nơi lưu trữ file chung (EFS hoặc S3 ….). Với Lambda cũng vậy, mình chọn S3 để lưu trữ file. Nhưng mà làm thế nào để upload và download file qua lambda nhỉ. Câu giải đáp là sẽ ko up/download file qua lambda, lambda chỉ là trung gian, generate Pre-signed URL để client tiến hành upload và download trực tiếp với S3.
DynamoDB: Đây là 1 database dạng NoSQL do AWS tăng trưởng. Lưu data dạng Key-Value. Nếu cần phải có phải sử dụng CSDL quan hệ, mình khuyến khích dùng AWS Aurora serverless(MySQL hoặc PostgreSQL), cung cấp tốt nếu sử dụng serverless
CloudWatch: Phần này có 1 số dịch vụ bé hơn. Ngoài ra có 2 service chính là Logs và Rules. Logs là nơi xem, truy hỏi log nhưng mà Lambda function đã ghi ra trong công đoạn chạy, Rules được sử dụng để lập lịch cho 1 số job chạy cố định hàng ngày, lúc tới thời kì nó sẽ gọi lambda function tương ứng.
SQS: Queue được chuyên dụng cho sử dụng cho những job muốn chạy ngay tức khắc. SQS trigger tới Lambda function(Job) mỗi lúc có message mới được đẩy vào queue.
X-Ray: Service này khá hay, nó giúp monitor phần mềm 1 cách cụ thể hơn, visualize nó lên trên dashboard AWS, giúp gỡ lỗi phần mềm, suy đoán lỗi cũng như cải tiến phần mềm tốt hơn. Tỉ dụ: Thời kì query data từ DynamoDb, thời kì upload file S3…….
SNS: Gửi notification.
Serverless framework
Nếu đã từng làm việc với lambda, mọi người sẽ biết được rằng mỗi Lambda function là độc lập với nhau, source code thành ra cũng hoàn toàn biệt lập. Vậy với 1 project béo bao gồm hàng trăm API, làm thế nào chúng ta điều hành source code và deploy, chẳng thể build và upload bản build cho từng lambda function được. Vì thế team đã quyết định sử dụng framework là serverless( https://www.serverless.com)
Serverless framework là fw cung cấp nhiều cloud provider bình thường như AWS, Azure, GPC, Alibaba… Nó hỗ trợ cho chúntg ta 1 dụng cụ để điều hành full life cycle cho phần mềm serverless. Serverless framework cũng cung cấp nhiều tiếng nói như Java, Nodejs, Go, Python …
Cấu hình serverless:
Tư tưởng của framework hiểu dễ ợt là chúng ta cần mapping Path của API Gateway với class, file xử lý logic cho function tương ứng.

Đây là 1 file cấu hình sample của project serverless. 1 số thành phần quan trọng bao gồm:
provider
name: Tên cloud provider(aws, gpc, azure)
runtime: Môi trường thực thi(java8, java11, nodejs12…)
package:
artifact: Đường dẫn trỏ tới file build
functions: List API của project
Tên lambda function:
handler: class xử lý logic cho API
events:
http: (nếu là HTTP thì lambda function này sẽ được trigger từ API Gateway)
path: Đường dẫn API
method: HTTP method(get, post …)
Mình chỉ giới thiệu qua cấu hình căn bản của serverless. Ích lợi của nó là giúp chúng ta dễ ợt điều hành life cycle của project serverless, sử dụng các architype có sẵn lúc tạo project.
Tổng kết lại
Túm lại, để nói về 1 serverless system thì 1 bài viết là ko đủ. Ở phần này mình chỉ overview hệ thống, các dịch vụ và vai trò của nó . Mong rằng qua bài viết này các bạn có thể nắm được căn bản về kiến trúc 1 hệ thống ko sử dụng server truyền thống nó như thế nào, bình chọn xem có thể apply trực tiếp vào dự án tiếp theo được ko. Mong rằng sẽ có nhiều hơn dự án sử dụng serverless trong đơn vị để mọi người có thêm những trải nghiệm mới.

Xem link gốc bài viết tại đây
#Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
[rule_2_plain] #Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
[rule_2_plain] #Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
[rule_3_plain]

#Case #study #Ứng #dụng #serverless #trên #AWS #phục #vụ #Olympic #Tokyo07 #tháng #lượt #xem #AWS #Đầu #mục #bài #viếtBài #viết #liên #quanKhoá #học #hay
Lời nói đầu
Ở đâu ấy có thể các bạn đã nghe thấy định nghĩa serverless hay chạy phần mềm ko nhưng mà ko cần sử dụng 1 server nào (non-server). Ngày nay với sự tăng trưởng mạnh bạo của các nền móng public cloud như AWS, Azure, Alibaba…, định nghĩa serverless đang dần phát triển thành quen thuộc hơn với những lập trình viên. Ngoài ra bạn đã bao giờ tự tay xây dựng 1 hệ thống API nhưng mà chẳng hề sử dụng server bao giờ chưa? Theo mình thấy thì hiện nay sự trải nghiệm của các dev với serverless thực thụ chưa nhiều, 1 phần có nhẽ do người ta vẫn tin cậy ở server truyền thống hơn(Cái gì sờ thấy được cũng cứng cáp hơn). Ở loạt bài này, mình sẽ thể hiện về 1 dự án team mình xây dựngAPI 100% sử dụng serverless . Mình sẽ vào kiến trúc hệ thống, giảng giải các thành phần và framework cung cấp deploy serverless nhé!
Nội dung
Bối cảnh
Người mua của mình đã xây dựng hệ thống trên môi trường AWS, sử dụng EC2 làm server, tiếng nói là Java và sử dụng framework là Struts . Hệ thống hiện nay chi tiêu đang quá béo (Bao gồm cả chi tiêu AWS cũng như các chi tiêu liên can khác), thời kì sử dụng và chạy job trong ngày là ko cố định(do nghiệp vụ), nhiều lúc ko có người sử dụng cũng như ko có job nào chạy mà cũng phải thanh toán cho 1 server API và 1 server Job. Người mua đã đề nghị chuyển hệ thống cũ sang serverless và tăng trưởng thêm tác dụng dựa trên kiến trúc mới này. Hệ thống này mình xây dựng hoàn toàn trên Amazon Web Service, nên các dịch vụ cứ mặc định là của AWS nhé!
Mẫu hình hệ thống Serverless
Có nhẽ nhiều người cũng đã nhìn qua kiến trúc serverless như thế này:

Đúng, nó là 1 kiến trúc chung thường thấy của 1 serverless system khai triển trên AWS. Flow sẽ là:
App call API qua API Gateway
API Gateway trigger lambda
Lambda query data từ DB, trả về kết quả
API Gateway response data cho client
Bla…Bla…
Ngoài ra, để phần mềm nó vào 1 dự án chi tiết cần nhiều hơn thế này, theo dõi phần tiếp theo nhé!
Tham khảo khóa học “LEARN AWS THE HARD WAY”
Hệ thống Serverless trong thực tiễn
Mỗi hệ thống sẽ có những điểm giống và không giống nhau tuỳ thuộc vào bài toán cần khắc phục. Ko ngùng ngoằng mình sẽ đưa ra kiến trúc mình đã xây dựng luôn (Đã lược bỏ 1 số cụ thể, chính vào phần serverless)

Overview hệ thống này nhé:
Phần màu đỏ là hosting cho Frontend(được viết bằng Angular xxx). Phần FrontEnd sẽ bao gồm 1 S3 Bucket được setting làm static web, 1 Cloudfront Distribution để cache lại các resource tĩnh GLOBAL.
Phần màu xanh là hệ thống API serverless. Chúng ta sẽ ân cần tới phần này nhiều hơn vì nó là trọng điểm của bài viết này. Nó bao gồm những dịch vụ gì, đi tuần tự nhé:
WAF: Web Application Firewall – Đây được coi là bức tường lửa trước nhất để bảo vệ web. Nhiêm vụ của nó là bảo vệ app qua rule do người mua thiết lập, thí dụ Whitelist IP, Blacklist IP… Quan trọng hơn là nó có thể phát hiện và chặn những request có tín hiệu tấn công như XSS, SQL Injection….
API Gateway: Điểm nhận tất cả các request từ phía client. AWS cho phép route từng path của request tới những handler tương ứng.
Cognito: Dịch vụ này hỗ trợ phương thức chính xác, phân quyền và điều hành người mua.
Lambda (Authenticate): Vì app của mình có tác dụng authen hơi đặc trưng, bởi thế mình phải dùng lambda function này để add thêm 1 số feature nhưng mà Cognito ko phục vụ đủ. Lambda function này sẽ được đính trực tiếp vào API Gateway, vào vai trò gần giống như 1 middleware, cũng đặt trong private subnet nhé, mà vẽ như thế để tránh rối
VPC, Public subnet và private subnet: Cái này nếu người nào đã làm qua với AWS và network của nó thì có thể nắm được rồi. Public subnet thì có thể internet facing, private subet là nơi đặt các server EC2, RDS, Lambda là private. Chẳng thể truy cập trực tiếp từ internet vào các dịch vụ được đặt trong private subnet.
InternetGateway cho phép VPC có thể truy cập Internet, VPC Endpoint cho phép kết nối tới các dịch vụ khác của AWS nhưng mà không qua đường truyền internet
Squid Proxy Server: Nhập vai trò là proxy cho phép các resource từ private subet kết nối ra ngoài Internet(Nhiều người sẽ dùng NAT Gateway hoặc NAT Instance).
Lambda (Đặt trong private subnet): Đây chính là vong hồn của Serverless, vào vai trò gần giống 1 server. Mỗi path của API Gateway sẽ được xử lý bởi 1 lambda function. Lambda sẽ nhận request từ API Gateway, xử lý, trả response về API Gateway -> Response về Client
S3: Nếu không có server thì file được lưu trữ ở đâu, up/down thế nào? Thông thường nếu hệ thống sử dụng autoscale thì cũng cần 1 nơi lưu trữ file chung (EFS hoặc S3 ….). Với Lambda cũng vậy, mình chọn S3 để lưu trữ file. Nhưng mà làm thế nào để upload và download file qua lambda nhỉ. Câu giải đáp là sẽ ko up/download file qua lambda, lambda chỉ là trung gian, generate Pre-signed URL để client tiến hành upload và download trực tiếp với S3.
DynamoDB: Đây là 1 database dạng NoSQL do AWS tăng trưởng. Lưu data dạng Key-Value. Nếu cần phải có phải sử dụng CSDL quan hệ, mình khuyến khích dùng AWS Aurora serverless(MySQL hoặc PostgreSQL), cung cấp tốt nếu sử dụng serverless
CloudWatch: Phần này có 1 số dịch vụ bé hơn. Ngoài ra có 2 service chính là Logs và Rules. Logs là nơi xem, truy hỏi log nhưng mà Lambda function đã ghi ra trong công đoạn chạy, Rules được sử dụng để lập lịch cho 1 số job chạy cố định hàng ngày, lúc tới thời kì nó sẽ gọi lambda function tương ứng.
SQS: Queue được chuyên dụng cho sử dụng cho những job muốn chạy ngay tức khắc. SQS trigger tới Lambda function(Job) mỗi lúc có message mới được đẩy vào queue.
X-Ray: Service này khá hay, nó giúp monitor phần mềm 1 cách cụ thể hơn, visualize nó lên trên dashboard AWS, giúp gỡ lỗi phần mềm, suy đoán lỗi cũng như cải tiến phần mềm tốt hơn. Tỉ dụ: Thời kì query data từ DynamoDb, thời kì upload file S3…….
SNS: Gửi notification.
Serverless framework
Nếu đã từng làm việc với lambda, mọi người sẽ biết được rằng mỗi Lambda function là độc lập với nhau, source code thành ra cũng hoàn toàn biệt lập. Vậy với 1 project béo bao gồm hàng trăm API, làm thế nào chúng ta điều hành source code và deploy, chẳng thể build và upload bản build cho từng lambda function được. Vì thế team đã quyết định sử dụng framework là serverless( https://www.serverless.com)
Serverless framework là fw cung cấp nhiều cloud provider bình thường như AWS, Azure, GPC, Alibaba… Nó hỗ trợ cho chúntg ta 1 dụng cụ để điều hành full life cycle cho phần mềm serverless. Serverless framework cũng cung cấp nhiều tiếng nói như Java, Nodejs, Go, Python …
Cấu hình serverless:
Tư tưởng của framework hiểu dễ ợt là chúng ta cần mapping Path của API Gateway với class, file xử lý logic cho function tương ứng.

Đây là 1 file cấu hình sample của project serverless. 1 số thành phần quan trọng bao gồm:
provider
name: Tên cloud provider(aws, gpc, azure)
runtime: Môi trường thực thi(java8, java11, nodejs12…)
package:
artifact: Đường dẫn trỏ tới file build
functions: List API của project
Tên lambda function:
handler: class xử lý logic cho API
events:
http: (nếu là HTTP thì lambda function này sẽ được trigger từ API Gateway)
path: Đường dẫn API
method: HTTP method(get, post …)
Mình chỉ giới thiệu qua cấu hình căn bản của serverless. Ích lợi của nó là giúp chúng ta dễ ợt điều hành life cycle của project serverless, sử dụng các architype có sẵn lúc tạo project.
Tổng kết lại
Túm lại, để nói về 1 serverless system thì 1 bài viết là ko đủ. Ở phần này mình chỉ overview hệ thống, các dịch vụ và vai trò của nó . Mong rằng qua bài viết này các bạn có thể nắm được căn bản về kiến trúc 1 hệ thống ko sử dụng server truyền thống nó như thế nào, bình chọn xem có thể apply trực tiếp vào dự án tiếp theo được ko. Mong rằng sẽ có nhiều hơn dự án sử dụng serverless trong đơn vị để mọi người có thêm những trải nghiệm mới.

Xem link gốc bài viết tại đây

Related Articles

Trả lời

Email của bạn sẽ không được hiển thị công khai.

Back to top button