Giới thiệu về Microservices Architecture

Hello hello, xin chào tất cả anh em. Anh em nào đã lỡ vào đây rồi thì comment chào nhau một cái nhé cho đông vui nhé. Đầu xuân năm mới, mình xin gửi lời chúc sức khỏe tới mọi người, chúc mọi người và gia đình một năm mới an khang thịnh vượng, mọi sự hanh thông, phát tài phát lộc. 🎉🎊🏆️

Bài viết này sẽ cung cấp cái nhìn tổng quát về Microservices Architecture dành cho các bạn mới bắt đầu tìm hiểu. Với các ae đã có nhiều kinh nghiệm, mong ae (nếu được) cũng bớt thời gian tham khảo và cùng thảo luận về chủ đề này tại phần chức năng bình luận cuối bài nhé. Mời mọi người cùng đón đọc! 🙅🙆

LƯU Ý: Nếu chưa đọc hết bài, bạn hãy dùng chức năng bookmark của Viblo để lưu lại bài viết này và đọc lại sau nha.

👉️ Introduction

Vào cuối năm 2022 vừa rồi, mình cũng có thực hiện một buổi thuyết trình về chủ đề cùng tên tại bộ phận mà mình làm việc. Hôm nay, mình sẽ chia sẻ lại nó dưới dạng bài viết trên Viblo. Hãy cùng mình điểm nhanh một chút về những nội dung sẽ có trong bài viết.

