-
El último artículo de esta serie está escrito para programadores comunes. Si no está interesado, puede leer los últimos párrafos de este artículo.
Antes de comenzar a diseñar la estructura del código, repasemos lo que hemos preparado antes: tenemos un servidor WEB con carga equilibrada, un servidor de base de datos maestro-esclavo y posiblemente fragmentación, un caché y almacenamiento escalable. Todos los aspectos de la organización del código están estrechamente relacionados con estos preparativos. Los enumeraré uno por uno, dos por tres, y cada uno comenzará con la frase clásica "mencionado anteriormente" para facilitar la comparación.
No se apresure a leer los patrones de oraciones clásicos, mi mente saltó e insertaré un párrafo. En el desarrollo real, siempre hacemos un compromiso entre rendimiento y elegancia del código. Para las computadoras y los intérpretes de idiomas de hoy, la cuestión de cuántas capas de llamadas a objetos y cuántas capas de llamadas a objetos y si declarar variables como Map o HashMap es lo último que deben considerar. Siempre considere la parte más lenta del sistema y resuelva. desde la parte más lenta. Por ejemplo, vea si el ORM que utiliza hace muchas cosas que no necesita y si hay llamadas de datos repetidas. Lo que hacemos es el desarrollo de aplicaciones web, no la API del marco subyacente. El código fácil de leer y comprensible es un aspecto muy importante para garantizar la calidad. ¿Para qué está diseñado su programa? Hay diferentes métodos... Olvídelo, este tema. Se discutirá por separado. Este artículo está demasiado alejado del tema. Si desea comunicarse, puede seguir mi Weibo : http://t.sina.com.cn/liuzhiyi .
Como se mencionó anteriormente, la carga del servidor WEB debe estar equilibrada y el servidor de imágenes debe estar separado. Con respecto a este punto, cuando el código maneja el estado del cliente, no coloque el estado en una sola máquina. Por ejemplo, no use la sesión de archivos. Bueno, el sentido común. Si es posible, es mejor desarrollar una interfaz unificada para la autenticación de punto único del usuario desde el principio, incluido cómo determinar el estado entre dominios, cómo determinar el estado en páginas estáticas y la definición de parámetros de salto y retorno al iniciar sesión. Proporcione una buena interfaz en la capa inferior y aplíquela. La capa se usa directamente (consulte el servicio de usuario de GAE). El diseño del inicio de sesión debe considerar las características de los dispositivos móviles. Por ejemplo, las computadoras pueden usar ventanas de capa flotante, pero el propio navegador de NOKIA o UCWEB no pueden manejar esta forma de expresión. El programa debe poder manejar tanto solicitudes Ajax como directamente a través de la URL. . preguntar. El servidor de imágenes está separado y es mejor colocar los archivos de recursos en el servidor de imágenes, es decir, el servidor WEB solo sirve programas dinámicos. Aunque es un poco complicado de desarrollar y probar (porque se requiere un URI absoluto para acceder), será mucho más fácil optimizar el front-end de la página en el futuro y la optimización IO de su servidor WEB también. ser mucho más fácil. Cuando el programa hace referencia a archivos de recursos, debe haber un método de procesamiento unificado. Muchas cosas se pueden completar automáticamente dentro del método, como combinar CSS / js en un archivo o agregar automáticamente QUERYSTRING después del URI generado. Se utiliza el servicio de caché, generar QUERYSTRING es la forma más sencilla de actualizar el caché del servidor y el caché del cliente.
Como se mencionó anteriormente, la base de datos se replicará, puede tener múltiples maestros y esclavos, y puede estar fragmentada. En el proceso de procesamiento de datos en nuestro programa, es mejor abstraerlos y colocarlos en una capa separada. Tome el popular modelo MVC como ejemplo, que consiste en colocar una capa de datos debajo de la capa M. Esta capa de datos no es la comúnmente conocida JDBC/PDO/ActiveRecord, etc., sino su propia capa de datos de acceso, que solo expone métodos a. el mundo exterior. Ocultar detalles de acceso a datos. No tenga miedo de escribir feos dentro de esta capa de datos, pero debe proporcionar todas las funciones de almacenamiento de datos. No vea las palabras relacionadas con la base de datos en ningún otro nivel. La razón de esto es que en el caso de una única base de datos relacional, puede SELECCIONAR... UNIR... o directamente INSERTAR... EN..., pero puede almacenar algunas tablas en una base de datos clave-valor, o Después de eso, será necesario cambiar todas las declaraciones y métodos originales. Si están demasiado dispersos, se gastará mucho esfuerzo durante el trasplante o se obtendrá un modelo muy grande. En términos de diseño a nivel de datos, intente evitar consultas JOIN. Podemos hacer más redundancia y almacenamiento en caché. Cada tipo de datos solo necesita una consulta y luego combinarla en su programa. Para combinaciones de datos más complejas, cuando los requisitos en tiempo real no son altos, se puede utilizar el procesamiento asincrónico y los usuarios solo obtienen los resultados procesados al acceder. Cuando trabaje con claves primarias, evite el uso de ID de incremento automático y use valores únicos generados por ciertas reglas como claves primarias. Esta clave primaria es la estrategia de distribución de fragmentación más simple. Incluso si usa una ID de incremento automático, es mejor usar un generador de ID de incremento automático. De lo contrario, si la base de datos esclava se escribe accidentalmente, la clave principal entrará fácilmente en conflicto.
Como se mencionó anteriormente, hay algunos cachés que bloquean el frente de nuestra base de datos. No trate el caché de consultas de MySQL como un caché. Cuando la aplicación es un poco compleja, QUERY CACHE se convertirá en una carga. El almacenamiento en caché está estrechamente integrado con la base de datos y el negocio. Debido a que está estrechamente relacionado con el negocio, no existe un enfoque único para todos. Pero todavía tenemos algunas reglas que seguir. Regla 1: cuanto más cerca del front-end, mayor será la granularidad de la caché. Por ejemplo, toda la página se almacena en caché en la parte frontal de la WEB, parte de la página se almacena en caché en el siguiente nivel y un solo registro en el área se almacena en caché en el siguiente nivel. Porque cuanto más cerca estamos del backend, más flexible es nuestra operatividad y el código front-end que más cambia es más fácil de escribir. En la práctica, debido a que los requisitos del producto cambian muy rápidamente y el ciclo de iteración es cada vez más corto, a veces es difícil distinguir claramente el controlador y el modelo. El almacenamiento en caché parcial es inevitable en el nivel del controlador, pero es necesario asegurarse de que esto sea así. sucede, el Controlador El caché que se opera no debe afectar a otras partes solicitantes de datos, es decir, se debe garantizar que estos datos almacenados en caché solo sean utilizados por este Controlador. Regla 2: el programa no puede cometer errores sin almacenamiento en caché. Sin considerar el efecto de avalancha causado por la invalidación del caché, su programa debe tener un caché y ser el mismo que sin caché. No puede ser como Sina Weibo. Una vez que el caché falla, el ventilador Weibo estará vacío y toda la aplicación estará. en mal estado. Cuando el almacenamiento en caché es esencial, darle al usuario un mensaje de error es mejor que darle un mensaje engañoso. Regla 3: las actualizaciones de la caché deben ser atómicas o seguras para subprocesos. Especialmente cuando se utiliza el almacenamiento en caché pasivo, es muy probable que el mismo caché se actualice cuando dos usuarios accedan a él. Por lo general, esto no es un gran problema y el caché se puede reconstruir. después de que expire. Esta puede ser una de las causas de la reacción en cadena. Regla 4: El almacenamiento en caché también tiene un coste. No sólo el coste de la tecnología, sino también el coste del tiempo de mano de obra. Si una función usa almacenamiento en caché y no lo usa, la diferencia en el volumen de acceso previsible es pequeña, pero el uso del almacenamiento en caché aumentará la complejidad, entonces no es necesario agregar una marca TODO y agregar procesamiento de almacenamiento en caché en la siguiente iteración.
Como se mencionó anteriormente, el almacenamiento de archivos es independiente, por lo que todas las operaciones con archivos son llamadas remotas. Puede proporcionar una interfaz RESTful muy simple en el servidor de archivos, o puede proporcionar un servicio xmlrpc o json. Todos los archivos generados y procesados por el servidor WEB se notifican al servidor de archivos a través de la interfaz para su procesamiento. para proporcionar almacenamiento de archivos. Por este motivo, descubrirá que cargar imágenes y guardar artículos en muchos sitios web grandes se realiza en dos pasos.
Lo anterior "mencionado antes" en realidad lo han dicho innumerables personas. Simplemente lo repetí con mis propias palabras basándose en los artículos anteriores. La esencia del análisis real es muy simple: además de una buena lógica funcional en capas, también necesitamos Diseño. interfaces separadas para llamadas de recursos externos, como almacenamiento de bases de datos, almacenamiento en caché, colas y servicios de archivos. Puede imaginar que su programa se ejecuta en Amazon EC2 y utiliza todos sus servicios web. Su base de datos es su SimpleDB. El almacenamiento es su S3. La única diferencia es que la interfaz de Amazon es una llamada remota y la suya es una llamada interna.
La interfaz del servicio de soporte significa que reemplazar MySQL con PostgreSQL no requiere cambios en el programa de procesamiento de negocios, y el equipo de migración ni siquiera necesita comunicarse demasiado con el equipo de desarrollo de negocios, lo que significa que el equipo de desarrollo de negocios está programando la interfaz; que programar la base de datos; significa que el rendimiento no se verá afectado por un error de un desarrollador de negocios.
Si no está interesado en el programa de alfabetización, mire aquí——
Una vez completado el diseño del producto y construido el marco del programa, pueden surgir conflictos en este momento. Hay constantes quejas de los diseñadores de productos de que sus ideas no logran los resultados deseados y los programadores se quejan de que los diseños de productos no son realistas. Este tipo de queja se debe principalmente al hecho de que el personal del producto no comprende la tecnología y el personal técnico no comprende los productos. En un sentido amplio, los productos incluyen estrategias de mercado, métodos de marketing y diseño funcional. Cuando se discute sobre productos y tecnologías, la atención se centra a menudo en la función, pero la atención real se centra en el costo de realizar esta función y los beneficios que conlleva. puede traer. Si se puede convertir y si se puede tener en cuenta. Si es posible, resuelva la disputa. Si no, lanza una moneda y mira suerte. Hay muchos ejemplos de indicadores que desaparecen debido a la mejora de una función o retrasos en el combate debido a retrasos en el proyecto. Los tomadores de decisiones radicales se centran en los beneficios, los tomadores de decisiones conservadores se centran en las pérdidas y los tomadores de decisiones inteligentes considerarán si el problema es realmente tan grave.
Nadie puede predecir lo que sucederá en el futuro, de lo contrario, la mitad de iniciar un negocio depende de la suerte. Pero siempre hay cosas que se pueden decir con precisión y hay que confiar en los datos para que hablen por sí solos.
No el 100%, pero el 99,9% de los sitios web tienen códigos de estadísticas de acceso instalados, incluso mi http://zhiyi.us no es una excepción, y Xinwen Network siempre habla sobre la toma de decisiones científicas y el desarrollo científico. Con las estadísticas se pueden determinar muchas cosas. Por ejemplo, puede analizar qué canales tienen el costo de adquisición per cápita más bajo en función de la tasa de conversión de origen a destino, adivinar los motivos de las tasas de rebote de los usuarios en función del acceso al contenido de origen y determinar si la posición del enlace es razonable en función del clic del usuario. comportamiento. Combine datos de diferentes maneras para encontrar conexiones internas, analizar factores internos y externos, formular estrategias correspondientes y reducir las decisiones difíciles. Depender de los datos para respaldar las operaciones es un asunto muy profesional. Aunque no entiendo modelos matemáticos profundos ni cálculos de fórmulas complejas, gradualmente aprendí que B se debe a A y C se debe a A y B. Sigue siendo relativamente simple. .
Autor del artículo: Liu Zhiyi (indique el enlace de origen y el autor al reimprimir)
Fuente del artículo: http://zhiyi.us/