Cấu trúc phụ trợ cho phần phụ trợ ứng dụng web hướng nội dung

Cấu trúc phần phụ trợ là cách cấu trúc phần phụ trợ của ứng dụng web. Cấu trúc phụ trợ xác định cách các phần của ứng dụng giao tiếp với nhau để xử lý các yêu cầu đến và tạo phản hồi. Khi xây dựng một ứng dụng web, hãy chọn một cấu trúc phụ trợ dựa trên các yêu cầu và yếu tố cụ thể, bao gồm cả chi phí (cả hiện tại và trên quy mô lớn), độ phức tạp của ứng dụng, mục tiêu mở rộng quy mô và chuyên môn của nhóm.

Đặc biệt đối với các ứng dụng web hướng đến nội dung, chẳng hạn như thương mại điện tử, báo chí hoặc blog, các yêu cầu quan trọng bao gồm tính nhất quán của dữ liệu và hiệu suất, đặc biệt là khi ứng dụng của bạn phát triển ra quy mô toàn cầu và có thể trở nên phân phối nhiều hơn. Đối với các ứng dụng web dựa trên nội dung, bộ nhớ dữ liệu mà ứng dụng của bạn dùng cũng rất quan trọng và sẽ được thảo luận chi tiết hơn trong hướng dẫn về bộ nhớ dữ liệu. Khi tối ưu hoá hiệu suất của ứng dụng, việc không chỉ dựa vào cấu trúc ứng dụng thông thường, mà còn lưu trữ và giúp người dùng dễ tiếp cận nội dung đó là những việc quan trọng. Tìm hiểu thêm về cách chọn chiến lược lưu trữ phù hợp và tối ưu hoá ứng dụng của bạn trong hướng dẫn lưu trữ.

Nếu bạn đã có sẵn một phần phụ trợ cho một ứng dụng web, hãy xem xét các giới hạn của cấu trúc hiện tại. Ví dụ: khi ứng dụng của bạn mở rộng quy mô và đòi hỏi hiệu suất cũng như độ tin cậy tăng lên, hãy cân nhắc xem có nên tái cấu trúc hoặc chuyển các phần của ứng dụng sang một cấu trúc khác phù hợp hơn với quy mô tăng thêm của bạn hay không. Ví dụ: Cấu trúc kết hợp (hoặc nhiều đám mây) cho phép bạn chuyển một số tải công việc sang đám mây trước khi thực hiện quá trình chuyển đổi hoàn chỉnh. Việc cân nhắc chi phí, thời gian và rủi ro liên quan đến quá trình di chuyển như vậy cũng là điều cần thiết.

Kiến trúc nguyên khối

Kiến trúc nguyên khối có cấu trúc thống nhất, trong đó tất cả thành phần của ứng dụng được tích hợp chặt chẽ vào một cơ sở mã duy nhất. Toàn bộ ứng dụng được xây dựng dưới dạng một đơn vị độc lập. Kiến trúc nguyên khối có nhiều lớp, trong đó các lớp khác nhau của ứng dụng thực hiện các tác vụ cụ thể.

Lớp kết cấu

  • Giao diện người dùng (UI), bao gồm các thành phần để trình bày các tính năng của ứng dụng, thường là một ứng dụng dựa trên nền tảng web hoặc máy tính để tương tác với người dùng.
  • Logic ứng dụng là nơi chứa chức năng cốt lõi.Phần này của cơ sở mã chứa các quy tắc, phép tính và toán tử xác định cách hoạt động của ứng dụng.
  • Lớp truy cập dữ liệu chứa các hàm để đọc và ghi dữ liệu, đồng thời dịch giữa cấu trúc dữ liệu của ứng dụng và giản đồ cơ sở dữ liệu. Lớp này chịu trách nhiệm tương tác với cơ sở dữ liệu hoặc kho lưu trữ dữ liệu của ứng dụng.
  • Cơ sở dữ liệu là nơi ứng dụng lưu trữ dữ liệu. Thường thì có một cơ sở dữ liệu duy nhất lưu trữ tất cả dữ liệu của ứng dụng, bao gồm cả dữ liệu người dùng, cấu hình và các thông tin khác.
  • Các thành phần phần mềm trung gian xử lý những công việc như xác thực, định tuyến yêu cầu và xác thực dữ liệu. Các thành phần này giúp quản lý luồng dữ liệu và yêu cầu.
  • Một số ứng dụng nguyên khối có điểm tích hợp với dịch vụ hoặc API bên ngoài. Những điểm này cho phép ứng dụng tương tác với dịch vụ bên thứ ba, nguồn dữ liệu hoặc các hệ thống khác.