1. Giới thiệu chung (🚩We're here)
2. Tìm hiểu về Monolithic Architecture
   • Monolithic Architecture là gì?
   • Những trở ngại gặp phải của Monolithic Architecture?
   • Tại sao lại chuyển sang dùng Microservices?
3. Tìm hiểu về Microservices Architecture
   • Microservices Architecture là gì?
   • Ưu điểm của microservices
   • Nhược điểm của microservices
   • Chuyển từ Monolithic sang Microservices
   • Communication giữa các microservices
   • Quản lý source code của microservices

Bắt đầu nhé! 🥍🏌️🇻🇳

👉️ Tìm hiểu về Monolithic Architecture

Monolithic Architecture là gì?

Trước khi bắt đầu với Microservices, mình sẽ đề cập tới một kiến trúc sơ khai được gọi là Monolithic Architecture. Hãy cùng xem bức ảnh dưới đây trong vài giây, để ý những đặc điểm của nó và mình sẽ giả thích về nó sau lát nữa.

🖖 Three...
🤞 Two...
🖕 One!
👉️👉️👉️ =>>>> Tiếp nào...

Mình muốn bạn xem bức ảnh khối đá trên trước nhằm mục đích cắt nghĩa từ Monolith trong cụm từ Monolithic Architecture. Monolith ở đây được hiểu là một khối đá rất lớn, dựng đứng và nguyên khối. Hãy chú ý tới những từ mình in đậm nhé. 😊

Vậy nếu đặt từ này vào trong cụm từ Monolithic Architecture của ngành IT thì nó sẽ được hiểu như nào? ❓️❓️❓️

Để trả lời, mình có vẽ một sơ đồ dưới đây về kiến trúc của một ứng dụng.

Trong ngành IT, Monolithic Architecture ám chỉ một kiến trúc hệ thống mà tất cả các thành phần của ứng dụng đều nằm trong một source code duy nhất. Hình ảnh của nó trông chả khác gì một khối đá đồ sộ và đứng sừng sững... một cục... 😒 🤔 😆

Chính vì tất cả là một khối nên nó có một số đặc điểm chung đó là:

• Kiến trúc đơn giản, dễ triển khai lên production
• Mọi thứ được phát triển, deploy và scale trên 1 code base duy nhất
• Ứng dụng được viết với 1 technical stack duy nhất

Trong sơ đồ trên, mình giả sử là hình mình hoạ cho VD1 về hệ thống https://viblo.asia sử dụng Monolithic Archiecture chẳng hạn. Lúc này, tất cả các thành phần như:

• Accounts, Authentication, Posts, Questions… đều build trong một source code duy nhất viết bằng Ruby on rails
• Users sẽ truy cập và sử dụng một app duy nhất là Rails - mình gọi là Monolithic Application
• Ứng dụng sẽ kết nối tới một database duy nhất, và database này chứa tất cả các thông tin về:
  • Tài khoản
  • Bài viết
  • Câu hỏi
  • Phân quyền...

Tới đây, bạn đã thấy bóng dáng về ứng dụng của mình trong đấy chưa? 😆

Trước khi có microservices, monolithic là một chuẩn chung khi phát triển ứng dụng và tới bây giờ nó vẫn được dùng với các dự án nhỏ. Điều này cũng hết sức bình thường thôi. Không có gì căng thẳng! 😄

Những trở ngại của Monolithic Architecture

• Với dự án nhiều team, team sẽ phải cẩn thận để không làm ảnh hưởng tới chức năng của team khác
• Khi có chỉnh sửa source code, sẽ phải build và deploy lại toàn bộ cả ứng dụng, gây mất nhiều thời gian để release
• Team bị bó buộc trong một technical stack duy nhất: Chẳng hạn trong VD1, team bị gắn chặt vào Ruby on rails. Điều này vô hình làm team không tận dụng được sức mạnh đến từ các ngôn ngữ lập trình / technical stack khác.

• Không thể deploy / scale riêng cho một phần chức năng nào đó. Rõ ràng, khi mọi chức năng đều chung một source code, chúng ta bắt buộc phải scale cả cái ứng dụng to đó lên. Bản chất khi scale như vậy vẫn chưa được coi là microservices.
• Càng lâu dài, càng nhiều code, ứng dụng càng trở nên cồng kềnh và phức tạp
• Nhiều code của các thành phần khác nhau bị rối và lẫn lộn vào nhau, ảnh hưởng việc phát triển giữa các team
• Dependencies conflict giữa các thành phần khác nhau
• Mỗi thay đổi trước release, cần phải test lại cả ứng dụng

VD2: Về dependencies conflict.

• Trong hình, chức năng Authentication yêu cầu thư viện Passport v9.x thì mới có thể hoạt động
• Trong khi đó, chức năng Authorization có một số đặc thù mới từ khách hàng, dẫn tới yêu cầu thư viện Passport v10.x mới có thể làm được
• Lúc này, team đảm nhiệm chức năng Authentication bắt buộc phải thực hiện migrate code để có thể dùng cùng phiên bản Passport v10.x

VD3: Về vấn đề scale.

• Xét hệ thống của Viblo, giả sử Viblo tổ chức sự kiện Khai bút đầu xuân với trị giá giải thưởng lên tới 1 tỷ đồng. Dẫn tới thu hết rất nhiều tác giả viết bài rất hay như: Trịnh Quốc Việt, Minh Monmen, hay mình chẳng hạn 😅😅😅 cùng tham gia viết bài và thu hút số lượng rất cao traffic vào đọc bài tăng đột biến.
• Một hệ thống theo kiến trúc Monolithic không thể scale riêng cho chức năng đọc bài và render bài viết từ markdown sang HTML vì tất cả các thành phần đều chung một app.

Trên đây là một số ví dụ mình dẫn ra để giúp bạn hình dung được về những vấn đề của Monolithic Architecture. Để giải quyết các vấn đề trên, Microservices Architecture đã được hình thành. Nội dung tiếp theo, không có gì khác, chắc chắn sẽ là Microservices Architecture. 🤭🤭🤭

👉️ Tìm hiểu về Microservices Architecture

Microservices Architecture là gì?

Ở phần trên, mình đã trình bày khá chi tiết về Monolithic Architecture và các trở ngại mà chúng ta phải đối mặt. Tất cả các vấn đề mà Monolithic Architecture gặp phải sẽ đều được giải quyết với Microservices Architecture.

Về cơ bản, Microservices Architecture là kiểu kiến trúc mà ứng dụng sẽ được chia thành nhiều dịch vụ nhỏ hơn và độc lập với nhau gọi là microservice hay service, các service kết nối với nhau tạo thành một ứng dụng lớn.

Như trong ảnh VD4 trên, mình làm mô phỏng việc chuyển đổi sang Microservices Architecture của Viblo, các chức năng sẽ được phân hóa ra thành rất nhiều microservice độc lập như:

• Authentication service: Đảm nhiệm xử lý hoạt động xác thực danh tính người dùng
• Accounts service: Đảm nhiệm việc quản lý các thông tin liên quan tới tài khoản người dùng
• Stories service: Đảm nhiệm việc quản lý các thông tin liên quan tới bài viết
• ... Và có thể có rất nhiều các service khác
• Mỗi service có thể có database của riêng nó

Vậy thì một số câu hỏi đặt ra trước mắt là:

• Làm sao để chia nhỏ ứng dụng?
• Làm sao để kết nối chúng?
• Phải tạo bao nhiêu service?
• Lưu trữ và quản lý source code như nào?
• Deploy các service ra sao?

Hãy tiếp tục phần tiếp theo để có những câu trả lời nhé các bạn.

Những lợi ích của Microservices

Như đã đề ở phần trước, microservices sẽ chia ứng dụng thành nhiều service nhỏ và độc lập. Chính bởi vậy, nó mang lại một số lợi ích:

• Develop, deploy và scale các service không bị phụ thuộc lẫn nhau. Nếu có 10 services, 1 bản update mới cho 1/10 service thì quá trình release chỉ cần build / test / deploy cho duy nhất 1/10 service giúp rút ngắn thời gian release, cũng như có thể dễ dàng scale cho từng service riêng lẻ.

• Mỗi service có thể được phát triển bởi một team khác nhau, cái này thì rõ ràng rồi
• Mỗi team có thể lựa chọn được technical stack riêng sao cho tối ưu cho service cần phát triển. Thay vì chỉ dùng Ruby on Rails như trong VD1, mình thí dụ Viblo có thể lựa chọn:
  • Node.js cho Authentication service
  • Go cho Accounts service
  • Rust cho Authorization service
  • Python cho Bookmarks service
  • Có thể sử dụng đa dạng các loại database như PostgreSQL, MySQL, MongoDB

• Các service có thể có verison hoàn toàn khác nhau và dependencies độc lập
• Giúp hệ thống dễ dàng hơn khi phân tán trên nhiều server / vùng khác nhau. Điều này là bởi các microservice thường phải đi kèm theo các orchestration như Docker, Kubernetes, mà phổ biến nhất bây giờ là Kubernetes - có vai trò tự động phân bổ các service vào server cũng như là giám sát chúng.

Nhược điểm của microservices

Trong một hệ thống microservice, mỗi service con sẽ là một mắt xích trong cả hệ thống hàng chục, hàng trăm service con. Việc có quá nhiều service con được "đẻ ra" dẫn tới rất nhiều vấn đề phát sinh, cần phải xử lý sao cho phù hợp để nhàn hơn về sau. Nếu xử lý không tốt sẽ có thể gây ra một chuỗi các lỗi như hiệu ứng domino vậy. Dưới đây là một số nhược điểm của microservices mà chúng ta cần phải lưu ý:

• Ứng dụng trở nên phức tạp do bị chia thành rất nhiều service, distributed system
• Việc communication giữa rất nhiều các services sẽ làm tăng lưu lượng mạng nội bộ lên gấp nhiều lần, đòi hỏi phải có các giải pháp để các service gửi ít dữ liệu hơn và nhanh hơn. 😅
• Monitoring khó khăn hơn vì sẽ rất nhiều container và phân tán trên nhiều servers. Nếu làm không tốt ngay từ đầu sẽ dẫn tới hệ lụy rằng khó truy vết, xác định lỗi trong cả trăm service.

Tuy nhiên cũng có rất nhiều công cụ để việc deploy microservices dễ dàng hơn, phổ biến nhất đó là Kubernetes.

Và tất nhiên rồi, bạn sẽ lại phải học =)) 🤗😇 Orchestration, Security, Monitoring, gRPC, Service Mesh…

