Khi bắt đầu làm dự án lớn

Trường hợp của bạn có rất nhiều cách giải quyết. Mình đưa ra theo hướng microservices.

Bạn nên bắt đầu với Docker để triển khai microservice. Tách app của bạn thành nhiều service nhỏ. Mỗi service bao gồm server và database. Server và database của service này không ảnh hưởng đên server và database của service khác. Service nào càng nhận request nhiều thì tạo nhiều service cho nó, rồi deploy trên các server khác nhau. Docker sẽ quản lý load balancing trên các servers, chỉ cần tạo 1 file Docker Compose khai báo bao nhiêu server, bao nhiêu service, mỗi service tạo bao nhiêu phần. Nếu kết hợp với AWS thì Amazon có tool tích hợp với Docker, tự động load balancing.

Ngoài hướng microservice còn có:

• SPA, triển khai app trên client, cache nhiều nhất có thể, hạn chế request.
• Refactor database theo kiến trúc Hadoop.
• Sử dụng load balancing của RDBMS (cái này mình không biết nhiều).

Bổ sung thêm ý của bạn Hung.

• Ngoài việc microservices ra thì nên API hóa toàn bộ các dịch vụ, bỏ qua các template view thông thường, cơ chế xác thực JWT.

• Phía frontend dùng Angular/React/Vue, bỏ jQuery, liên lạc với server qua API.

• Dùng websocket cho chức năng realtime như chat hay update dữ liệu.

• Triển khai lên mây, các nhà cung cấp lớn đã có tool cho triển khai microservices.

• 1000 request hay 1 tỷ ri quét không phải là việc của dev, nó là việc của bên hạ tầng. Nếu bạn tự làm thì nó thuộc về chức năng cân bằng tải, không phải chức năng của ứng dụng.

Đừng. 1k req/s vẫn chưa phải là 1 con số lớn. Khi mọi thứ chưa xảy ra vấn đề gì thì monolithic vẫn rất tốt. Chia ra microservices lại càng làm mọi thứ rối lên. Redis/Memcache hay gì thì tùy thuộc vào nhu cầu là gì mà sử dụng. Chưa hẳn nhiều request là phải dùng những công nghệ đấy. Cứ làm từ từ. Mắc đâu thì nghiên cứu ở đó. Chứ giờ cứ tự nghĩ nó to thế này thế kia cũng k giải quyết được vấn đề gì.

Vấn đề là bạn ấy nói “bắt đầu dự án lớn”.
Nếu làm mono thì sau này mất công phá đi làm lại lần nữa, chẳng thà làm ngay từ đầu.

Dự án ra sao rồi bác?

Nhưng bạn ấy nói bạn ấy chưa có kinh nghiệm. Nếu có kinh nghiệm nhìn trước được sẽ tách service gì ra ngay từ đầu và có thể manage được thì đã không có gì phải nói. Đây rằng bạn ấy không có kinh nghiệm thì việc phải kiêm 1 đống services + networking, monitoring, alert/log system, version impact tả phí lù thứ phải làm thì bạn nghĩ có khả thi không? Việc làm monolithic nhưng module rõ ràng thì việc tách service khi cần thiết cũng không có gì khó.

Có lẽ dự án không lớn đến mức phải dùng microservice, rất ít ứng dụng có cơ hội phát triển đến quy mô hàng triệu người dùng.
Về khía cạnh học tập, nếu vì lý do hiện nay không có kinh nghiệm về công nghệ xyz nên không làm thì 10 năm sau vẫn không có kinh nghiệm thôi.

Bạn không hiểu ý mình à? Mình nói hiện tại khi build foundation thì dùng monolithic sau có xảy ra vấn đề thì sẽ split ra các microservice chứ mình k có nói là cứ sẽ mãi dùng mono. Còn cứ chỉ vì nghe đến hot trend microservices rồi đu theo khi không có kinh nghiệm thì là bad programmer. Cái gì cũng phải có thời gian phát triển. Nếu đi quá nhanh chẳng khác nào bảo kỹ sư xây dựng mới ra trường cho thiết kế chung cư. High risk!

Cái microservice người ta chả dùng chán rồi hot trend gì nữa.
Ứng dụng hiện nay lớn nhỏ gì thì cũng cho vào Docker hết, triển khai dễ dàng vì môi trường phát triển giống với môi trường triển khai.
Tuy nhiên đồng ý với bạn là dự án của chủ thread không cần thiết phải microservice vì cơ hội để nó lớn đến mức thay đổi cấu trúc và hạ tầng là không cao.

Với Laravel thuần thì phải nói là khá khó để đạt 1000 rps (xem test)
Do vậy mình gợi ý bạn có thể chuyển sang code Nodejs.
Còn nếu bạn vẫn muốn làm với Laravel thì tối tưu một số thứ theo thứ tự: upgrade to PHP 7.x, Caching (redis…), tối ưu truy vấn, load balancing (nginx…), docker, caching server (varnish…)