Các lớp cấu trúc thường là một phần của một cơ sở mã. Cơ sở mã này chứa toàn bộ ứng dụng và thường được sắp xếp thành các thư mục, mô-đun và lớp. Các nhà phát triển xử lý nhiều phần của cơ sở mã để xây dựng và duy trì ứng dụng. Tuy nhiên, toàn bộ ứng dụng thường được triển khai dưới dạng một đơn vị duy nhất. Khi thực hiện cập nhật hoặc thay đổi, toàn bộ ứng dụng sẽ được triển khai lại.

Thách thức tiềm ẩn

  • Khi các ứng dụng nguyên khối phát triển, cơ sở mã có xu hướng trở nên phức tạp và khó duy trì. Điều này có thể dẫn đến chu kỳ phát triển dài và khó hiểu toàn bộ cơ sở mã.
  • Việc triển khai các thay đổi cho một ứng dụng nguyên khối có thể gây rủi ro vì những thay đổi được thực hiện trong một phần của mã có thể vô tình ảnh hưởng đến các phần khác của ứng dụng. Việc này có thể khiến quá trình triển khai sẽ mất nhiều thời gian và dễ xảy ra lỗi.
  • Các ứng dụng nguyên khối có thể khó mở rộng vì chúng được triển khai dưới dạng một đơn vị duy nhất. Bạn phải mở rộng toàn bộ ứng dụng ngay cả khi chỉ một thành phần trải nghiệm làm tăng nhu cầu.
  • Các ứng dụng đơn khối thường dựa vào một ngăn xếp công nghệ hoặc ngôn ngữ lập trình duy nhất, nên khả năng sử dụng công cụ tốt nhất cho một tác vụ cụ thể trong ứng dụng đó có thể bị hạn chế.
  • Ngay cả trong giai đoạn nhu cầu thấp, các ứng dụng nguyên khối vẫn đòi hỏi tài nguyên đáng kể để vận hành. Chi phí bảo trì cũng tăng theo thời gian của ứng dụng vì việc cập nhật và vá ứng dụng trở nên khó khăn hơn mà không gây ra hiện tượng hồi quy.
  • Các nhóm phát triển làm việc về các ứng dụng nguyên khối thường được tổ chức xoay quanh toàn bộ ứng dụng. Điều này dẫn đến các nhóm lớn hơn và hoạt động phối hợp phức tạp hơn giữa các thành viên trong nhóm.

Cách sử dụng được đề xuất

Kiến trúc đơn khối phù hợp khi một ứng dụng có yêu cầu khiêm tốn và nhóm phát triển có quy mô nhỏ. Khi một ứng dụng phát triển về độ phức tạp và quy mô hoặc khi các phần khác nhau của ứng dụng yêu cầu công nghệ hoặc chiến lược triển khai khác nhau, các cấu trúc nguyên khối có thể trở nên kém linh hoạt và khó duy trì hơn.

Bạn có thể tạo và quản lý các máy ảo có thể chạy các ứng dụng nguyên khối trên Compute Engine. Bạn có toàn quyền kiểm soát hệ điều hành, phần mềm và quản lý các máy ảo này để chạy ứng dụng nguyên khối của mình.

Với dịch vụ nền tảng dưới dạng dịch vụ, chẳng hạn như App Engine, bạn có thể xây dựng ứng dụng và chạy ứng dụng trên cơ sở hạ tầng được quản lý toàn diện và tự động mở rộng quy mô theo các yêu cầu.