Bạn thấy nó còn nhược điểm nào nữa không? Comment xuống dưới giúp mình nhé! 💕

👉️ Chuyển đổi từ Monolithic sang Microservices?

Thực ra việc chuyển đổi từ monolithic sang microservices sẽ có nhiều thứ bạn cần học và tìm hiểu. Nếu bạn mong muốn có thêm những nội dung liên quan tới microservices, hãy ủng hộ mình bằng cách upvote, follow cũng như comment xuống dưới nhé.

Thông thường, để chuyển đổi sang microservices, bạn phác thảo sơ bộ về system architecture của hệ thống như:

• Cần phải có bao nhiêu service?
• Các service sẽ có vai trò như nào trong hệ thống?
• Việc trao đổi dữ liệu giữa các service ra sao?
• ....

Chúng ta đang nói với nhau rằng microservices thì phải chia nhỏ ứng dụng thành nhiều service nhỏ hơn. Vậy như thế nào mới là nhỏ? Bao nhiêu service thì là đủ? Phương pháp nào để chia ứng dụng ban đầu thành các service con?

Thật ra, chúng ta không có giới hạn cũng như định nghĩa như nào là nhỏ hay to, số lượng service bắt buộc phải là một con số bao nhiêu đó. Điều này hoàn toàn phụ thuộc vào quy mô cũng như nguồn lực của dự án. Tuy nhiên, thường thì ban đầu, chúng ta sẽ chia nhỏ ứng dụng monolithic dựa theo chức năng nghiệp vụ thay vì căn cứ theo technical.

