Bài này thực ra là đi copy từ đây, nhưng dịch lại theo ngôn ngữ dễ hiểu thôi : ).

Trông có vẻ phức tạp nhưng gần như mình sử dụng hết các phần trong này đó. Thông thường thì mình không để ý đến 9a và 9c, 10 cũng khá optional nhưng thôi cứ đề cập cả.

Câu chuyện ở trong bài viết hơi khác nhưng mình sẽ diễn giải lại thế này.

Khi bạn tìm kiếm techover trên Google, kết quả đầu tiên tìm được sẽ là: https://magz.techover.io/. Khi ấn vào link đó, trình duyệt sẽ truy cập đến DNS server tìm kiếm cách truy cập đến magz.techover.io, sau đó trình duyệt sẽ gửi request. Request đầu tiên sẽ truy cập đến CDN Cloudfront của magz.techover.io, các request đã cache sẽ đựoc response luôn từ Edge Location của Cloudfront. Các request khác sẽ đến Load Balancer, và chọn ngẫu nhiên 1 trong 5 Server LightSail của techover. Webserver sẽ truy vấn vào database, tra cứu một số thông tin về các hình ảnh có trong bài viết từ S3 và thực hiện thay đổi database. Và tất nhiên giờ đây, Server sẽ luôn response cho người đọc chế độ xem dưới dạng HTML và gửi lại cho trình duyệt của người dùng, trước tiên chuyển qua bộ cân bằng tải. Trang này chứa các tài sản Javascript và CSS mà mấy cái này thì lại được cache ở CDN ở ban đầu ấy, vì vậy trình duyệt của người dùng liên hệ với CDN để lấy nội dung. Cuối cùng, trình duyệt hiển thị rõ ràng trang cho người dùng xem. Tiếp theo, khi người đọc tìm kiếm bài viết tương tự Server sẽ gửi yêu cầu đến Fulltext Search Service bằng cách sử dụng tiêu đề bài viết và các từ khóa có trong nội dung. Tương lai gần, dịch vụ này cũng phục vụ cho custom feed cho từng user một dựa trên các sở thích hay xu hướng tìm kiếm các từ khóa ở techover. Nhưng bây giờ mỗi khi người dùng đăng bài, chúng tôi sẽ lưu trữ tạm kết quả của trang home ở một Server cache Redis để phục vụ người dùng tốt hơn. Sau đó người dùng viết bài, các tác vụ upload ảnh, resize khá nặng vì vậy sẽ đẩy các công việc này vào queue SQS và được thực hiện bởi các worker, mà các worker này sẽ xử lý không đồng bộ, cập nhật database phù hợp với kết quả, các hình ảnh này sau khi được xử lý xong sẽ được lưu trữ trên S3 và có một CDN Cloudfront khác phục vụ request. Đấy là toàn bộ bức tranh của trang techover hiện tại, cũng khá đủ component.

Tiếp theo thì mình sẽ đi qua từng cái ở trên kia, mấy cái khóa ở trường đại học thường sẽ dùng số 101 để cho các khóa introduction nên ông tác giả để như thế. Chắc sẽ có một vài series 102, 103 để nói rõ hơn.

DNS

Domain Name System, tên nó là thế. Gần như đây là một thứ cốt lõi trong thế giới Web hiện nay. Ở mức cơ bản nhất, DNS cung cấp tra cứu key-value từ một tên miền – domain (ví dụ: google.com) đến địa chỉ IP (ví dụ: 85.129.83.120), được yêu cầu để máy tính của bạn định tuyến(route) yêu cầu đến server phù hợp. Tương tự với số điện thoại, sự khác biệt giữa tên miền và địa chỉ IP là sự khác biệt giữa cuộc gọi của Nguyen Van A, và cuộc gọi 0945123456. Giống như bạn cần một cuốn sách điện thoại để tra cứu số của A trong những ngày xưa, bạn cần DNS để tra cứu địa chỉ IP cho một tên miền. Vì vậy, bạn có thể nghĩ DNS là danh bạ điện thoại cho internet. Có nhiều chi tiết khác chúng tôi có thể đi vào đây nhưng mình sẽ bỏ qua vì nó không quan trọng cho bài 101 này.