Nếu ứng dụng nguyên khối của bạn được đưa vào vùng chứa, bạn có thể chạy ứng dụng đó bằng Google Kernetes Engine (GKE) hoặc Cloud Run. Bạn có thể dùng các dịch vụ như Cloud SQL hoặc Cloud Spanner để lưu trữ dữ liệu cho các ứng dụng nguyên khối. Hãy cân nhắc việc kết hợp các dịch vụ và hệ thống dựa trên các yêu cầu cụ thể của ứng dụng.

Kiến trúc không máy chủ

Khi sử dụng cấu trúc không máy chủ, bạn có thể xây dựng và chạy các ứng dụng mà không cần quản lý máy chủ thực hoặc máy chủ ảo. Nhà cung cấp dịch vụ đám mây tự động quản lý cơ sở hạ tầng, việc mở rộng quy mô và phân bổ tài nguyên để các nhà phát triển có thể tập trung vào việc viết mã cho ứng dụng của họ. Các cấu trúc không máy chủ có thể đơn giản hoá quá trình phát triển, giảm chi phí vận hành và tối ưu hoá chi phí bằng cách loại bỏ nhu cầu bảo trì máy chủ. Chúng rất phù hợp với các dịch vụ vi mô, xử lý dữ liệu theo thời gian thực, các ứng dụng web có khối lượng công việc thay đổi và xử lý sự kiện.

Cấu trúc không máy chủ dựa trên sự kiện

Kiến trúc không máy chủ dựa trên sự kiện là một loại cấu trúc điện toán không máy chủ cụ thể, dựa vào các sự kiện hoặc điều kiện kích hoạt để bắt đầu thực thi các hàm hoặc vi dịch vụ. Các thành phần hệ thống giao tiếp thông qua các sự kiện và các hàm được gọi để phản hồi các sự kiện đó. Các hàm này thường dựa vào hoạt động giao tiếp không đồng bộ vì các hàm được kích hoạt bởi các sự kiện, sau đó xử lý chúng một cách độc lập, và có thể tạo ra các sự kiện kích hoạt các hành động tiếp theo. Loại cấu trúc không máy chủ này là một lựa chọn phù hợp để xây dựng các hệ thống có thể mở rộng, thích ứng và kết nối lỏng lẻo.

Google Cloud FunctionsCloud Function for Firebase cho phép bạn xây dựng và triển khai các hàm dựa trên sự kiện trong môi trường không có máy chủ và được quản lý hoàn toàn. API này cho phép bạn chạy mã để phản hồi nhiều sự kiện và điều kiện kích hoạt, bao gồm cả yêu cầu HTTP, thông báo trên Cloud Pub/Sub, các thay đổi của Google Cloud Storage, nội dung cập nhật về Cơ sở dữ liệu theo thời gian thực của Firebase mà không cần quản lý cơ sở hạ tầng. Các tính năng chính bao gồm hỗ trợ nhiều ngôn ngữ, khả năng có thể mở rộng, thanh toán chi tiết, tích hợp với bên thứ ba, ghi nhật ký và giám sát hiệu quả, cũng như tích hợp với các dịch vụ khác của Google và Firebase.

Kiến trúc không máy chủ có thể mang lại hiệu quả về mặt chi phí trong nhiều trường hợp sử dụng, đặc biệt là đối với các ứng dụng có khối lượng công việc thay đổi, nhu cầu phát triển nhanh chóng và lưu lượng truy cập không thể dự đoán. Độ tin cậy phụ thuộc vào nhà cung cấp dịch vụ đám mây, với các thoả thuận mức độ cung cấp dịch vụ (SLA) có sẵn để đảm bảo các mục tiêu cụ thể về hiệu suất và độ tin cậy. Bạn phải đánh giá trường hợp sử dụng và các yêu cầu cụ thể để xác định xem cấu trúc không máy chủ có phải là lựa chọn tốt nhất hay không.

Chuyên chở bằng công ten nơ