Chẳng hạn, chúng ta không chia kiểu: web-app, api, redis, database.. điều này sẽ làm bạn rất rối ở bước đầu. Thay vào đó hãy căn cứ theo chức năng nghiệp vụ của ứng dụng:

• Accounts service: Quản lý thông tin tài khoản
• Stories service: Quản lý thông về bài viết
• Search service: Đảm nhiệm chức năng tìm kiếm của hệ thống
• Auth service: Đảm nhiệm chức năng authentication / authorization
• Recommendation service: Đảm nhiệm chức năng làm hệ gợi ý các bài viết hay khác tới users

Phân chia như vậy giúp bạn phác thảo ra hình hài của hệ thống. Từ đó, khi xem xét các vấn đề các thành phần technical khác sẽ tự xuất hiện như:

• Queue
• Scheduler
• Database
• Kafka...

Và hãy cố gắng để mỗi service chỉ đảm nhiệm một phần chức năng chuyên biệt.

👉️ Vấn đề trao đổi dữ liệu giữa các service trong microservices

Như đã đề cập ở trên, việc đẻ ra rất nhiều các service con trong một hệ thống khiến lưu lượng mạng sẽ tăng lên gấp nhiều lần khi các service sẽ cần gọi lẫn nhau và chúng ta cần có các giải pháp để giảm lưu lượng mạng xuống mà vẫn đáp ứng được yêu cầu dữ liệu.

Trong phần này, mình sẽ giới thiệu tới các bạn các cách để các service có thể tìm thấy nhau và trao đổi được dữ liệu.

Dùng Service Mesh

Service Mesh là một hình thức phổ biến và tất cả các microservices đều bắt buộc phải có khi hệ thống có cả trăm service.

Trong đó, service mesh đóng vai trò trung gian chịu trách nhiệm các vấn đề về network như:

• Chia IP cho từng service con theo các dải mạng để các service con có thể tìm thấy nhau hoặc cô lập với nhau 😂
• Cung cấp Sidecar, kiểu như một dạng proxy để forward request vào service tương ứng
• Xử lý vấn đề về DNS cho các service, kiểu như đặt tên miền cho mỗi service, các service không giao tiếp trực tiếp bằng IP mà sẽ dùng tên miền, VD như dùng K8s, mình muốn gửi request tới Accounts service thì sẽ gửi request tới domain: accounts.svc.cluster.local. Sau đó, service mesh sẽ DNS để tới đúng IP của service tương ứng.

Service mesh thường đi kèm trong các orchestration như Docker, Kubernetes. Có thể service mesh architecture của từng orchestration khác nhau nhưng chức năng của nó vẫn là service mesh.

VD như trong Ảnh 8 bên trên là service mesh architecture của K8s. K8s sẽ cung cấp các thành phần gồm control plane + sidecar proxy. Các service của chúng ta sẽ ủy quyền việc communication cho Control Plane. Control plane sẽ DNS và forward request tới đúng service được yêu cầu.

Dùng RESTful

Về REST thì bản chất vẫn là HTTP + JSON payload.

• Mỗi service sẽ có bộ API của riêng nó, trong có đa dạng các request GET, PUT, POST và nhiều URL khác nhau như: /login, /users/123...
• Một service gửi HTTP request đi và chờ HTTP response trở về
• Hình thức communication này còn được gọi là => Synchronous communication, tức thằng gửi request đi phải chờ có phản hồi thì mới xử lý tiếp.
• Hình thức communication này thì đơn giản và dễ dàng triển khai.

Dùng GraphQL

Tương tự như REST, GraphQL bản chất vẫn là HTTP + JSON. Tuy nhiên một chút điểm khác biết đó là client:

