Serverless là gì? Tìm hiểu mô hình điện toán không máy chủ

Bạn đang vận hành một ứng dụng startup: ban ngày lưu lượng tăng vọt, ban đêm thì gần như không có ai truy cập, server vẫn phải chạy 24/7 vừa tốn kém vừa lãng phí tài nguyên. Đây chính là bài toán khiến nhiều doanh nghiệp đau đầu. Serverless ra đời như một giải pháp thay thế, cho phép ứng dụng chỉ chạy khi có sự kiện kích hoạt, tối ưu tài nguyên và giảm gánh nặng hạ tầng. Vậy Serverless là gì và tại sao nó ngày càng được ưa chuộng? Hãy cùng tìm hiểu trong bài viết này.

Serverless là gì? Tìm hiểu mô hình điện toán không máy chủ

Serverless là gì?

Serverless là một mô hình điện toán đám mây, các nhà phát triển không cần quản lý máy chủ vật lý hay ảo mà vẫn có thể chạy ứng dụng và dịch vụ. Trong mô hình này, nhà cung cấp dịch vụ đám mây chịu trách nhiệm quản lý hạ tầng, tự động mở rộng tài nguyên khi cần thiết và tính phí dựa trên mức độ sử dụng thực tế. Mô hình không máy chủ này giúp lập trình viên tập trung vào logic ứng dụng mà không phải lo lắng về việc cấu hình, bảo trì hoặc scaling của server.

Serverless là gì?

Ba thành phần chính của Serverless

Serverless không chỉ là khái niệm về không có server mà thực chất được xây dựng từ ba thành phần chính. Mỗi thành phần trong Serverless Architecture đảm nhận một vai trò trong vòng đời phát triển phần mềm, giúp tối ưu từ khâu code đến triển khai và vận hành.

1. Function as a Service (FaaS)

FaaS là thành phần cốt lõi của Serverless, cho phép chạy các hàm nhỏ, độc lập mà không cần quản lý server. Các hàm này được thiết kế theo mô hình event-driven: chỉ chạy khi có sự kiện xảy ra (HTTP request, thay đổi cơ sở dữ liệu, message từ queue,…).

Nhà cung cấp dịch vụ cloud sẽ tự động:

- Cấp phát tài nguyên (server, container ẩn bên dưới).

- Scale hàm theo nhu cầu thực tế.

- Quản lý vận hành (bảo trì, update hạ tầng).

Ví dụ: Bạn viết một hàm handle Payment() để xử lý thanh toán và một hàm send Email() để gửi email xác nhận. Cả hai chỉ chạy khi có sự kiện phát sinh, giúp tiết kiệm tài nguyên.

2. Backend as a Service (BaaS)

BaaS cung cấp các dịch vụ backend dựng sẵn, thay thế việc tự xây dựng toàn bộ server. Điều này giúp rút ngắn giai đoạn phát triển và kiểm thử vì lập trình viên chỉ cần gọi Serverless API thay vì viết từ đầu.

Các dịch vụ phổ biến của BaaS bao gồm:

- Authentication (xác thực người dùng).

- Storage (lưu trữ file, hình ảnh, video).

- Push notification (gửi thông báo).

- Messaging (gửi và nhận tin nhắn theo thời gian thực).

Ví dụ: Khi xây dựng ứng dụng mobile, thay vì viết hệ thống đăng nhập riêng, bạn có thể tích hợp Firebase Authentication chỉ bằng vài dòng code.

 

Serverless Architecture

 

3. Serverless Database

Serverless Database là loại cơ sở dữ liệu được tối ưu để tự động mở rộng (scale), quản lý hạ tầng, backup và tính phí theo mức sử dụng. Nhà phát triển không cần lo việc cấu hình server, cập nhật hệ thống hay tối ưu hiệu năng. Điểm mạnh của Serverless Database nằm ở giai đoạn vận hành: dữ liệu tăng bao nhiêu, hệ thống tự động scale bấy nhiêu mà không phải nâng cấp thủ công. Điều này đặc biệt hữu ích khi dữ liệu tăng đột biến. 

Ví dụ: Nếu bạn xây dựng ứng dụng thương mại điện tử, database sẽ tự động scale khi có nhiều đơn hàng vào dịp Black Friday, rồi giảm tài nguyên khi hết cao điểm, bạn chỉ trả tiền đúng lúc sử dụng.

 

