Trong bài viết này, tôi sẽ khám phá xem liệu bạn có thể sử dụng Laravel ở quy mô lớn và liệu nó có thể được sử dụng để vận hành những ứng dụng lớn như Twitter, Facebook hoặc các ứng dụng khác không.

Điều gì đã đưa tôi đến đây

Chúng ta đều mệt mỏi với câu hỏi "Laravel có mở rộng quy mô không?". Không phải vì mọi người đặt câu hỏi mà vì những phản hồi thiếu hiểu biết đối với câu hỏi này. Điều này đã xảy ra, và câu chuyện luôn giống nhau.

Ai đó đăng trên Twitter hoặc diễn đàn hỏi liệu Laravel có thể mở rộng quy mô

Hai nhóm người xuất hiện

• Nhóm một nói, "tất nhiên là có thể mở rộng framework web sẽ không phải là điểm nghẽn của bạn trong một thời gian dài."
• Nhóm hai nói "không" và tức giận vì sao bạn dám đề xuất rằng một framework PHP có thể hoạt động ở quy mô lớn.

Trong bài viết này, tôi sẽ giải quyết câu hỏi này một lần và mãi mãi: Laravel có mở rộng quy mô không?

Tại sao bạn lo lắng?

Trước khi đi vào chi tiết về việc liệu Laravel có thể mở rộng quy mô không, bạn phải hiểu rằng hầu hết mọi người đều lo lắng về một tình huống mà họ sẽ có thể không bao giờ gặp phải. Bạn không đang xây dựng các ứng dụng lớn như Google, Facebook hoặc YouTube tiếp theo. Tôi không viết điều này để xúc phạm, và tôi không phải là người bi quan, nhưng việc giữ kỳ vọng của chúng ta dựa trên thực tế là rất quan trọng về mặt tinh thần.

Vì vậy, khi mọi người hỏi câu hỏi, "Laravel có mở rộng quy mô không?" vì họ đang bắt đầu một công ty hoặc sắp xây dựng một ứng dụng cho một công ty trị giá hàng tỷ đô la, họ cần nhận ra rằng họ sẽ không đạt được quy mô của Facebook.

Wikipedia xử lý bao nhiêu yêu cầu?

Wikipedia là một trong những trang web lớn nhất thế giới, và, đoán xem, nó chạy trên PHP. Theo một bài viết của TechCrunch từ năm 2020, Wikipedia xử lý trung bình 255 triệu lượt xem trang mỗi ngày. Vậy điều đó trông như thế nào mỗi giây và mỗi tháng?

• 255 triệu / 86400 = 2,604 lượt xem trang mỗi giây
• 255 triệu x 30 = 6.75 tỷ lượt xem trang mỗi tháng

Chúng ta có coi Wikipedia là một trang web lớn không?

Facebook xử lý bao nhiêu yêu cầu?

Họ tuyên bố trong một bài viết blog năm 2010 rằng họ đã xử lý 100 tỷ "hits" mỗi ngày với 500 triệu người dùng. Đó là một con số khổng lồ. Từ "hit" rất mơ hồ và có thể tương ứng với bất kỳ điều gì, nhưng hãy giả sử đó là các yêu cầu web. Hãy xem điều đó trông như thế nào mỗi giây và mỗi tháng:

• 100 tỷ / 86400 = 1.15 triệu yêu cầu mỗi giây
• 100 tỷ x 30 = 3 nghìn tỷ yêu cầu mỗi tháng

Vậy đó là một lượng truy cập kinh khủng, ngoài sức tưởng tượng. Và đó là vào năm 2010!

Laravel có thể mở rộng quy mô để xử lý 3 nghìn tỷ yêu cầu mỗi tháng không?

Chắc chắn.

Bạn có thể sử dụng các framework khác cho một số phần của ứng dụng không?

Có.

Chúng ta có bao giờ xây dựng một ứng dụng xử lý 3 nghìn tỷ yêu cầu mỗi tháng không? Theo thống kê, không. Một lần nữa, đó không phải là tôi bi quan.

Thực tế, bạn sẽ mở rộng từ 1 triệu yêu cầu đến 100 tỷ yêu cầu mỗi tháng. Mỗi người có một ý tưởng khác nhau về một ứng dụng "lớn", vì vậy tôi đã đưa ra một phạm vi rộng lớn ở đây.

