051.2 Bài 1

Tại một thời điểm nào đó khi sử dụng các hệ thống trực tuyến, rất có thể người dùng nào cũng đều đã gặp phải thông báo giống như Màn hình mẫu hiển thị khi phản hồi đang được tiến hành.

Hãy cùng nhìn lại và xem xét bối cảnh nơi chúng ta đã nhìn thấy thông báo này. Giả sử khi chúng ta đang cố gắng truy cập vào tài khoản ngân hàng của mình thông qua trang web ngân hàng. Khi truy cập trang web ngân hàng trên máy tính xách tay của mình, chúng ta sẽ sử dụng một loại phần mềm (tức là ứng dụng) được gọi là trình duyệt web (chẳng hạn như Google Chrome hay Firefox). Trong trường hợp này, trình duyệt trên máy tính của chúng ta sẽ gửi yêu cầu đến một máy tính khác lưu trữ trang web này. Loại máy tính đặc biệt này được gọi là máy chủ. Nó được thiết kế đặc biệt để hoạt động 24/7 nhằm phục vụ các yêu cầu mới đến từ khắp mọi nơi trên thế giới.

Như vậy có nghĩa là máy chủ chính là một máy tính giống như máy tính chúng ta sử dụng để làm việc, chơi trò chơi điện tử và thực hiện các bài tập lập trình. Tuy nhiên, có một điểm khác biệt chính là máy chủ thường sử dụng tất cả tài nguyên của nó cho ứng dụng phần mềm chạy trên nó. Trong ví dụ này, phần mềm là một ứng dụng web - một chương trình máy tính chạy trên máy chủ.

Trong Màn hình mẫu hiển thị khi phản hồi đang được tiến hành, máy chủ đã nhận được yêu cầu từ trình duyệt và ứng dụng đang chạy trên máy chủ đang xử lý thao tác kết quả. Hoạt động này có thể truy vấn một cơ sở dữ liệu để lấy thông tin chi tiết của người dùng trong ngân hàng hoặc liên lạc với một máy chủ khác để xác minh mức chiết khấu đặc biệt cho khoản vay tiếp theo của người dùng.

Trong ví dụ này, chúng ta sẽ gọi trình duyệt đang chạy trên máy của chúng ta là ứng dụng khách, hay nói một cách đơn giản là máy khách. Máy khách sẽ tương tác với máy chủ từ xa.

Giao tiếp mạng giữa máy khách và máy chủ có thể diễn ra bên trong một mạng doanh nghiệp hoặc trên mạng toàn cầu mà chúng ta gọi là internet. Đặc điểm chung của tương tác giữa máy khách và máy chủ là máy chủ có thể thiết lập nhiều mối quan hệ với nhiều máy khách. Hãy nghĩ về ví dụ trước: trang web của một ngân hàng được lưu trữ trên máy chủ có thể đáp ứng hàng nghìn yêu cầu mỗi phút từ nhiều điểm, mỗi điểm đều có người dùng đang cố gắng truy cập vào tài khoản ngân hàng cá nhân của họ.

Không phải trường hợp nào cũng đều sẽ có cấu trúc giống như một trình duyệt tương tác với một máy chủ thực hiện hầu hết mọi tiến trình xử lý. Trong một số trường hợp, máy khách có thể sẽ là thành phần xử lý chính; khái niệm này được gọi là máy khách cấu hình tối đa (fat client hay thick client). Trong đó, máy khách sẽ lưu trữ và xử lý phần lớn các tác vụ thay vì dựa vào tài nguyên của máy chủ. Ngược lại, trong ví dụ về ngân hàng, trình duyệt lại là một máy khách cấu hình tối thiểu (thin client) sẽ dựa vào máy chủ để tính toán và trả về thông tin qua mạng.

Một ví dụ về máy khách cấu hình tối đa là ứng dụng trò chơi điện tử trên máy tính để bàn. Trong đó, phần lớn việc lưu trữ và xử lý dữ liệu sẽ được thực hiện cục bộ sử dụng GPU, RAM, CPU và dung lượng ổ đĩa của máy tính để xử lý thông tin. Ứng dụng như vậy hiếm khi dựa vào máy chủ bên ngoài, đặc biệt nếu đó là trò chơi ngoại tuyến.