• Chỉ sử dụng POST method
• Client + Server đều dùng chung một Schema về resource - được quy định từ trước khi code
• Trả về đúng các thông tin về resource được yêu cầu, không thừa, không thiếu một field nào
• Single endpoint: Client chỉ gửi request tới một endpoint URL duy nhất

• GraphQL server thường có cơ chế gọi là federation - tư tưởng tương tự microservices:
  • Chia nhỏ GraphQL server ban đầu thành nhiều service graphql server nhỏ hơn gọi là sub-graph. (Ảnh 9)
  • Trong đó có một service đóng vai trò là Gateway, forward GraphQL request tới các service con.
  • Cơ chế federation cũng cho phép mapping dữ liệu giữa các sub-graph với nhau
• Một số GraphQL server hỗ trợ subscription, tính năng tương tự như socket, giúp realtime data từ server xuống client.
• Ngoài ra, subscription còn được dùng để tạo cơ chế lazy response như trên Hasura:
  • Client gửi HTTP request lên GraphQL server
  • Server trả về HTTP response là subscription id và xử lý yêu cầu background trên server
  • Client subscribe theo ID vừa nhận
  • Khi xử lý xong, server gửi data được về cho client đang subcribe subscription-id.

Dùng Message broker

Một cách khác để communicate giữa các service đó là dùng giao thức Message Broker, rất hữu ích với các service implenment event bus (Event Driven architecture):

• Trước tiên, các service (thường gọi là producer) sẽ gửi message đến một thành phần trung gian gọi là Broker, VD: Redis, RabbitMQ...
• Sau đó, broker sẽ đưa message vào trong queue để chờ tới lượt
• Khi tới lượt, message trong queue sẽ được gửi tới các subscriber (thường gọi là consumer) - chính là các service đầu cuối

• Đây là một dạng Asynchronous communication
• Trao đổi thông tin dưới dạng các message
• Ngoài ra, nó cũng hay được biết đến với pattern: Publish / Subscribe

Dùng gRPC

gRPC là cũng một phương án rất hiệu quả để các service có thể trao đổi dữ liệu với nhau.

gRPC = RPC + Protocol Buffers

• Được tạo ra bởi Google, trên Viblo có một bài viết rất hay giới thiệu về gRPC của 200labs, mọi người có thể đọc thêm
• Trong đó thì RPC là framework giúp một service có thể gọi một hàm nằm ở một service khác hay còn gọi là Remote Procedure Call

• Protocol Buffers (Protobuf) giúp encode data về dạng binary thay vì dùng dạng JSON-text như REST, GraphQL, giúp giảm kích thước của data. Các resource được định nghĩa trong một file syntax Protobuf có đuôi *.proto. Các ngôn ngữ lập trình khác nhau sẽ đọc file này để tự generate ra code RPC tương ứng.

• gRPC được xây dựng trên HTTP2, khác với REST và GraphQL. Điều này giúp nó có thêm các tính năng streaming ấn tượng giúp tối ưu performance
• gRPC được biết đến là phương án mang có performance cao, tiêu tốn ít băng thông hơn nhiều so với việc sử dụng JSON truyền thống

Mixed - Kết hợp

Trên đây mình đã điểm qua các hình thức communication phổ biến giữa các service trong hệ thống microservices. Chúng ta không nhất thiết phải chỉ dùng một loại mà có thể kết hợp lẫn nhau sao cho phù hợp.

Chẳng hạn, bạn có thể kết hợp GraphQL + gRPC:

• GraphQL đóng vai trò như API Gateway để publish service ra thế giới bên ngoài
• gRPC đóng vai trò communication giữa các Private Services với nhau hoặc từ GraphQL server tới các private services

VD như Ảnh 11:

Trên đây là kết thúc phần giới thiệu về các hình thức communication giữa các microservices. Tiếp theo, mình sẽ điểm qua nội dung về việc quản lý source code cho hệ thống microservices.

👉️ Code managenment & CI/CD cho microservices

Khi các service được develop và deploy riêng lẻ thì lúc này:

• Việc tổ chức và quản lý code với Git sẽ như nào?
• Deploy service ra sao?
• Bình thường, 1 application -> 1 git repository
• Vậy với hệ thống lớn có hàng trăm service thì cần bao nhiêu repo?