Bây giờ chúng ta đã giải quyết được thực tế rằng chúng ta đang lo lắng về điều gì đó mà theo thống kê sẽ không bao giờ xảy ra, hãy chuyển sang việc mở rộng Laravel trong thế giới thực.

Các bài kiểm tra của bạn là vô nghĩa

Các bài kiểm tra đánh giá hệ thống thường xuyên được đưa ra mỗi khi bạn thảo luận về việc liệu thứ gì đó có thể mở rộng quy mô hay không. Bạn sẽ thấy một số framework ngẫu nhiên ở đầu danh sách mà không ai từng nghe nói, có trải nghiệm phát triển tệ hại, không có cộng đồng và một hệ sinh thái tồi tệ. Nhưng vì nó có thể thực hiện nhiều yêu cầu trên một máy chủ mỗi giây, nó dường như là tốt nhất.

Mặc dù tôi rất muốn tranh luận về việc liệu Laravel có thể chạy ở mức 3 nghìn tỷ yêu cầu mỗi tháng hay không, tôi sẽ thừa nhận rằng khi bạn đạt đến một điểm nhất định mà chi phí tăng cao và bạn đang tìm kiếm thứ gì đó tiết kiệm chi phí hơn ở quy mô lớn, bạn có thể sẽ chuyển từ Laravel sang thứ gì đó bằng C++ hoặc Rust, ít nhất là cho một số phần của ứng dụng. Nhưng bạn cần lưu lượng truy cập như thế nào để chuyển đổi?

Gần đây, ai đó trên Twitter đã liên kết đến các TechEmpower Framework Benchmarks. Laravel nằm ở vị trí thứ #388 với hiệu suất 4,833 yêu cầu mỗi giây so với vị trí số 1 được giữ bởi drogon-core đạt được 666,737 yêu cầu/giây.

Chà, khoan đã, điều đó có nghĩa là drogon-core có thể thực hiện 1,752,184,836,000 yêu cầu mỗi tháng. Và vào năm 2010, Facebook đã thực hiện 3,000,000,000,000 yêu cầu mỗi tháng…

3,000,000,000,000 / 1,752,184,836,000 = 1.71

Này, ai đó nên nói với Facebook rằng họ nên chuyển toàn bộ mã của họ sang drogon-core, và họ sẽ có thể vận hành toàn bộ lớp ứng dụng của họ trên hai máy chủ web. Họ sẽ rất vui khi nghe tin này.

Điểm của tôi là những bài kiểm tra này vô giá trị khi bạn đang có một cuộc trò chuyện về việc liệu Laravel có thể mở rộng quy mô hay không. Bạn nhìn vào bài kiểm tra Laravel trong các kết quả trên và bạn nghĩ, "huh, có điều gì đó không ổn" rồi bạn cuộn xuống và thấy ghi chú sau:

Trong bài kiểm tra này, ORM của framework được sử dụng để lấy tất cả các hàng từ một bảng cơ sở dữ liệu chứa một số lượng không xác định các thông điệp cookie Unix (bảng có 12 hàng, nhưng mã không thể biết trước kích thước của bảng)

Chà, đúng vậy, Laravel không sử dụng kết nối pooling theo mặc định, không có kết nối liên tục, và mỗi yêu cầu đó là:

• Khởi động toàn bộ framework
• Kết nối với cơ sở dữ liệu MySQL
• Chạy truy vấn
• Ngắt kết nối khỏi cơ sở dữ liệu MySQL

Họ đang sử dụng PHP FPM… Còn Laravel Octane thì sao? Còn các kết nối liên tục thì sao? Còn một lớp kết nối pooling thì sao?

Những bài kiểm tra này thật vô lý. Tại sao ai đó lại nghiêm túc với chúng? Và ai đã tạo ra ý tưởng rằng các bài kiểm tra tổng quát này? Nó là bài kiểm tra quan trọng? Bởi vì chúng không phải. Tôi đã thừa nhận ở trên rằng, ở quy mô lớn, bạn có thể muốn thứ gì đó nhanh hơn PHP, nhưng đối với 99.99994% doanh nghiệp (và tôi đoán là nhiều hơn nữa), bạn sẽ thành công với Laravel. Và bạn sẽ được hưởng lợi từ tài liệu tuyệt vời, một cộng đồng đáng kinh ngạc và một hệ sinh thái mà Mark Zuckerberg sẽ ước ao khi anh ta lần đầu xây dựng Facebook.