Cả hai cách tiếp cận đều có ưu và nhược điểm: Đối với máy khách cấu hình tối đa, tính ổn định của mạng không phải là vấn đề so với máy khách cấu hình tối thiểu dựa trên máy chủ từ xa, nhưng việc cập nhật phần mềm có thể khó áp dụng hơn và máy khách cấu hình tối đa sẽ yêu cầu nhiều tài nguyên máy tính hơn. Đối với một máy khách cấu hình tối thiểu, tiêu hao thấp hơn chính là một lợi thế lớn. Đối với cả hai loại máy khách, việc cung cấp dữ liệu cá nhân cho ứng dụng của bên thứ ba có thể sẽ trở thành vấn đề.

Ứng dụng web là phần mềm chạy trên máy chủ, xử lý các tương tác của người dùng và được liên hệ với máy khách cấu hình tối đa thông qua một mạng máy tính. Không phải tất cả các trang web đều được coi là ứng dụng web: các trang web tĩnh đơn giản không có tính tương tác không được coi là ứng dụng web vì máy chủ không chạy ứng dụng để xử lý các hành động do máy khách yêu cầu.

Có nhiều ứng dụng web có thể được chia thành hai nhóm: ứng dụng một trang (SPA) và ứng dụng đa trang (MPA). SPA chỉ có một trang web nơi tất cả việc trao đổi và tải dữ liệu diễn ra mà không cần chuyển hướng người dùng đến một trang web khác bên trong ứng dụng. Một MPA, trái ngược với SPA, sẽ có nhiều trang web. Một phiên thay đổi dữ liệu có thể làm mới cùng một trang web bắt nguồn của hành động hoặc chuyển hướng người dùng đến một trang web khác.

Xét trong ví dụ trước khi người dùng muốn kiểm tra các giao dịch tài khoản gần đây nhất của họ trên trang web ngân hàng trực tuyến. Hãy tưởng tượng rằng một giao dịch sẽ xảy ra sau khi trang web được tải. Nếu ứng dụng web ngân hàng là SPA, giao dịch mới sẽ tự động được hiển thị trên cùng một trang web mà không chuyển hướng người dùng đến một trang mới. Nếu người dùng muốn kiểm tra khoản vay của mình, thông tin mới cũng sẽ được hiển thị trên cùng một trang để tránh việc phải chuyển hướng người dùng đến một trang web mới. Việc thay đổi trang mà không chuyển hướng người dùng sẽ giúp việc điều hướng trở nên mượt mà hơn.

Đối với MPA, khi người dùng yêu cầu trang web về khoản vay, máy chủ sẽ phải chuyển hướng người dùng đến một vị trí mới - tức là một trang web khác.

Một ví dụ rất nổi tiếng về ứng dụng web SPA chính là Google Mail (Gmail). Nó sẽ không chuyển hướng người dùng đến các trang hoàn toàn mới (ví dụ khi người dùng muốn hiển thị thư mục thư rác); ứng dụng sẽ chỉ đơn giản là làm mới các khu vực cụ thể của màn hình hiển thị nơi hiển thị tất cả các tin nhắn rác trong khi vẫn ở lại trên một trang web đó.

Trái lại, một ứng dụng MPA nổi tiếng chính là Amazon.com - một gã khổng lồ trong lĩnh vực thương mại điện tử - với mỗi một mặt hàng đều được đặt trên một trang web riêng biệt.

Một lợi thế của MPA so với SPA là dễ dàng thu thập và đo lường dữ liệu phân tích trang web. Điều này rất quan trọng trong việc giúp các nhà phát triển tối ưu hóa các kết quả tìm kiếm trên internet.

Thông thường, một ứng dụng web sẽ được chia thành hai phần riêng biệt: giao diện người dùng (frontend) và giao diện máy chủ (backend). Giao diện người dùng là tầng xem nơi người dùng tương tác với trình duyệt bằng cách sử dụng các thành phần trang với các thao tác nhấp, chọn hoặc nhập. Đây là nơi dữ liệu từ máy chủ sẽ được nhận, định dạng và hiển thị cho người dùng thông qua trình duyệt.