Thực ra có một series khác nói về cái này rõ hơn, có thể tìm thấy ở đây này.

Load Balancer

Cân bằng tải, thực ra trong ví dụ của techover thì Load Balancer (LB) còn sau cả CDN nhưng nó không tiêu chuẩn và không hay dùng như thế lắm nên mình để ở đây.

Hồi ở đại học thì mọi người sẽ biết đến khái niệm mở rộng theo chiều ngang (Horizontal scaling) và mở rộng theo chiều dọc (Vertical scaling). Thì mở rộng theo chiều dọc là nâng cấp phần cứng: Ram, CPU, Bandwidth, … cho Server làm cho Server mạnh hơn đúng nghĩa theo chiều dọc, còn mở rộng theo chiều ngang là thay vì bạn nâng cấp, bạn sẽ mua thêm Server mới, đặt ngang hàng với Server cũ, không tin thì xem ở Stackoverflow này.

Lúc phát triển một ứng dụng web, thường thì mọi người sẽ thích mở rộng theo chiều ngang hơn vì nó đơn giản, chỉ cần cài thêm server là được. Các vấn đề bất ngờ như: Server sự cố, crash, mất điện datacenter bất ngờ, sự cố thiên tai, … có thể dễ dàng được phòng chống bằng cách đưa thêm Server, ngoài ra khi có nhiều Server chúng ta sẽ có thể bảo trì một trong các Server một cách dễ dàng mà không làm ảnh hưởng đến người dùng vì vẫn còn những Server khác hoạt động. Thuật ngữ thường dùng ở đây là fault tolerant. Thứ hai, việc mở rộng theo chiều ngang cho phép các component của ứng dụng không liên kết quá chặt chẽ với nhau (low coupling) (như Web Server, Database, Service, v.v.), bằng cách cho mỗi component chạy trên một cum Server khác nhau. Cuối cùng, lý do cốt lõi nhất, đồng ý bạn có thể mở rộng theo chiều dọc tuy nhiên đến một lúc nào đó bạn không để mở rộng được nữa,ví dụ như giới hạn của rack server, của datacenter, không có máy tính nào trên thế giới đủ lớn để thực hiện tất cả các tính toán ứng dụng của bạn, trong khi đó việc mở rộng theo chiều ngang gần như không hạn chế. Ví dụ thực tế như này, Netflix một lúc có thể chạy vài chục đến vài nghìn EC2 instance mỗi loại, thậm chí có dùng cả GCP và Azure, không có Server nào đủ lớn để chạy toàn bộ ứng dụng của Netflix trên một Server duy nhất cả.

Lan man hơi nhiều, nhưng trở lại với Load Balancer, có thể nhận ra rằng Load Balancer lại là cái không thể thiếu để thực hiện mở rộng theo chiều ngang. LB định tuyến các request từ user/client đến các Server khác nhau và đưa kết quả về lại cho user/client, mấy cái Server này thường là các bản sao của một server gốc, hay đơn thuần chỉ là bạn cài đặt lại toàn bộ Server đó. Bất kỳ Server nào trong số đó cũng nên xử lý request theo cùng một cách để nó chỉ là vấn đề phân phối các request trên toàn bộ các Server để không Server nào bị quá tải.

Đó, Load Balancer về mặt khái niệm là đúng theo nghĩa đen, tất nhiên đằng sau đó là một loạt các công nghệ khác nhau, nhưng cuối cùng vẫn phải đề cập ở một bài viết cụ thể hơn.

Web Application Servers