Khi chúng tôi bắt đầu thấy sự tăng trưởng đáng kinh ngạc trong phần mềm của mình, Fathom Analytics (được xây dựng trên Laravel), các vấn đề của chúng tôi đều liên quan đến cơ sở dữ liệu. Chúng tôi chưa bao giờ có những khoảnh khắc "framework có đủ số lượng yêu cầu mỗi giây không?". Và thậm chí khi đó, chúng tôi là một trường hợp ngoại lệ. Hầu hết mọi người không làm nhiều lưu lượng truy cập như chúng tôi, vì vậy họ thậm chí không lo lắng về việc tối ưu hóa lớp HTTP và đang chạy một cách thoải mái với một thiết lập tương đối đơn giản.

Cũng thật buồn cười khi mọi người ném xung quanh thuật ngữ "doanh nghiệp" để cố gắng làm mất uy tín của Laravel. Đột nhiên, vì một doanh nghiệp đang kiếm được hàng triệu/hàng tỷ đô la doanh thu, dường như Laravel không phù hợp? Thật vô lý.

Tôi đã làm việc với các công ty doanh nghiệp sử dụng Laravel để vận hành toàn bộ doanh nghiệp của họ, và các công ty như Twitch, Disney, New York Times, WWE và Warner Bros đang sử dụng Laravel cho các dự án khác nhau mà họ vận hành.

Laravel có thể xử lý ứng dụng của bạn ở quy mô lớn.

Tôi nên lo lắng về điều gì?

Bây giờ, sau khi đã giải quyết một số điều sai lầm mà một số người trong chúng ta mắc phải bên trên, tôi muốn đi sâu vào chi tiết của việc mở rộng ứng dụng Laravel. Trước khi đồng sáng lập một nền tảng phân tích trang web, tôi chưa bao giờ có kinh nghiệm với việc mở rộng ứng dụng. Kinh nghiệm của tôi trước khi điều hành doanh nghiệp này là xây dựng các ứng dụng cho 100 - 10.000 người dùng, và tôi chắc chắn chưa từng phải lo lắng về việc xử lý hàng tỷ lượt xem trang.

Vậy nếu Laravel không phải là lĩnh vực chúng ta cần lo lắng khi mở rộng, thì điều gì mới là quan trọng?

Database, cache and sessions

Cơ sở dữ liệu của bạn sẽ trở thành nút thắt cổ chai khi bạn mở rộng. Tôi đang giả định một thiết lập MySQL/PostgreSQL truyền thống ở đây. Bạn sẽ không gặp vấn đề nếu bạn sử dụng DynamoDB hoặc SingleStore từ đầu, vì các giải pháp này được xây dựng để mở rộng khổng lồ với cấu hình tối thiểu. Dù sao đi nữa, tăng hiệu suất cơ sở dữ liệu là cả một sự nghiệp, và có nhiều thứ có thể được điều chỉnh ngoài các truy vấn bạn viết.

Lộ trình tối ưu cơ sở dữ liệu của chúng tôi khi xây dựng là:

1. Một tệp SQLite cho mỗi khách hàng (điều này thật khủng khiếp, đừng làm điều này).
2. PostgreSQL quản lý trên Heroku (thiếu sự quen thuộc với PostgreSQL dẫn đến mong muốn chuyển sang MySQL).
3. MySQL quản lý trên Heroku (điều này ổn, nhưng chúng tôi đã bỏ Heroku và chuyển sang Laravel Vapor).
4. RDS cho MySQL (chúng tôi bắt đầu gặp vấn đề về hiệu suất vì chúng tôi cần phân tích tạm thời và nhập liệu mở rộng. MySQL liên tục gặp sự cố, mặc dù đã nâng cấp và tăng IOPS).
5. SingleStore (cơ sở dữ liệu trong mơ của chúng tôi).

Bộ nhớ đệm: Chúng tôi đã sử dụng Redis làm bộ nhớ đệm trong vài năm và sau đó chuyển sang DynamoDB (để không phải lo lắng về việc kích thước Redis hoặc cổng NAT trên AWS). Ngày nay, chúng tôi sử dụng các bảng in-memory của SingleStore để lưu vào bộ nhớ đệm vì nó rất nhanh.