Phương thức vùng chứa cho phép các ứng dụng và phần phụ thuộc của ứng dụng đó được đóng gói vào các vùng chứa nhẹ và di động được. Các giải pháp này cung cấp một môi trường ứng dụng nhất quán, hỗ trợ việc phát triển và triển khai trên nhiều hệ thống và nền tảng. Một số nền tảng không máy chủ có thể chạy tải công việc trong vùng chứa. Việc chạy các vùng chứa trong môi trường không máy chủ có thể có lợi khi bạn có khối lượng công việc phức tạp hoặc có trạng thái không thể biểu thị dưới dạng hàm cơ bản. Giải pháp này mang lại tính linh hoạt về mặt hỗ trợ ngôn ngữ và môi trường thời gian chạy.

Cloud Run là một nền tảng điện toán không máy chủ, cho phép các nhà phát triển triển khai và chạy các ứng dụng trong vùng chứa trong một môi trường được quản lý toàn diện. Đây là cách thức đơn giản để xây dựng, triển khai và mở rộng quy mô của ứng dụng mà không cần quản lý cơ sở hạ tầng cơ bản. Giải pháp này phù hợp với nhiều ứng dụng web và dịch vụ vi mô, đặc biệt là những ứng dụng có tải công việc thay đổi, và trong đó việc chứa vùng chứa mang lại nhiều lợi ích về việc đóng gói ứng dụng và tính nhất quán.

Kiến trúc vi dịch vụ

Các ứng dụng được chia thành các phần nhỏ được kết nối lỏng lẻo và triển khai các tính năng hoặc chức năng riêng biệt. Các dịch vụ này có thể giao tiếp thông qua các thông báo không đồng bộ, các kênh dựa trên sự kiện hoặc trực tiếp bằng cách hiển thị một giao diện. Mỗi dịch vụ được phát triển, kiểm thử và mở rộng một cách độc lập trong vùng chứa của dịch vụ đó. Thường được quản lý thông qua dịch vụ điều phối, chẳng hạn như Kubernetes, hoặc được triển khai bằng một nền tảng được quản lý như Cloud Run.

Việc triển khai dịch vụ vi mô cũng thường tận dụng mô hình ứng dụng không máy chủ bằng cách không dựa vào một máy chủ tập trung.

Việc phân tách một ứng dụng thành các dịch vụ tự chủ có thể giúp đơn giản hoá một hệ thống phức tạp. Các ranh giới và mục tiêu được xác định rõ ràng có thể đẩy nhanh tốc độ phát triển và cải thiện khả năng bảo trì. Mỗi dịch vụ vi mô có thể được phát triển độc lập bằng cách sử dụng các khung hoặc công cụ hiệu quả nhất. Hoạt động giao tiếp giữa các dịch vụ thường được xử lý bằng sự kiện, thông tin liên lạc xuất bản-đăng ký, quy trình thông báo hoặc các lệnh gọi quy trình từ xa như gRPC.

Để điều phối các tác vụ trong một cấu trúc vi dịch vụ, hãy cân nhắc sử dụng một khung hỗ trợ các nền tảng mà bạn đang nhắm đến, đủ chiều sâu cho các tác vụ và loại quy trình làm việc mà bạn đang sắp xếp, cũng như xử lý lỗi và đo từ xa để gỡ lỗi. Các lựa chọn phổ biến bao gồm Người dẫn chương trình hoặc các sản phẩm/dịch vụ của một nhà cung cấp dịch vụ đám mây, chẳng hạn như Quy trình làm việc của Google.

Các ứng dụng dựa trên dịch vụ vi mô có thể rất phức tạp khi phát triển và duy trì do tính chất phân tán và nhu cầu giao tiếp trong các dịch vụ. Do đó, việc quản lý việc triển khai, giám sát và ghi nhật ký phức tạp hơn so với các tuỳ chọn cấu trúc khác. Vì độ tin cậy phụ thuộc vào cấu trúc của từng dịch vụ riêng lẻ, nên tính chất phân tán có thể mang lại khả năng thích ứng cao hơn, đặc biệt là khi triển khai và bật tính năng giám sát và đo từ xa nếu cần.

So sánh các cấu trúc khác nhau của phần phụ trợ ứng dụng web dựa trên nội dung

Bảng sau đây so sánh các cấu trúc với các yêu cầu chính đối với phần phụ trợ của ứng dụng web dựa trên nội dung.