Thực ra, có thể bạn đã biết, chúng ta có hai cách phổ biến hiện này cho việc quản lý source code đó là:

• Poly-repo (Multi-repo): Mỗi project / service một repository trên Git.
• Mono-repo: Nhiều project / service đều để chung trong một repository trên Git.

Polyrepo (Multi-repo)

Ưu điểm Polyrepo

• Một repository cho một service
• Code hoàn toàn độc lập
• Clone và làm việc hoàn toàn tách biệt
• Đối với Gitlab, có thể sử dụng chức năng Gitlab Group cho mỗi ứng dụng để nhóm các microservices cũng như chia sẻ secret key, CI/CD variables
• Github sẽ khó khăn hơn khi phải dùng Organization thay cho Group của Gitlab
• CI/CD cấu hình đơn giản hơn
• Quản lý được chặt chẽ quyền truy cập theo từng project

Nhược điểm Polyrepo

• Việc tìm kiếm source code khó khăn hơn do trải dài trên nhiều repo
• Nếu 1 tính năng cần sửa đổi code của nhiều service cũng lúc
• => phải tạo nhiều PR => việc deploy không đồng nhất
• Các file và script cấu hình như docker, k8s sẽ phải sao chép lại trên nhiều repo

Monorepo

Ngược lại với Polyrepo, Mono repo lại có hình hài như này:

- microservices-demo
|__ .git
|__ .docker
|__ src |__ users-service |__ auth-service |__ stories-service |__ search-service |__ ...

Nhiều công ty lớn như: Google, Facebook cũng dùng monorepo để quản lý source code.

Ưu điểm Monorepo

• Sử dụng 1 Git repository để lưu trữ nhiều projects
• Mỗi project là một folder chỉ chứa code của project đó
• Quản lý code và phát triển đơn giản hơn khi tất cả code cùng một repo
• Clone và làm việc chỉ với 1 repo, dễ làm/test cùng nhau

Nhược điểm Monorepo

• Nếu setup không tốt, sẽ dàng phá vỡ quy tắc mỗi service deploy một cách độc lập
• Ứng dụng ngày một lớn hơn, việc push / pull code trở nên chậm hơn
• Một số hệ thống CI/CD chưa support mono repo -> phải viết thêm logic để xử lý việc deploy độc lập từng service
• Chỉ có 1 main branch cho toàn bộ các projects
• => sẽ gây ảnh hưởng tới việc phát triển của các project khác

Mixed - Kết hợp

Không có ràng buộc nào bắt buộc chúng ta phải dùng monorepo hay polyrepo cả. Thậm chí bạn có thể phối kết hợp cả hai loại trên. Tuy nhiên, theo mình:

• Ưu điểm của monorepo thì trở thành nhược điểm của polyrepo và ngược lại.
• Nếu dự án chỉ một team, hoặc các team không cần phải chặt chẽ về việc phân quyền và quản lý truy cập => Dùng Monorepo
• Nếu dự án nhiều team và yêu cầu rất nghiêm ngặt về việc ai được truy cập project nào, ai không => Dùng Polyrepo

Dựa vào những phân tích ưu nhược điểm trên của mình, hy vọng bạn sẽ chọn được cho mình phương án sử dụng Git repository phù hợp nhé. 😃😆

👉️ Tổng kết

Qua bài viết này, mình tin rằng đã cung cấp cho bạn một cái nhìn tổng quan nhất về Microservices Architecture:

• Hiểu được Monolithic / Microservices là gì
• Làm sao để chuyển đổi từ monolithic sang microservices
• Các ưu nhược điểm của từng loại architecture kể trên
• Cách services trao đổi dữ liệu, giao tiếp với nhau trong microservices
• Quản lý source code microservices; CI/CD

⚠️ CHỖ NÀY PHẢI CHÚ Ý:

• Nếu bạn quan tâm tới chủ đề này và muốn mình ra thêm các bài viết tương tự, hãy comment xuống dưới nhé!
• Đừng quên cho mình một upvote / bookmark / follow để ủng hộ mình và có nhận được thông báo khi có bài viết mới nha.
• Donate cho mình nếu bạn thấy nội dung này hữu ích và muốn mình làm thêm về các topic bạn mong đợi: Mono, Paypal, Bank
• => Link donate: https://kimyvgy.webee.asia