Chúng tôi chỉ làm việc với các dịch vụ và chúng tôi không phải là kỹ sư cơ sở dữ liệu. Nếu bạn là kỹ sư cơ sở dữ liệu, bạn sẽ không gặp khó khăn trong việc mở rộng cơ sở dữ liệu của mình, và bạn đã biết cách mở rộng theo chiều ngang, và điều chỉnh nó, v.v. Nhưng đối với phần còn lại, hãy sẵn sàng cho những cơn đau đầu về cơ sở dữ liệu khi bạn phát triển.

Queue system

Hệ thống hàng đợi của Laravel có nhiều driver như Amazon SQS, Redis, cơ sở dữ liệu, v.v. Mục đích của hệ thống hàng đợi là để chuyển các công việc tốn thời gian ra chạy nền (background) để đảm bảo thời gian phản hồi nhanh cho người dùng của bạn.

Chúng tôi rất ưa thích SQS vì nó có thông lượng không giới hạn và bảo mật tuyệt vời, và nó lưu trữ công việc qua nhiều khu vực sẵn sàng. Bây giờ chúng tôi sử dụng SingleStore cho cơ sở dữ liệu của mình, họ có thể hỗ trợ hệ thống hàng đợi của chúng tôi, nhưng chúng tôi thích hệ thống hàng đợi của mình tách biệt khỏi cơ sở dữ liệu (vì lý do chịu lỗi).

Một trong những mối lo ngại của tôi khi chúng tôi sử dụng Redis cho hệ thống hàng đợi là, "điều gì sẽ xảy ra nếu chúng tôi có một hàng đợi tồn đọng, Redis đầy, và chúng tôi hết dung lượng." Và đó là một mối lo ngại hợp lý vì chúng tôi đã gặp phải điều này trong những ngày đầu. Bên cạnh đó, có rất nhiều thứ bạn có thể làm để mở rộng Redis, điều mà hầu hết mọi người sẽ không gặp trong sự nghiệp của mình, nhưng nó là có thể. Bạn có thể cấu hình Redis để chạy ở quy mô lớn trên hàng đợi Laravel, và nhiều người đã làm điều đó. Hoặc bạn có thể sử dụng SQS hoặc SingleStore. Dễ dàng.

Các dịch vụ khác

Nếu bạn đang sử dụng PHP-FPM, bạn sẽ muốn giám sát, kiểm tra tải và cấu hình nó một cách tối ưu nhất có thể. Nhưng ngoài điều đó, các "dịch vụ bên ngoài" của bạn, chẳng hạn như cơ sở dữ liệu, hệ thống hàng đợi, v.v., sẽ trở thành nút thắt cổ chai chính của bạn trước PHP-FPM (hầu hết các lần, tôi chắc chắn sẽ có ngoại lệ).

Ngoài những điều trên, đừng quên các điều sau:

1. Đảm bảo API email của bạn (Postmark, SES, v.v.) có thể xử lý nhanh những gì bạn có thể gửi. Điều tương tự cũng áp dụng cho thông báo SMS và mọi thứ khác. Kiểm tra giới hạn tỷ lệ trên mọi dịch vụ bên ngoài bạn sử dụng và giám sát chúng, vì bạn có thể cần nâng chúng khi mở rộng.
2. Sử dụng CDN. Bạn không nên phục vụ static resource từ máy chủ web của mình, bạn nên sử dụng CDN như bunny.net, Cloudfront hoặc Cloudflare.

Viết mã có thể scale

Khi chạy ở quy mô lớn, bạn cần suy nghĩ về những điều mà trước đây có thể chưa nghĩ đến. Tôi sẽ chia sẻ một vài suy nghĩ về điều này, nhưng đây không phải là hướng dẫn viết mã toàn diện

Một trong những trải nghiệm đầu tiên của tôi về một khoảnh khắc "WTF" là khi tôi sử dụng các giao dịch cơ sở dữ liệu để chèn và tôi gặp phải các lỗi deadlock qua cột tự động tăng trong bảng. Tóm lại, tôi đã có nhiều giao dịch đa truy vấn, đa bảng cố gắng giành khóa trên tự động tăng để ghi một hàng. Giải pháp ban đầu cho vấn đề này, hoạt động tốt, là thử lại transactions 50 lần, nhưng điều đó không thể mở rộng và rất kém hiệu quả.

Cuối cùng, chúng tôi đã từ bỏ việc sử dụng transactions, và chúng tôi đã khắc phục vấn đề. Nhưng điểm tôi muốn nói là bạn sẽ không nhận ra vấn đề này ở quy mô nhỏ. Nhưng một khi mọi thứ bắt đầu tăng lên, bạn sẽ bắt đầu thấy những điều như thế này.

Vậy với điều đó, đây là một vài suy nghĩ của tôi về việc viết mã cho quy mô:

1. Make sure your queries are consistent - Đảm bảo các truy vấn của bạn nhất quán. Các kỹ sư từ Facebook đã có một lời khuyên tuyệt vời: "It's OK if a query is slow as long as it is always slow" - "Không sao nếu một truy vấn chậm miễn là nó luôn luôn chậm." Tôi đồng ý, và điều này có nghĩa là bạn cần biết rõ các truy vấn của mình và viết chúng một cách hiệu quả.
2. Know when to offload functionality - Biết khi nào nên chuyển chức năng ra ngoài. Chúng tôi đang nói về việc chạy Laravel ở quy mô lớn, nhưng tôi không nói rằng bạn nên sử dụng Laravel để xử lý video. Nếu Amazon có một dịch vụ có thể làm điều này cho bạn, hãy sử dụng nó. Khi bạn đang kiếm hàng tỷ đô la mỗi năm từ doanh thu, bạn có thể xây dựng nó trong nội bộ bằng cách sử dụng một số framework C++ tiên tiến. Điều đó sẽ rất thú vị!
3. Cache expensive queries - Bộ nhớ đệm các truy vấn. Điều này áp dụng cho tất cả các dự án nhưng trở nên quan trọng khi bạn mở rộng. Nếu bạn đang chạy một truy vấn SQL phức tạp/chậm và nó được hiển thị cho nhiều người hoặc hiển thị nhiều lần, hãy lưu kết quả vào bộ nhớ đệm. Bằng cách này, bạn chỉ cần thực hiện tra cứu bộ nhớ đệm key/value trong các yêu cầu tiếp theo, điều này sẽ mang lại lợi ích lớn. Chúng tôi đã làm điều này cho hộp người truy cập hiện tại của chúng tôi trên bảng điều khiển Fathom. Nếu ai đó chia sẻ bảng điều khiển công khai của họ cho một lượng lớn khách hàng, bạn đột nhiên có hàng nghìn người truy cập chúng tôi mỗi 10 giây với cùng một truy vấn, tìm kiếm số lượng người truy cập hiện tại theo thời gian thực, có thể trong nhiều giờ. Vì vậy, chúng tôi bắt đầu lưu vào bộ nhớ đệm phản hồi trong 10 giây cho người dùng không xác thực (tức là người ngẫu nhiên) xem bảng điều khiển công khai. Thay đổi này giảm tải đáng kể cho cơ sở dữ liệu của chúng tôi vì chỉ một trong các yêu cầu sẽ chạy truy vấn trong khi phần còn lại sẽ truy cập bộ nhớ đệm. Và đỉnh điểm này không bao giờ xảy ra nữa vì các truy vấn key/value (bộ nhớ đệm) hiệu quả hơn nhiều.
4. AWS service limits - Giới hạn dịch vụ AWS. Nếu bạn đang sử dụng AWS, họ có giới hạn trên các dịch vụ khác nhau, và chúng có thể gây rắc rối cho bạn. Một ví dụ tuyệt vời trong Laravel Vapor là khi sử dụng secrets, bạn có thể cần tăng throughput của Parameter Store. Vapor sử dụng chúng khi tạo container (lưu ý: container sẽ được tái sử dụng nhiều lần trước khi tự khởi động lại, vì vậy nó không truy cập Parameter Store ở mỗi yêu cầu).

Mặc định, bạn có quyền truy cập 40 giao dịch mỗi giây, điều này phù hợp với nhiều trường hợp sử dụng. Nhưng khi chúng tôi phát triển, chúng tôi gặp phải các lỗi và phải chuyển sang throughput cao hơn (3.000 giao dịch mỗi giây). Vì vậy, hãy xem xét các hạn mức cho tất cả các dịch vụ của bạn.

Cách chúng tôi triển khai cho quy mô lớn

Bây giờ tôi đã đề cập đến những khu vực cần "lo lắng" và một vài mẹo về viết mã ở quy mô lớn, tôi sẽ nói về cách chúng tôi mở rộng ứng dụng của mình. Chúng tôi chạy một dịch vụ phân tích ưu tiên bảo mật, và lưu lượng của chúng tôi là tổng hợp từ tất cả lưu lượng website của khách hàng. Vậy nên nếu chúng tôi có mười website mới làm khách hàng và mỗi website xử lý 50 triệu yêu cầu mỗi tháng, dịch vụ phân tích của chúng tôi cần xử lý thêm 500 triệu yêu cầu mỗi tháng. Khi chúng tôi bắt đầu có hàng trăm ngàn website sử dụng dịch vụ, bạn có thể thấy lý do tại sao chúng tôi ám ảnh với việc mở rộng dịch vụ của mình.

Trước khi đi vào cách chúng tôi triển khai, tôi nên nói rõ rằng bạn có thể mở rộng Laravel với EC2 (với autoscaling), ECS, Heroku, DigitalOcean, v.v. Chúng tôi không sử dụng những dịch vụ đó cho Fathom, nên tôi sẽ không đề cập đến chúng. Tôi sẽ nói cụ thể về cách chúng tôi thiết lập cơ sở hạ tầng để xử lý quy mô lớn khi chúng tôi phát triển nhanh chóng.

Như nhiều người trong số các bạn đã biết, tôi là một người hâm mộ lớn của cơ sở hạ tầng không máy chủ (serverless infrastructure). Tôi dạy khóa học Serverless Laravel, nơi tôi đã dạy hơn một ngàn người cách chạy ứng dụng của họ ở quy mô lớn mà không phải lo lắng về việc quản lý máy chủ. Khóa học đó được ra mắt sau khi chúng tôi triển khai phần mềm của mình lên Laravel Vapor vì tôi đã yêu thích nó.

Tôi sẽ đề cập đến ứng dụng collector phân tích của chúng tôi, không phải bảng điều khiển (dashboard) của chúng tôi. Mặc dù bảng điều khiển của chúng tôi nhận được hàng triệu yêu cầu mỗi tháng, nhưng ứng dụng collector phân tích (triển khai riêng biệt) là phần quy mô lớn của doanh nghiệp chúng tôi.

Sử dụng CDN làm điểm vào chính của cơ sở hạ tầng

Trước tiên, chúng tôi sử dụng CDN làm điểm vào chính của cơ sở hạ tầng. Chúng tôi sử dụng bunny.net, xử lý gần 1 nghìn tỷ yêu cầu mỗi tháng từ tất cả các khách hàng của nó. Họ dễ dàng xử lý lưu lượng của chúng tôi, cung cấp cho chúng tôi các cài đặt bảo mật cơ bản (giới hạn tốc độ, v.v.) và cho phép chúng tôi định tuyến lưu lượng như chúng tôi cần (ví dụ: định tuyến lưu lượng EU đến cơ sở hạ tầng EU của chúng tôi qua cách ly EU).

Định tuyến lưu lượng truy cập

Khi nó đi qua Bunny, nó được định tuyến đến một trong những nơi sau đây:

• Nếu lưu lượng đến từ EU, nó được định tuyến đến proxy EU đa vùng của chúng tôi được lưu trữ trên Hetzner. Thiết lập này sử dụng Go (tôi không viết nó!) và được xây dựng để xử lý quy mô lớn đáng kể trên nhiều vùng, nhưng đây là một phần nhỏ của tổng lưu lượng của chúng tôi.
• Nếu lưu lượng đến từ ngoài EU, nó được định tuyến đến cơ sở hạ tầng AWS chính của chúng tôi.

Proxy đánh vào cùng một điểm mà lưu lượng "ngoài EU" của chúng tôi đánh: Bộ cân bằng tải ứng dụng (ALB) của chúng tôi, một dịch vụ cân bằng tải được quản lý bởi Amazon có thể xử lý lưu lượng truy cập đáng kinh ngạc. Tất nhiên, bạn có thể tự triển khai điều này nếu bạn có chuyên môn (hoặc có thể thuê chuyên môn), nhưng chúng tôi là những người hâm mộ lớn của các dịch vụ được quản lý. Trước khi lưu lượng được định tuyến qua ALB, nó đi qua Tường lửa ứng dụng web (WAF) của chúng tôi, nơi giới hạn tốc độ và bảo vệ chống lại lưu lượng độc hại.

Xử lý với Lambda

Khi nó đã vượt qua WAF và ALB, nó đi đến Lambda. Chúng tôi có giới hạn throughput là 60.000 yêu cầu mỗi giây và sau đó chúng tôi có thể đẩy vượt qua đó. Tại thời điểm viết bài, điều này tương đương với khoảng 157 tỷ yêu cầu mỗi tháng.

Lambda chuyển yêu cầu đến SQS, kích hoạt một Lambda khác để xử lý yêu cầu. Chúng tôi có kế hoạch thay thế SQS bằng một ghi trực tiếp vào cơ sở dữ liệu sớm (để tiết kiệm chi phí và cải thiện hiệu suất), nhưng chúng tôi vẫn sẽ giữ SQS như một phương án dự phòng về khả năng sẵn sàng. Chúng tôi sẽ không bao giờ mơ làm điều này nếu chúng tôi đang chạy RDS cho MySQL, nhưng chúng tôi hiện đang chạy một cơ sở dữ liệu được xây dựng cho quy mô lớn.

Kết nối cơ sở dữ liệu

Một trong những vấn đề lớn nhất của chúng tôi với việc mở rộng là mở/đóng kết nối cơ sở dữ liệu, vì điều này tốn kém. Trước đây, mỗi lần xem trang sẽ mở một kết nối cơ sở dữ liệu, khởi động framework, chạy các truy vấn, và đóng kết nối, điều này không mở rộng được. Nhưng bây giờ chúng tôi có Laravel Octane, sẽ giữ các kết nối mở trong bộ nhớ. Điều này có nghĩa là chúng tôi có thể mở kết nối cơ sở dữ liệu khi khởi động container, và các yêu cầu tiếp theo sẽ sử dụng cùng một kết nối đó. Và, vâng, nó nhanh hơn nhiều, và CPU cơ sở dữ liệu của chúng tôi yêu thích chúng tôi vì đã làm điều này.

Laravel có phù hợp cho các dự án lớn không?

Tôi hiểu điều đó. Bạn đang ngồi trong một cuộc họp với ban quản lý và họ lo lắng về việc liệu Laravel có thể mở rộng hay không. Hoặc có thể bạn đang lo lắng liệu dự án phụ của mình hoặc doanh nghiệp mới của mình sẽ phát triển mạnh mẽ và Laravel sẽ không chịu nổi? Vậy đây là cấu hình tôi sẽ sử dụng nếu tôi bắt đầu một dự án mới ngay bây giờ và ban quản lý nói rằng chúng tôi có thể nhận hàng tỷ yêu cầu mỗi tháng:

• Laravel Vapor (triển khai SQS, Cloudfront, ALB, S3)
• AWS WAF
• SingleStore (thay vì RDS, Redis và DynamoDB)
• ALB (Application Load Balancer)

Và bạn sẽ sẵn sàng. Vì vậy, khi ban quản lý của bạn nói, "Này, chúng tôi cần mở rộng ra quốc tế và chúng tôi cần các máy chủ ở châu Á," bạn có thể sử dụng Global Accelerator. Bạn sẽ triển khai nhiều vùng Vapor và đặt chúng sau Global Accelerator. Sau đó, bạn sẽ nói chuyện với SingleStore về sao chép dữ liệu chéo vùng (chúng tôi không sao chép cơ sở dữ liệu của mình chéo vùng, nhưng tôi biết họ có những khách hàng làm điều đó).

Kết luận

Kết luận là Laravel là một lựa chọn tuyệt vời cho hơn 99.99994% các ứng dụng web.

Nhưng nếu Mark Zuckerberg gửi email cho bạn ngay bây giờ và nói:

"Chào, tôi vừa đọc các tin nhắn trò chuyện Facebook giữa bạn và đối tác của bạn, bạn có vẻ thú vị và mạo hiểm. Bạn có thể xây dựng lại Facebook cho chúng tôi không?"

Bạn có thể sử dụng Laravel để điều hành Facebook? Câu trả lời là: Có.

Nguồn: https://usefathom.com/blog/does-laravel-scale