Un diagrama aproximado de la arquitectura del último proyecto a gran escala en el que participé.
Es solo un esquema básico, adaptado de los documentos de arquitectura reales y presentado de una manera que se asemeja a un enfoque típico de n niveles combinado con un enfoque MVC típico . Como puede ver, la lógica y los niveles de datos están conectados a través de una capa de servicio, y más específicamente una API REST , inspirada en Recess , un marco PHP menos conocido.
No reinventes la rueda
Yo trabajo con tres marcos:
Marco Zend
El gigante de los frameworks PHP, con una base de código impresionantemente bien escrita y una extensa lista de características. En aplicaciones a gran escala, te encontrarás modificando el marco la mayoría de las veces, y creo que la base de código de ZF es la más agradable para trabajar. Pero cuidado, no es un marco de nivel de entrada .
Kohana
Kohana comenzó como un tenedor de CodeIgniter, y esa fue una razón suficiente para que no lo usara, inicialmente. Hoy en día se ha convertido en un marco sólido y elegante que se diferencia de todos los demás siguiendo un enfoque MVC jerárquico . HMVC permite una mayor extensión de modularización que MVC . Para el proyecto en el diagrama, adapté el HMVC de Kohana a ZF, pero comencé a usar Kohana para proyectos más pequeños y a considerarlo también para proyectos más grandes.
CodeIgniter
Solo lo uso debido a un proyecto heredado que heredé, evítalo si es posible.
Como señalaron las otras respuestas, un ORM siempre es útil. Uso Doctrine ampliamente, y deberías echar un vistazo a sus nuevos mapeadores para CouchDB y MongoDB . La escalabilidad es imprescindible en aplicaciones a gran escala y debe evaluar las soluciones NoSQL .
Dicho todo esto, lo importante es recordar que las aplicaciones más grandes generalmente tienen desafíos únicos. Debe evaluar todas las soluciones de terceros populares que existen, y probablemente obtendrá mucho de un par de soluciones oscuras. Cuando evalué Recess por primera vez, estaba lejos de estar listo para la producción, pero su enfoque esencialmente llegó al proyecto.
Actuación
En sitios web típicos, puede salirse con el almacenamiento en caché de salida simple y el almacenamiento en caché de código de operación, pero en las aplicaciones a gran escala realmente debería considerar el almacenamiento en memoria caché, que generalmente se basa en memcached .
xdebug se conoce principalmente como depurador, pero también puede servir como perfilador . Recientemente comencé a usar Zend Server y adoro sus características de rastreo de código . Desafortunadamente, esos no están disponibles en la Edición de comunidad , pero xdebug es una alternativa bastante decente.
Si está utilizando Apache, asegúrese de optimizarlo al máximo . Aparentemente, nginx y lighttpd son mejores opciones , en cuanto al rendimiento, pero no las he usado mucho y realmente no puedo decirlo.
En cuanto a la base de datos, el almacenamiento en caché de consultas y resultados de Doctrine funciona de maravilla, especialmente combinado con memcached . Y, por supuesto, no podemos olvidarnos del frente. El equipo de rendimiento excepcional de Yahoo ha reunido una extensa lista de mejores prácticas . No soy realmente un desarrollador front-end, pero he visto resultados sorprendentes en proyectos en solitario.
Por último, PHP tiene un nuevo mecanismo de recolección de basura , que vale la pena considerar.
Seguridad
El mundo de la seguridad de PHP es caótico, por decir lo menos. No soy un experto, así que trata los siguientes consejos genéricos:
Proyecto de seguridad de aplicaciones web abiertas
Hay muchas cosas buenas allí, pero para una visión general rápida, debe comenzar con la lista de los diez mejores . E investigue las soluciones PHP para esas vulnerabilidades comunes.
Apilar vulnerabilidades
Un buen hábito es monitorear periódicamente los errores abiertos de PHP . Incluso si usted no es un experto, casi siempre hay consejos para solucionar problemas de seguridad. Y, por supuesto, debe extender el hábito a cualquier otra parte de la pila, especialmente a los más vulnerables, como el servidor web y la base de datos.
La multitud en IT Security Stack Exchange puede ayudarlo con respuestas más educadas.
Otras lecturas