Ở high level, các Web Application Server tương đối đơn giản để mô tả. Những server này thực thi logic nghiệp vụ cốt lõi xử lý request của người dùng và gửi lại HTML cho trình duyệt của người dùng. Để thực hiện công việc của mình, các server này có kết nối với nhiều cơ sở hạ tầng phụ trợ như database, caching, queue job, searching service, các micro-service khác, logging, v.v. Như đã đề cập ở trên, mọi người thường có sử dụng 1 hoặc nhiều load balancer trong cùng một ứng dụng. Web App thì có thể sử dụng nhiều ngôn ngữ khác nhau (Node.js, Ruby, PHP, Scala, Java, C # .NET, v.v.) và một framework MVC cho ngôn ngữ đó (Express cho Node.js, Ruby on Rails , Play Framework cho Scala, Laravel cho PHP, v.v.). Tuy nhiên, đi sâu vào chi tiết của các ngôn ngữ và khung này nằm ngoài phạm vi của bài viết này.

Database

Hiện nay, mỗi Web Application thường sử dụng một hoặc nhiều database để lưu trữ thông tin. Database cung cấp các cách xác định cấu trúc dữ liệu của bạn, insert dữ liệu mới, search/select dữ liệu hiện có, update hoặc xóa dữ liệu hiện có, thực hiện tính toán trên dữ liệu và hơn thế nữa. Trong hầu hết các trường hợp, các Web Application Server, cũng như các Worker Server làm việc trực tiếp một Database. Ngoài ra, mỗi Backend có thể có cơ sở dữ liệu riêng của mình và riêng biệt với với phần còn lại.

Trong bài viết nay, thường sẽ tránh nói sâu về một loại công nghệ cụ thể, thế nên chỉ đề cập đến 2 loại database: SQL và NoQuery.

SQL là viết tắt của Structured Query Language, ngôn ngữ này cung cấp một cách truy vấn tiêu chuẩn cho các bộ dữ liệu quan hệ có thể truy cập được đối tượng. Cơ sở dữ liệu SQL lưu trữ dữ liệu trong các bảng được liên kết với nhau thông qua các quan kệ: Id, Foreign Id . Hãy xem qua một ví dụ đơn giản về lưu trữ thông tin địa chỉ lịch sử cho người dùng. Bạn có thể có hai bảng, user và user_addresses, được liên kết với nhau bởi id người dùng. Xem hình ảnh dưới đây cho một phiên bản đơn giản. Các bảng được liên kết bằng cột user_id trong user_addresses là một Foreign key, với cột id trong bảng user.

Nếu bạn không biết nhiều về SQL, tôi khuyên bạn nên tìm hiểu hướng dẫn như bạn có thể tìm thấy ở W3School tại đây. SQL gần như xuất hiện ở mọi Web Application Server, nhìn chung gần như bạn không thể làm Web mà không biết gì về SQL cả. NoQuery, viết tắt của từ Non-SQL, là một công nghệ cơ sở dữ liệu mới hơn đã xuất hiện để xử lý lượng dữ liệu khổng lồ có thể tạo ra Web Application với quy mô lớn (hầu hết các biến thể của SQL không thể mở rộng theo chiều ngang quá tốt và chỉ có thể mở rộng theo chiều dọc đến một điểm nhất định). Nếu bạn không biết gì về NoQuery, mình khuyên nên bắt đầu với một số link dưới đây:

• https://www.w3resource.com/mongodb/nosql.php
• http://www.kdnuggets.com/2016/07/seven-steps-understanding-nosql-databases.html
• https://resources.mongodb.com/getting-started-with-mongodb/back-to-basics-1-introduction-to-nosql

I would also keep in mind that, by and large, the industry is aligning on SQL as an interface even for NoSQL databases so you really should learn SQL if you don’t know it. There’s almost no way to avoid it these days.

Về cơ bản cũng sẽ ghi nhớ rằng, gần như tất cả phần mềm đang liên kết với SQL như một giao diện thường thấy ngay cả đối với NoSQL, họ cũng tạo ra các framework cũng như library để hỗ trợ truy vấn NoSQL như một database SQL thông thường, thế nên thực sự cần biết về SQL, kiểu gì bạn cũng gặp những thứ này thôi.

Caching Service

Caching Service cung cấp một một nơi lưu trữ theo kiểu key-value đơn giản, cho phép tra cứu các thông tin với độ phức tạp O(1). Các ứng dụng thường tận dụng các Caching Service để lưu kết quả của các tính toán nặng và khó để có thể lấy lại kết quả từ cache thay vì tính toán lại chúng vào lần tiếp theo khi chúng ta cần. Một ứng dụng có thể lưu trữ kết quả từ truy vấn database, kết quả gọi đến một API ở bên ngoài, HTML cho một URL nhất định và nhiều hơn nữa. Dưới đây là một số ví dụ từ các ứng dụng trong thế giới thực:

• Google lưu trữ kết quả tìm kiếm cho các truy vấn tìm kiếm phổ biến như Taylor Swift hay World Cup, thay vì tính lại chúng mỗi lần
• Facebook lưu trữ nhiều dữ liệu có thể hiển thị lúc bạn đăng nhập, chẳng hạn như dữ liệu bài đăng, bạn bè, v.v. À có một bài chi tiết về vụ Facebook ở đây

Job Queue & Servers

Hầu hết Web Appliaction cần thực hiện một số async job ở background mà không liên quan trực tiếp đến việc tiếp nhận và đáp ứng request của người dùng. Chẳng hạn, Google cần thu thập dữ liệu và lập chỉ mục toàn bộ internet để trả về kết quả tìm kiếm. Google không làm điều này mỗi khi bạn tìm kiếm. Thay vào đó, Google thu thập dữ liệu web không đồng bộ, cập nhật các chỉ mục tìm kiếm khi duyệt các trang web. Mặc dù có các kiến ​​trúc khác nhau cho phép thực hiện async job, nhưng phổ biến nhất là kiểu Queue hay Queue Job. Cài này bao gồm hai thành phần:

• Một là queue, tất nhiên rồi, thường thì có thể dùng database queue, Redis queue, xịn xò hơn thì dùng dịch vụ cloud như SQS của AWS hay Task Queue ở GCP, Queue này lưu trữ một danh sách các async job. Đơn giản nhất là queue FIFO
• Hai là cái thực hiện công việc trong queue, thường được gọi là Worker hay Job Server. Bất cứ khi nào Application cần chạy một job, theo một thứ tự thông thường hoặc được xác định bởi hành động của người dùng, thì Application sẽ thêm một job vào queue. Ví dụ, Techover sử dụng queue job làm nhiều background job cần thiết cho công việc. Techover dùng các job để resize ảnh, xử lý CSV để gắn tag, cập nhật Elastic Search index, gửi email đặt lại mật khẩu và nhiều cái nữa. Đầu tiên chúng tôi sử dụng một queue FIFO đơn giản sau đó nâng cấp lên hàng đợi ưu tiên để đảm bảo rằng các hoạt động cần kíp như gửi email đặt lại mật khẩu đã được hoàn thành càng sớm càng tốt. Worker Server, thông thường được cài đặt riêng hoặc có thể chạy cùng với Application Server cho tiết kiệm tài nguyên, các Server này kiểm tra queue job để xác định xem có job nào để làm hay không và nếu có, họ sẽ lấy job (pop) ra khỏi queue và thực hiện(execute). Chi tiết về vụ ngôn ngữ và framework thì lại không đề cập ở bài viết này nhé.

Full-text Search Service

Nhiều Web Application, nếu không phải hầu hết đều hỗ trợ một số tính năng tìm kiếm trong đó người dùng nhập vào một đoạn keyword(query) và Web Application trả về kết quả có liên quan nhất về keyword đó. Công nghệ dùng cho chức năng này thường được gọi là Full-text Search, trong đó sử dụng một inverted index để nhanh chóng tra cứu các tài liệu có chứa các từ khóa truy vấn.

Mặc dù nó có thể thực hiện Full-text Search trực tiếp từ một số cơ sở dữ liệu (ví dụ: MySQL hỗ trợ Full-text Search), nhưng chúng ta có thể sử dụng một Search Service riêng biệt, tính toán và lưu trữ inverted index và cung cấp query interface. Full-text Search Platform nổi tiếng và phổ biến nhất hiện tại là Elaticsearch mặc dù có các tùy chọn khác như Sphinx hoặc Apache Solr.

Services

Khi một Application đạt đến một quy mô nhất định, có khả năng sẽ có một số Service nhất định được refactor để chạy như các Application riêng biệt. Những service này không tiếp xúc với thế giới bên ngoài nhưng sẽ tương tác cùng Application và các service khác. Ví dụ như Techover, có một số service hoạt động và theo schedule:

• Service gửi mail
• Service chạy hằng đêm để đồng bộ tài khoản
• Service export file thành PDF

Data

Ngày nay, các công ty sống dựa vào người dùng và dữ liệu. Hầu như mọi ứng dụng ngày nay, một khi nó đạt đến một quy mô nhất định, tận dụng một data pipeline để đảm bảo rằng data có thể được thu thập, lưu trữ và phân tích. Một data pipeline điển hình có ba giai đoạn chính:

1. Ứng dụng sẽ gửi data, điển hình là các sự kiện về tương tác của người dùng, đến data Firehose, nơi cung cấp các interface dùng để nhập và xử lý data. Thông thường, data thô được chuyển đổi hoặc xử lý thêm data và chuyển sang một Firehose khác. AWS Kinesis (bao gồm cả Kinesis Data Firehose)và Kafka là hai công nghệ phổ biến nhất cho mục đích này.
2. Data thô cũng như data được chuyển đổi cuối cùng được lưu vào Cloud Storage. AWS Kinesis cung cấp một cài đặt Firehose, giúp lưu trữ data thô vào Cloud Storage S3.
3. Data được chuyển đổi cũng thường được lưu vào một loại database để phân tích – Data Warehouse, cũng không phải là loại database dùng cho Application thường thấy. Ở AWS thường chúng ta sẽ dùng AWS Redshift, đây là một sản phẩm ưa chuộng của giới ít tiền nhất là các startup, bên cạnh đó các công ty lớn hơn sẽ thường sử dụng Oracle hoặc các Data Warehouse. Nếu các bộ dữ liệu đủ lớn, các Hadoop-like NoSQL như MapReduce có thể dùng để phân tích dữ liệu. Một bước cuối cùng mà thường không được hình dung trong sơ đồ kiến ​​trúc: Load data từ Application vào dịch vụ Data Warehouse. Ví dụ: tại một số trang web sẽ chuyển data từ một OLTP Database vào Redshift mỗi đêm. Việc này giúp cho các data scientist có toàn bộ dữ liệu đầy đủ nhất để phân tích và đưa ra các quyết định.

Cloud storage

Theo AWS: "Cloud storage là một phương thức đơn giản và có thể mở rộng để lưu trữ, truy cập và chia sẻ dữ liệu qua Internet". Bạn có thể sử dụng nó để lưu trữ và truy cập bất cứ thứ gì như khi bạn lưu trữ trên hệ thông localfile với thêm lợi ích là có thể tương tác với nó thông qua API RESTful qua HTTP. Amazon S3 cho đến nay vẫn là bộ lưu trữ đám mây tuyệt vời nhất hiện nay và là nơi Techover dùng để lưu trữ video, ảnh và âm thanh, CSS và Javascript, dữ liệu người dùng(tất nhiên là private bucket) và nhiều cái khác nữa.

CDN – Content Delivery Network

CDN cung cấp cách transfer các file như HTML tĩnh, CSS, Javascript và hình ảnh trên web nhanh hơn nhiều so với lấy chúng từ một Server nào đó. Nó hoạt động bằng cách distribute các content trên nhiều máy chủ (Edge Location) trên toàn thế giới, để enduser có thể tải xuống các file này từ đó thay vì máy chủ gốc. Ví dụ trong hình ảnh bên dưới, một người dùng ở Tây Ban Nha yêu cầu một trang web từ một trang web có Origin Server ở New York, nhưng các file tĩnh cho trang được tải từ Server Edge CDN, ở Anh, ở Pháp, điều này giúp người dùng tải trang nhanh hơn trải nghiệm mượt mà hơn.

Về vụ CDN thì có thể xem thêm ở bài viết này.

EOF

Cũng hết những cái đề cập từ đầu rồi, bài viết này với mục đích 101 để mọi người hình dung rõ hơn về thế giới web :).