Serverless Database
 

Cơ chế hoạt động của Serverless

Serverless Architecture hoạt động dựa trên mô hình event-driven architecture (kiến trúc hướng sự kiện). Điều này có nghĩa là thay vì server luôn chạy để chờ request, các hàm (function chỉ khởi chạy khi có sự kiện kích hoạt. Toàn bộ hạ tầng được nhà cung cấp cloud (AWS, Azure, GCP,…) quản lý, bao gồm cấp phát server, scale và bảo trì.

Quy trình hoạt động diễn ra như sau:

Bước 1: Sự kiện kích hoạt (Event Trigger)

Một sự kiện kích hoạt xảy ra như request HTTP, thay đổi dữ liệu trong database, tải file lên cloud storage hoặc tín hiệu từ IoT device.

Bước 2: Khởi chạy hàm (Function Invocation)

Nhà cung cấp dịch vụ cloud sẽ tự động tìm và kích hoạt hàm FaaS tương ứng.

- Nếu function đã sẵn sàng, chạy ngay.

- Nếu function chưa có instance chạy, hệ thống khởi động mới (cold start).

Bước 3: Thực thi logic ứng dụng

Function xử lý request theo logic đã lập trình (ví dụ: tính toán, đọc/ghi dữ liệu, gửi email, trả kết quả JSON...).

Bước 4: Tự động mở rộng (Auto Scaling)

- Nếu nhiều request đến cùng lúc, cloud provider sẽ tự động scale bằng cách chạy nhiều instance function song song.

- Khi lưu lượng giảm, các instance không cần thiết sẽ bị hủy để tiết kiệm tài nguyên.

Bước 5: Kết quả cho người dùng

Sau khi hoàn thành, kết quả được trả về client hoặc lưu lại trong hệ thống (database, storage).

Bước 6: Thanh toán theo mức sử dụng (Pay-as-you-go)

Người dùng chỉ trả tiền cho thời gian function thực thi và tài nguyên thực sự sử dụng, không phải trả phí cho server idle.

 

Cơ chế hoạt động Serverless
 

Ví dụ thực tế: 

Người dùng upload một file ảnh lên AWS S3 (event trigger).

Event này kích hoạt một hàm Lambda (function invocation) để nén ảnh.

Hàm xử lý ảnh xong, lưu vào thư mục khác (logic execution).

Nếu 1.000 người cùng upload, Lambda tự động scale để xử lý song song (auto scaling).

Sau khi xử lý xong, chỉ tính phí đúng thời gian chạy hàm (pay-as-you-go).

 

Mô hình Serverless

Đánh giá ưu điểm và hạn chế của Serverless

Serverless không chỉ mang lại sự linh hoạt trong phát triển ứng dụng mà còn giúp doanh nghiệp tối ưu chi phí vận hành. Tuy nhiên, bên cạnh các lợi ích rõ rệt, mô hình này cũng tồn tại những hạn chế nhất định mà nhà phát triển cần cân nhắc trước khi áp dụng.

1. Ưu điểm của Serverless

Mô hình Serverless ngày càng được nhiều doanh nghiệp và lập trình viên lựa chọn bởi những lợi ích rõ rệt trong phát triển và vận hành ứng dụng.

- Tiết kiệm chi phí: Thay vì phải trả phí cố định cho máy chủ hoạt động 24/7, người dùng chỉ phải trả tiền khi function thực sự chạy. Điều này đặc biệt hữu ích với các ứng dụng có lưu lượng không ổn định, giúp doanh nghiệp tránh tình trạng lãng phí tài nguyên.

- Tự động mở rộng (Auto Scaling): Khi có nhiều request cùng đến, nhà cung cấp dịch vụ sẽ tự động tạo thêm nhiều instance function để xử lý song song. Khi lưu lượng giảm, hệ thống lại giải phóng tài nguyên. Nhờ vậy, ứng dụng luôn duy trì hiệu suất ổn định mà không cần quản lý thủ công.

- Rút ngắn thời gian triển khai: Developer không cần tốn công thiết lập server, cài đặt hệ điều hành, bảo mật hay cập nhật phần mềm. Chỉ cần viết logic và deploy lên cloud, ứng dụng có thể sẵn sàng hoạt động trong vài phút.

- Tính linh hoạt cao: Kiến trúc không máy chủ có thể kết nối trực tiếp với nhiều dịch vụ khác như cơ sở dữ liệu, bộ nhớ đám mây, API Gateway hay IoT. Điều này giúp xây dựng các hệ thống phức tạp chỉ bằng cách “ghép” các dịch vụ sẵn có, thay vì phải phát triển toàn bộ từ đầu.

- Nhanh chóng thử nghiệm và phát triển: Các nhóm startup hoặc dự án nghiên cứu có thể dễ dàng triển khai MVP (Minimum Viable Product) để thử nghiệm ý tưởng. Khi sản phẩm thành công, việc mở rộng cũng diễn ra thuận lợi nhờ khả năng scaling tự động.

 

Serverless

 

2. Hạn chế của Serverless

Khi đi vào triển khai thực tế, mô hình này vẫn có một số hạn chế về hiệu năng, bảo mật cũng như khả năng kiểm soát hạ tầng. Dưới đây là một số thách thức bạn cần lưu ý:

- Cold start: Khi function chưa chạy sẵn, cloud provider cần thời gian khởi tạo môi trường để function hoạt động. Thời gian này có thể từ vài trăm mili-giây đến vài giây, gây ra độ trễ không mong muốn, nhất là trong các ứng dụng yêu cầu phản hồi tức thì.

- Giới hạn thực thi: Các nhà cung cấp thường đặt giới hạn về thời gian chạy (ví dụ AWS Lambda: tối đa 15 phút), dung lượng bộ nhớ và khả năng xử lý. Điều này khiến Serverless không phù hợp cho các tác vụ nặng như xử lý video dài, tính toán phức tạp hoặc mô phỏng khoa học.

- Khó debug và giám sát: Do toàn bộ hạ tầng nằm phía sau cloud provider, lập trình viên khó tiếp cận trực tiếp để theo dõi. Việc debug thường dựa vào log hoặc các công cụ giám sát do nhà cung cấp cung cấp, có thể hạn chế khả năng kiểm soát và phân tích sự cố.

- Vendor lock-in: Mỗi cloud provider có cách triển khai khác nhau (AWS Lambda, Azure Functions, Google Cloud Functions...). Nếu đã xây dựng ứng dụng trên một nền tảng, việc di chuyển sang nền tảng khác thường phức tạp do sự khác biệt về API, cấu hình và hệ sinh thái đi kèm.

- Không phù hợp cho workload dài hạn: Serverless tối ưu cho các tác vụ ngắn gọn, lặp lại nhiều lần. Với workload chạy liên tục trong thời gian dài (ví dụ: streaming dữ liệu, game server real-time), tính phí theo số lần kích hoạt có thể khiến chi phí cao hơn so với dùng server truyền thống hoặc container.

 

Kiến trúc Serverless
 

Ứng dụng thực tế của Serverless

Nhờ khả năng tự động mở rộng, chi phí tối ưu và triển khai nhanh chóng, Serverless trở thành giải pháp linh hoạt cho cả startup lẫn doanh nghiệp lớn. 

1. Xử lý dữ liệu sự kiện (Event-driven processing)

Một trong những ứng dụng phổ biến nhất là xử lý dữ liệu khi có sự kiện xảy ra. Ví dụ: khi người dùng tải lên một file ảnh vào Amazon S3, sự kiện này có thể kích hoạt AWS Lambda để tự động nén ảnh, tạo thumbnail hoặc phân loại nội dung bằng dịch vụ AI. Với Serverless framework, lập trình viên chỉ cần định nghĩa event trigger trong file cấu hình serverless.yml là hệ thống sẽ tự động tạo liên kết giữa S3 và Lambda. Điều này giúp xử lý dữ liệu tức thì, không cần phải duy trì một server luôn chờ request.

2. Xây dựng API backend cho website, app

Mô hình điện toán không máy chủ này rất phù hợp để xây dựng các API backend cho web hoặc mobile app. Ví dụ: một ứng dụng thương mại điện tử có thể sử dụng API Gateway + AWS Lambda để xử lý các request như đăng nhập, thanh toán hay truy vấn sản phẩm. Thay vì phải dựng một server Node.js hoặc Django liên tục chạy, các hàm serverless sẽ chỉ được gọi khi người dùng gửi request. Framework như Serverless framework hoặc AWS SAM (Serverless Application Model) giúp lập trình viên dễ dàng triển khai, quản lý và mở rộng Serverless API. Điều này đặc biệt hữu ích cho các ứng dụng có lưu lượng biến động theo mùa như app đặt vé, flash sale.
 

Serverless API
 

3. Tích hợp IoT (Internet of Things)

Serverless là “cặp bài trùng” với IoT nhờ khả năng xử lý dữ liệu theo sự kiện từ hàng triệu thiết bị gửi về. Ví dụ: Trong hệ thống nhà thông minh, khi một cảm biến nhiệt độ gửi dữ liệu lên Azure Event Hub, nó có thể kích hoạt Azure Functions để kiểm tra và đưa ra phản hồi (bật/tắt điều hòa, gửi thông báo về app). 

Với Google Cloud Functions, dữ liệu từ IoT Core cũng có thể được xử lý tức thì. Các Serverless framework giúp đơn giản hóa việc quản lý event trigger từ hàng ngàn thiết bị IoT, đồng thời giảm tải chi phí so với việc duy trì server liên tục.

4. Ứng dụng real-time

Những ứng dụng yêu cầu xử lý và phản hồi tức thì như chatbot, thông báo đẩy (push notification) hay phân tích dữ liệu streaming cũng được hưởng lợi từ serverless. Với Serverless framework, developer chỉ cần định nghĩa sự kiện từ DynamoDB là hệ thống sẽ tự động triển khai toàn bộ pipeline xử lý real-time mà không cần setup thủ công.

5. Xử lý batch hoặc cron jobs

Mô hình này cũng rất mạnh trong việc thực thi các tác vụ lặp lại theo lịch trình. Thay vì duy trì server chỉ để chạy script hằng ngày, bạn có thể dùng AWS Lambda với CloudWatch Events hoặc Google Cloud Scheduler + Cloud Functions để thực thi cron jobs, ví dụ như gửi báo cáo định kỳ, dọn dẹp dữ liệu cũ hoặc backup dữ liệu sang storage. Với Serverless framework, việc cài đặt lịch chạy chỉ cần vài dòng cấu hình trong serverless.yml. Điều này vừa tiết kiệm chi phí, vừa giúp hệ thống linh hoạt hơn khi cần thay đổi lịch trình.
 

Serverless Framework
 

So sánh Serverless với các mô hình khác

Để quyết định có nên dùng mô hình điện toán không máy chủ cho dự án của mình hay không, bạn cần có cái nhìn tổng quan về Serverless so với các mô hình khác như Container/Kubernetes, PaaS và máy chủ/VM (IaaS).
 

Tiêu chí

Serverless (FaaS/BaaS)

Container / Kubernetes

PaaS (Heroku, App Engine, …)

Máy chủ / VM (IaaS)

Quản lý hạ tầng

Ẩn hoàn toàn; nhà cung cấp lo runtime, scale, cập nhật

Bạn quản lý image, networking; K8s hỗ trợ nhưng vẫn cần vận hành cụm.

Ẩn phần lớn; nhà cung cấp lo buildpack/runtime

Tự quản lý OS, middleware, cập nhật bảo mật

Khả năng mở rộng

Tự động, theo sự kiện, mượt ở mức hàm

Rất linh hoạt, scale theo pod/nút; cần cấu hình HPA/cluster

Auto-scale theo quy tắc nhà cung cấp

Tự cấu hình (manual/auto-scale group)

Mô hình tính phí

Pay-as-you-go, tính theo theo số lần gọi và thời gian chạy

Trả cho tài nguyên cấp sẵn (node/CPU/RAM) dù nhàn rỗi

Thường theo dyno/instance giờ chạy

Trả theo kích thước VM/giờ chạy

Chi phí khi nhàn rỗi

~0 (không gọi = không tốn)

Có (node vẫn chạy)

Có (dyno/instance vẫn chạy)

Có (VM luôn chạy)

Độ trễ

Có thể bị cold start (ms→giây)

Ổn định, ít biến động

Tương đối ổn định

Ổn định nhất

Cold start

Có, đặc trưng của FaaS

Không (container luôn sẵn)

Ít khi xảy ra

Không

Giới hạn thực thi

Có (thời gian, bộ nhớ, kích thước gói, concurrency)

Linh hoạt; giới hạn do cluster/resources

Có nhưng rộng rãi hơn FaaS

Ít giới hạn (tuỳ cấu hình)

Tác vụ chạy dài / stateful

Không phù hợp (thiết kế stateless, timeouts)

Phù hợp (job dài, worker, stateful qua PV)

Tương đối (tùy dịch vụ)

Phù hợp

Tùy biến môi trường

Thấp - trung bình (runtime được hỗ trợ)

Rất cao (toàn quyền trong image)

Trung bình (theo buildpack/runtime)

Rất cao (toàn hệ thống)

Tốc độ phát triển

Rất nhanh cho MVP & event-driven

Nhanh nếu có nền tảng DevOps tốt

Nhanh (DX thân thiện)

Chậm hơn (nhiều việc hạ tầng)

Độ phức tạp vận hành (DevOps)

Thấp

Cao (cluster, mạng, bảo mật, cập nhật)

Thấp - Trung bình

Trung bình - Cao

Trường hợp phù hợp

API sự kiện, tác vụ ngắn, bursty traffic, cron

Microservices, workload ổn định/dài, CI/CD bài bản

Web app tiêu chuẩn, API ổn định

Ứng dụng legacy, yêu cầu hệ thống đặc thù

Ví dụ dịch vụ/công cụ

AWS Lambda, Azure Functions, GCP Cloud Functions; BaaS: Firebase, Cognito, S3

Docker, Kubernetes, EKS/AKS/GKE, Helm, ArgoCD

Heroku, AWS Elastic Beanstalk, GAE, Render, Fly.io

AWS EC2, Azure VM, GCE; Ansible, Terraform

Chi phí dự kiến theo lưu lượng biến động

Rất tối ưu (trả theo dùng)

Có thể cao nếu over-provision

Khá ổn nhưng vẫn trả tiền “chờ”

Có thể lãng phí nếu nhàn rỗi nhiều

 

Xu hướng phát triển của Serverless trong tương lai

Những hạn chế hiện tại của Serverless như cold start, giới hạn runtime, vendor lock-in đều đang được khắc phục nhờ các xu hướng công nghệ mới. Trong tương lai, Serverless không chỉ là công cụ triển khai API nhỏ, mà sẽ trở thành mảnh ghép cốt lõi trong hạ tầng công nghệ hiện đại, đặc biệt ở các lĩnh vực AI, big data, IoT, edge computing và hybrid cloud.

- Giảm thiểu độ trễ và cold start: Các nhà cung cấp dịch vụ cloud (AWS, Azure, GCP) đang đầu tư vào cơ chế provisioned concurrency và tối ưu hạ tầng để hạn chế cold start, tối ưu runtime. Xu hướng này giúp serverless trở nên phù hợp hơn với các ứng dụng real-time như trò chuyện trực tuyến, game hoặc tài chính.

- Hỗ trợ workload dài hạn và đa dạng hơn: Hiện nay, serverless thường bị giới hạn về thời gian chạy, bộ nhớ và mức độ song song. Trong tương lai, các giới hạn này sẽ được nới lỏng để hỗ trợ workload dài hơi và phức tạp hơn, chẳng hạn như xử lý dữ liệu lớn (big data), phân tích video, hoặc AI/ML training ở quy mô nhỏ đến trung bình. Điều này mở ra cánh cửa cho nhiều doanh nghiệp đưa các tác vụ nặng lên serverless.

- Tích hợp sâu với AI và Machine Learning: Serverless sẽ ngày càng trở thành “công cụ nền” để triển khai AI inference theo sự kiện. Ví dụ: khi có ảnh/video tải lên, hàm serverless tự động kích hoạt mô hình AI để phân tích hoặc gợi ý kết quả. Các Serverless framework thế hệ mới cũng sẽ hỗ trợ tích hợp model AI trực tiếp trong pipeline xử lý, giúp quá trình triển khai AI đơn giản và linh hoạt hơn.
 

Xu hướng Serverless


- Serverless + Container (Hybrid): Đây là một xu hướng rõ rệt giúp doanh nghiệp linh hoạt hơn khi xây dựng hệ thống microservices quy mô lớn. Các công nghệ như Knative (trên Kubernetes) hay AWS Fargate cho phép triển khai container dưới dạng serverless, kết hợp khả năng tùy biến cao của container với sự tiện lợi và tiết kiệm chi phí của serverless.

- Multi-cloud và open-source serverless: Để giảm thiểu tình trạng vendor lock-in, nhiều tổ chức sẽ hướng đến sử dụng nhiều nền tảng cloud song song (multi-cloud) hoặc chọn giải pháp serverless mã nguồn mở như OpenFaaS, Kubeless, Knative. Nhờ đó, doanh nghiệp có thể chủ động hơn trong việc triển khai, đồng thời tránh phụ thuộc vào một nhà cung cấp duy nhất.

Mở rộng trong lĩnh vực IoT và Edge Computing: Serverless sẽ không chỉ chạy trên cloud trung tâm mà còn mở rộng đến edge - các node biên mạng gần người dùng hoặc ngay trên thiết bị IoT. Ví dụ: dữ liệu từ cảm biến có thể được xử lý ngay tại edge bằng serverless để giảm độ trễ, sau đó chỉ gửi dữ liệu cần thiết về cloud. Đây là xu hướng tất yếu trong các lĩnh vực nhà thông minh, xe tự lái hay giám sát an ninh.

 

Nền tảng Serverless


Qua bài viết của Phương Nam Vina, Serverless đang thay đổi cách chúng ta xây dựng và vận hành ứng dụng từ việc tối ưu chi phí, tự động mở rộng, rút ngắn thời gian triển khai cho đến việc mở ra không gian mới cho AI, IoT, edge computing và hybrid cloud. Dù vẫn còn tồn tại một số hạn chế như cold start, giới hạn tài nguyên hay nguy cơ vendor lock-in nhưng chính những thách thức này lại là động lực để các nhà cung cấp dịch vụ cloud không ngừng cải tiến. Đối với doanh nghiệp và lập trình viên, việc nắm bắt xu hướng serverless ngay từ bây giờ chính là chìa khóa để tăng tốc đổi mới, tối ưu vận hành và tạo lợi thế cạnh tranh bền vững trong kỷ nguyên số.

Tham khảo thêm:

icon thiết kế website Platform là gì? Top 10 loại hình platform phổ biến nhất

icon thiết kế website MVC là gì? Tất tần tật về mô hình MVC trong lập trình web

icon thiết kế website Entity Framework là gì? Từ A - Z về Entity Framework Core

Bài viết mới nhất

Headless CMS là gì? Những điều cần biết về Headless CMS

Headless CMS là gì? Những điều cần biết về Headless CMS

Headless CMS là giải pháp linh hoạt, đa kênh và hiệu năng cao, phù hợp doanh nghiệp muốn nâng trải nghiệm người dùng và mở rộng website lâu dài.

Flush DNS là gì? Cách flush DNS trên Windows, macOS và Linux

Flush DNS là gì? Cách flush DNS trên Windows, macOS và Linux

DNS Flush Google giúp làm mới bộ nhớ đệm DNS, khắc phục nhanh lỗi mạng, tăng tốc độ truy cập trang web và đảm bảo kết nối Internet luôn ổn định.

 
Cấu trúc HTML cơ bản: Nền tảng đầu tiên để xây dựng website

Cấu trúc HTML cơ bản: Nền tảng đầu tiên để xây dựng website

Nắm vững cấu trúc HTML không chỉ giúp website đẹp, chuyên nghiệp mà còn nâng cao hiệu quả SEO, trải nghiệm người dùng và khả năng phát triển lâu dài.

Lỗi 413 request entity too large là gì? Nguyên nhân & cách xử lý

Lỗi 413 request entity too large là gì? Nguyên nhân & cách xử lý

Lỗi 413 request entity too large tuy khá phổ biến nhưng hoàn toàn có thể xử lý và phòng tránh nếu bạn nắm rõ nguyên nhân cũng như cách khắc phục.

Typography là gì? Nguyên tắc typography trong thiết kế website

Typography là gì? Nguyên tắc typography trong thiết kế website

Chỉ với vài thay đổi nhỏ về typography, website của bạn có thể trở nên hiện đại, dễ tiếp cận hoặc ngược lại, mất điểm ngay từ cái nhìn đầu tiên.

Khắc phục lỗi Sorry you are not allowed to access this page

Khắc phục lỗi Sorry you are not allowed to access this page

Lỗi Sorry you are not allowed to access this page thường xảy ra khi WordPress chặn bạn vì tài khoản không đủ quyền hoặc do website gặp lỗi cấu hình.

 
zalo