Giao diện máy chủ thường chiếm phần lớn hơn trong ứng dụng web. Nó bao gồm logic nghiệp vụ, bộ xử lý giao tiếp, phần lớn việc xử lý dữ liệu và lưu trữ dữ liệu. Lưu trữ dữ liệu sẽ sử dụng một hệ thống quản lý cơ sở dữ liệu riêng biệt được kết nối với giao diện máy chủ.

Giao diện người dùng và giao diện máy chủ sẽ giao tiếp với nhau. Các yêu cầu dữ liệu sẽ được giao diện người dùng chuyển tiếp đến giao diện máy chủ và dữ liệu do máy chủ trả về sẽ được giao diện người dùng nhận, định dạng và hiển thị cho người dùng.

Trong ví dụ đơn giản của chúng ta về việc tìm nạp giao dịch mới nhất trong tài khoản ngân hàng của người dùng, hành động này được diễn giải bởi giao diện người dùng của ứng dụng đang chạy trong trình duyệt trên màn hình của người dùng. Yêu cầu này sau đó được gửi qua internet đến máy chủ của ứng dụng, xác thực xem người dùng có được phép thực hiện hành động hay không, tìm nạp dữ liệu và trả danh sách giao dịch trở lại giao diện người dùng được tải trong trình duyệt. Trình duyệt sau đó sẽ định dạng và hiển thị dữ liệu cho người dùng.

Không có phần mềm hữu ích nào là không giao tiếp với các thành phần bên trong và bên ngoài. Vậy làm thế nào để máy khách có thể giao tiếp với ứng dụng web? Làm cách nào giao diện người dùng có thể gửi dữ liệu đến máy chủ?

Các ứng dụng phần mềm giao tiếp với nhau thông qua giao diện lập trình ứng dụng (API) chạy trên các giao thức giao tiếp internet cơ bản. Các giao thức là các tiêu chuẩn và quy tắc được phát triển để đảm bảo rằng hai hoặc nhiều ứng dụng có thể trao đổi lệnh và dữ liệu.

Lợi ích chính của API là tách rời các phần khác nhau của ứng dụng, đồng thời cho phép chúng hợp tác với nhau để xử lý dữ liệu. API cũng tập trung luồng dữ liệu vào các kênh được xác định trước, hoạt động giống như một chiếc cổng có trách nhiệm đảm bảo rằng mọi thứ đều đến và đi bằng cùng một cách. Trong các ứng dụng web, API rất quan trọng đối với chức năng của ứng dụng vì chúng cho phép người dùng tương tác, cung cấp thông tin đã xử lý, yêu cầu lưu trữ dữ liệu và nhiều tác vụ khác. Ví dụ: khách hàng có thể sử dụng API để yêu cầu các hành động sẽ được thực thi trên máy chủ.

Hãy quay lại ví dụ về ứng dụng web ngân hàng. Để đăng nhập vào tài khoản thông qua ứng dụng web, người dùng thường sẽ nhập dữ liệu như tên người dùng và mật khẩu vào các trường văn bản nhất định và nhấp vào nút “Đăng nhập”. Trình duyệt sẽ lấy thông tin này và gọi một API máy chủ. Ứng dụng web chạy trên máy chủ từ xa sẽ nhận dữ liệu người dùng, xác thực người dùng, xác minh quyền truy cập của người dùng và cuối cùng gửi phản hồi trở lại trình duyệt. Để người dùng có thể giao tiếp với máy chủ, bắt buộc cả máy khách và máy chủ đều phải gửi dữ liệu qua lại. Đây chính là những gì API cho phép.

Có thể thấy được ứng dụng web của ngân hàng sẽ không để lộ các thông tin nhạy cảm khác; nó sẽ chỉ hiển thị cho người dùng các trường được phép và cần thiết cho tương tác mong muốn. Phần còn lại đều sẽ được ẩn đối với người dùng.

Giao tiếp giữa các API có thể dựa trên các thiết kế và giao thức rất khác nhau. Giao thức truyền siêu văn bản (HTTP) cho đến nay là giao thức được sử dụng thường xuyên nhất trong các ứng dụng web. Siêu văn bản là văn bản có liên kết đến các văn bản khác, đây là khái niệm nền tảng của các liên kết trong trang web HTML. Từ đây, các siêu liên kết sẽ tạo thành cơ sở để xây dựng các trang web và hiển thị chúng trong trình duyệt.

HTTP được thiết kế cho các ứng dụng máy khách-máy chủ nơi tài nguyên được yêu cầu từ máy chủ và sau đó được trả về máy khách qua mạng bằng cấu trúc được xác định trước do giao thức HTTP chỉ định.

Đối với một ứng dụng web có cấu trúc, các kỹ sư phần mềm sẽ thiết kế ứng dụng với các phần hoặc mô-đun riêng biệt. Sự phân tách trách nhiệm này cho phép các tác vụ và trách nhiệm được xác định rõ ràng, tạo điều kiện cho việc phát triển nhanh hơn và bảo trì tốt hơn.

Hãy lấy ví dụ về một ứng dụng có hai mô-đun bên trong: một mô-đun triển khai logic nghiệp vụ và mô-đun còn lại dựa vào sự tích hợp với bên thứ ba. Bên thứ ba này là một công ty bên ngoài cung cấp API của họ cho một số mục đích cụ thể — chẳng hạn như dự báo thời tiết. Nếu máy chủ thời tiết ngừng hoạt động, chúng ta sẽ không thể lấy thông tin chi tiết về thời tiết. Nếu dữ liệu này quan trọng đối với kết quả xử lý cuối cùng và không có nguồn thay thế cho dữ liệu thì người dùng có thể sẽ nhất thời gặp phải một số vấn đề khá đau đầu.

Hãy tưởng tượng rằng nhà cung cấp bên thứ ba này đã được thay thế và nhà cung cấp mới có cách khác để xử lý cùng một API. Việc tách các mô-đun có nghĩa là các nhà phát triển chỉ có một mô-đun phải cập nhật. Logic nghiệp vụ trong mô-đun còn lại hoàn toàn không cần phải động tới, hoặc nhiều nhất là yêu cầu cập nhật ở mức tối thiểu.

Nhu cầu về cấu trúc tiến trình rõ ràng cũng ảnh hưởng đến việc thiết kế các API để làm cho chúng dễ sử dụng hơn. Khái niệm chuyển trạng thái đại diện (Representational State Transfer - REST) ​​là kiểu kiến ​​trúc với một bộ hướng dẫn để thiết kế và triển khai quyền truy cập vào dữ liệu trong một ứng dụng.

Có sáu nguyên tắc REST. Để đơn giản hoá, chúng ta sẽ cùng tìm hiểu về ba điều có liên quan nhất đến bài học này:

Các API tuân theo các nguyên tắc REST được gọi là RESTful và trong web hiện đại, thiết kế REST được nhiều ứng dụng web tuân theo. Mặc dù API RESTful không cần triển khai các nguyên tắc này bằng giao thức HTTP nhưng nó vẫn gần như được sử dụng phổ quát trong mô hình REST nhờ tính mạnh mẽ, đơn giản và phổ biến trong môi trường web toàn cầu.

Có hàng chục kiểu cách và tiêu chuẩn kiến ​​trúc đang tồn tại nhằm tổ chức các cấu trúc của ứng dụng web. Giống như hầu hết mọi thứ trong thế giới máy tính, không có cái gì được gọi là "toàn diện", chỉ có một tập hợp ưu và nhược điểm cho mỗi mô hình. Một mô hình quan trọng được gọi là kiến trúc dịch vụ vi mô đã được tạo ra để thay thế cho kiến trúc nguyên khối đã cũ.

Kiến trúc dịch vụ vi mô là một mô hình phần mềm bao gồm nhiều dịch vụ phụ thuộc lẫn nhau và cùng nhau tạo thành ứng dụng cuối cùng. Kiến trúc này nhằm mục đích phân cấp cơ sở mã: Nhiều lớp phần mềm được chia thành nhiều ứng dụng nhỏ hơn để có thể bảo trì tốt hơn (Kiến trúc dịch vụ vi mô).