Kiến trúc nguyên khối Kiến trúc dựa trên sự kiện, không máy chủ Kiến trúc không máy chủ, dịch vụ vi mô
Tính phức tạp và việc bảo trì
  • Dễ dàng triển khai cho các dự án nhỏ, độc lập nhưng độ phức tạp sẽ tăng lên theo quy mô.
  • Cần phải bảo trì và điều phối theo cách thủ công.
  • Việc mở rộng quy mô được hỗ trợ tốt và tích hợp vào nền tảng.
  • Việc khắc phục sự cố và gỡ lỗi có thể khó khăn.
  • Không cần quản lý cơ sở hạ tầng.
  • Các dịch vụ độc lập được kiểm thử và triển khai độc lập giúp việc bảo trì từng thiết bị trở nên dễ dàng hơn.
  • Yêu cầu giao tiếp cẩn thận giữa các dịch vụ.
  • Cần có công cụ quản lý và sắp xếp để quản lý trên quy mô lớn hơn.
Khả năng mở rộng và hiệu suất
  • Hiệu quả ở quy mô nhỏ, khó mở rộng ra ngoài một quy mô cụ thể.
  • Nhu cầu cụ thể về cơ sở hạ tầng, giới hạn các lựa chọn điều chỉnh theo tỷ lệ động.
  • Mở rộng quy mô theo cách thủ công (hoặc sử dụng dịch vụ thủ công) trong cấu trúc, chẳng hạn như bằng cách cân bằng tải.
  • Mỗi dịch vụ đều được điều chỉnh theo một nhu cầu cụ thể và có thể được mở rộng và tối ưu hoá một cách độc lập.
Chiến lược phục hồi và dự phòng
  • Việc triển khai phức tạp và có thể dẫn đến thời gian ngừng hoạt động ("tất cả hoặc không có gì").
  • Vốn có của nhà cung cấp dịch vụ đám mây.
  • Mỗi hàm độc lập có thể được thử lại một cách độc lập.
  • Mỗi dịch vụ đều độc lập, giúp hệ thống nói chung trở nên bền bỉ hơn thông qua quá trình kiểm thử và phát triển độc lập.
Trải nghiệm phát triển
  • Phát triển nhanh trên quy mô nhỏ thông qua việc ghép nối chặt chẽ cấu trúc (ví dụ: thông qua các truy vấn hiệu quả).
  • Thời gian xây dựng lâu và thử nghiệm cũng như cộng tác khó khăn khi mức độ phức tạp tăng lên.
  • Không có cơ sở hạ tầng để duy trì và quản lý, giúp phát triển nhanh hơn.
  • Việc kiểm thử và gỡ lỗi ứng dụng đang hoạt động sẽ tuỳ thuộc vào các dịch vụ của nhà cung cấp dịch vụ đám mây.
  • Các dịch vụ độc lập và có thể được phát triển độc lập.
  • Một số lượng lớn dịch vụ cần được điều phối và quản lý.
Chi phí
  • Quá trình phát triển phức tạp có thể làm tăng chi phí.
  • Đòi hỏi đáng kể đầu tư vào phần cứng hoặc cơ sở hạ tầng, đặc biệt là ở quy mô lớn hơn.
  • Rất khó để hiện thực hoá mức hiệu quả chi phí từ việc tăng và giảm.
  • Không tốn phí chuyên dụng cho phần cứng.
  • Tăng và giảm quy mô để tối ưu hoá việc sử dụng tài nguyên và chi phí (giảm về 0).
  • Không tốn phí chuyên dụng cho phần cứng.
  • Mở rộng quy mô để tối ưu hoá việc sử dụng tài nguyên và chi phí trong phạm vi giới hạn.
  • Chi phí bổ sung từ việc giám sát và quản lý một nhóm nhiều dịch vụ độc lập.

Tìm hiểu thêm về cấu trúc phụ trợ cho các ứng dụng web dựa trên nội dung

Dưới đây là một số tài nguyên để tìm hiểu thêm về cấu trúc của ứng dụng web dựa trên nội dung, bao gồm cả cách di chuyển ứng dụng của bạn sang một cấu trúc khác: