Một sơ đồ sơ bộ về kiến trúc của dự án quy mô lớn mới nhất mà tôi đã tham gia.
Đây chỉ là một phác thảo cơ bản, được điều chỉnh từ các tài liệu kiến trúc thực tế và được trình bày theo cách giống với cách tiếp cận n tầng thông thường kết hợp với cách tiếp cận MVC điển hình . Như bạn có thể thấy logic và tầng dữ liệu được kết nối thông qua một lớp dịch vụ và cụ thể hơn là API REST , được lấy cảm hứng từ Recess , một khung công tác PHP ít được biết đến hơn.
Đừng phát minh lại bánh xe
Tôi làm việc với ba khung:
Khung Zend
Các đặc điểm của các khung công tác PHP, với một cơ sở mã được viết rất ấn tượng và danh sách các tính năng mở rộng. Trên các ứng dụng quy mô lớn, bạn sẽ thấy mình điều chỉnh khung thường xuyên hơn không và tôi thấy cơ sở mã của ZF là cách dễ chịu nhất để làm việc. Nhưng hãy cẩn thận, nó không phải là một khung cấp nhập cảnh .
Kohana
Kohana khởi đầu là một nhánh của CodeIgniter, và đó là lý do đủ để tôi không sử dụng nó, ban đầu. Ngày nay, nó đã phát triển thành một khung vững chắc và thanh lịch, khác biệt với nhau bằng cách làm theo cách tiếp cận MVC phân cấp . HMVC cho phép mở rộng mô đun hóa nhiều hơn so với MVC . Đối với dự án trong sơ đồ, tôi đã điều chỉnh HMVC của Kohana thành ZF, nhưng tôi đã bắt đầu sử dụng Kohana cho các dự án nhỏ hơn và xem xét nó cũng lớn hơn.
CodeIgniter
Tôi chỉ sử dụng nó vì một dự án cũ mà tôi được thừa kế, tránh nếu có thể.
Như các câu trả lời khác đã chỉ ra, một ORM luôn có ích. Tôi sử dụng Doctrine một cách rộng rãi và bạn nên xem qua các trình ánh xạ hoàn toàn mới của nó cho CouchDB và MongoDB . Khả năng mở rộng là bắt buộc trên các ứng dụng quy mô lớn và bạn nên đánh giá các giải pháp NoQuery .
Tất cả những gì đã nói, điều quan trọng cần nhớ là các ứng dụng lớn hơn thường có những thách thức độc đáo. Bạn nên đánh giá mọi giải pháp phổ biến của bên thứ ba, và có thể bạn sẽ thu được rất nhiều từ một vài giải pháp tối nghĩa. Khi tôi lần đầu tiên đánh giá Recess, nó đã không còn sản xuất nhưng cách tiếp cận của nó về cơ bản đã đưa nó vào dự án.
Hiệu suất
Trên các trang web điển hình, bạn có thể thoát khỏi bộ đệm ẩn đầu ra đơn giản và bộ đệm ẩn opcode nhưng trên các ứng dụng quy mô lớn, bạn thực sự nên xem xét bộ nhớ đệm, mà phổ biến nhất là xây dựng xung quanh memcached .
xdebug hầu hết được biết đến như là một trình gỡ lỗi, nhưng cũng có thể phục vụ như một trình lược tả . Gần đây tôi đã bắt đầu sử dụng Zend Server và tôi hoàn toàn yêu thích các tính năng theo dõi mã của nó . Thật không may, những thứ đó không có sẵn trong Phiên bản cộng đồng , nhưng xdebug là một lựa chọn khá tốt.
Nếu bạn đang sử dụng Apache, hãy đảm bảo tối ưu hóa địa ngục khỏi nó . nginx và lighttpd là sự lựa chọn rõ ràng tốt hơn , hiệu suất khôn ngoan, nhưng tôi đã không sử dụng chúng rất nhiều và tôi có thể không thực sự nói.
Đối với cơ sở dữ liệu, bộ nhớ đệm kết quả và truy vấn của Doctrine hoạt động kỳ diệu, đặc biệt là kết hợp với memcached . Và tất nhiên, chúng ta không thể quên về mặt trước. Nhóm Hiệu suất Đặc biệt của Yahoo đã tập hợp một danh sách các thực tiễn tốt nhất . Tôi không thực sự là một nhà phát triển front end, nhưng tôi đã thấy kết quả tuyệt vời trong các dự án solo.
Cuối cùng PHP có một thương hiệu mới cơ chế thu gom rác , đáng để xem xét.
Bảo vệ
Thế giới bảo mật PHP là hỗn loạn, để nói rằng ít nhất. Tôi không phải là chuyên gia, vì vậy hãy coi những điều sau đây là những lời khuyên chung chung:
Dự án bảo mật ứng dụng web mở
Có rất nhiều thứ hay ho ở đó, nhưng để có cái nhìn tổng quan nhanh, bạn nên bắt đầu với danh sách mười mục hàng đầu . Và nghiên cứu các giải pháp PHP cho các lỗ hổng phổ biến.
Lỗ hổng ngăn xếp
Một thói quen tốt là định kỳ theo dõi các lỗi mở của PHP . Ngay cả khi bản thân bạn không phải là chuyên gia, hầu như luôn có những lời khuyên giải quyết về các mối đe dọa bảo mật. Và tất nhiên, bạn nên mở rộng thói quen đến mọi phần khác của ngăn xếp, đặc biệt là những phần dễ bị tổn thương nhất, như máy chủ web và cơ sở dữ liệu.
Đám đông tại IT Security Stack Exchange có thể giúp bạn có câu trả lời có học thức hơn.
đọc thêm