Ngược lại, một kiến ​​trúc nguyên khối sẽ chứa tất cả các dịch vụ và tài nguyên của ứng dụng trong một ứng dụng (Kiến ​​trúc nguyên khối).

Các hình ảnh cho thấy mô hình dịch vụ vi mô được phân cấp và ứng dụng dựa trên nhiều dịch vụ, mỗi dịch vụ đều có cơ sở dữ liệu, cơ sở mã và thậm chí là cả tài nguyên máy chủ riêng. Đúng như tên gọi, mỗi dịch vụ vi mô đều phải nhỏ hơn so với phó bản nguyên khối chịu trách nhiệm về tất cả các dịch vụ của nó.

Ứng dụng nguyên khối sẽ đóng gói tất cả tài nguyên của nó thành một đơn vị duy nhất. Tất cả các logic nghiệp vụ, dữ liệu và cơ sở mã đều sẽ được tập trung thành một khối lớn. Đây chính là lý do tại sao nó được gọi là “nguyên khối.”

Người dùng hầu như sẽ không chú ý việc ứng dụng web đang chạy với mô hình nguyên khối hay dịch vụ vi mô; sự lựa chọn về vấn đề này nên được minh bạch. Ví dụ: ứng dụng ngân hàng có thể là một khối nguyên khối nơi tất cả cáclogic nghiệp vụ liên quan đến thanh toán, giao dịch, khoản vay, v.v. đều nằm trong cùng một cơ sở mã chạy trên một hoặc nhiều máy chủ. Mặt khác, nếu ứng dụng ngân hàng sử dụng kiểu dịch vụ vi mô, nó có thể có một dịch vụ vi mô dành riêng cho việc xử lý các khoản thanh toán và một dịch vụ vi mô khác chỉ để phát hành các khoản vay. Dịch vụ vi mô phát hành khoản vay sẽ gọi thêm một dịch vụ vi mô khác để phân tích xác suất người nộp đơn không trả được nợ. Ứng dụng có thể có tới hàng ngàn các dịch vụ nhỏ hơn.

Phương thức nguyên khối tiêu hao nhiều kinh phí trì hơn khi ứng dụng phát triển lớn hơn, đặc biệt là khi có nhiều đội ngũ viết mã trong cùng một cơ sở mã. Với các tài nguyên phần mềm tập trung, rất có thể một đội nhóm sẽ thay đổi điều gì đó dẫn đến làm hỏng phần ứng dụng của một nhóm khác. Đây có thể là một vấn đề thực sự đau đầu đối với các đội ngũ làm việc lớn với số lượng nhóm làm việc cao.

Về mặt này, phương thức dịch vụ vi mô linh hoạt hơn nhiều vì mỗi dịch vụ chỉ được quản lý bởi một nhóm. Tất nhiên, một nhóm cũng có thể quản lý nhiều dịch vụ. Việc thay đổi mã có thể được thực hiện dễ dàng và việc cạnh tranh tài nguyên sẽ không phải là một vấn đề thực sự. Vì mỗi dịch vụ đều được kết nối với nhau nên bất kỳ điểm lỗi nào cũng có thể có tác động tiêu cực đến toàn bộ ứng dụng. Hơn nữa, vì có nhiều phiên bản cơ sở dữ liệu, máy chủ và API bên ngoài giao tiếp với nhau nên khả năng phục hồi của toàn bộ ứng dụng chỉ đạt ngang tầm với dịch vụ vi mô yếu nhất của nó.

Một ưu điểm của phương pháp nguyên khối là có một nguồn dữ liệu tập trung giúp dễ dàng tránh trùng lặp dữ liệu hơn. Cách tiếp cận này cũng làm giảm mức tiêu thụ tài nguyên đám mây vì một máy chủ lớn hơn cần ít tài nguyên máy tính hơn nhiều so với các máy chủ phi tập trung. Một ứng dụng dịch vụ vi mô có kích thước tương đương sẽ đặt lên đám mây một gánh nặng lớn hơn.