Este artículo se transfiere de [ Titulares de hoy ]
Este artículo utiliza Taobao como un ejemplo para presentar el proceso de evolución de la arquitectura del servidor de 100 concurrentes a decenas de millones de concurrencia. También enumera las tecnologías relevantes encontradas en cada etapa de evolución, para que todos puedan tener una comprensión general de la evolución de la arquitectura. Al final, el artículo resume algunos principios del diseño arquitectónico.
Antes de presentar la arquitectura, para evitar que algunos lectores no entiendan algunos conceptos en el diseño de la arquitectura, estos son algunos de los conceptos más básicos:
① Distribuido: se implementan varios módulos en el sistema en diferentes servidores, lo que se puede llamar un sistema distribuido. Por ejemplo, Tomcat y la base de datos se implementan en diferentes servidores, o dos Tomcats con la misma función se implementan en diferentes servidores.
② Alta disponibilidad: cuando algunos nodos del sistema fallan y otros nodos pueden asumir el control para continuar brindando servicios, se puede considerar que el sistema tiene alta disponibilidad.
LusCluster: un campo específico de software se implementa en varios servidores y proporciona un tipo de servicio en su conjunto, este conjunto se denomina clúster.
Por ejemplo, el Maestro y el Esclavo en Zookeeper se implementan en múltiples servidores para formar un todo para proporcionar servicios de configuración centralizados.
En un clúster común, el cliente a menudo puede conectarse a cualquier nodo para obtener servicio, y cuando un nodo en el clúster se desconecta, otros nodos pueden reemplazarlo automáticamente para continuar proporcionando servicios, lo que muestra que el clúster tiene alta disponibilidad.
④ Equilibrio de carga: cuando la solicitud se envía al sistema, la solicitud se distribuye uniformemente a múltiples nodos de alguna manera, de modo que cada nodo en el sistema pueda manejar la carga de la solicitud de manera uniforme, entonces el sistema puede considerarse como una carga equilibrada.
Proxy Proxy de reenvío y proxy inverso: cuando el sistema quiere acceder a la red externa, la solicitud se reenvía a través de un servidor proxy de manera unificada. Desde la perspectiva de la red externa, es el acceso iniciado por el servidor proxy. En este momento, el servidor proxy implementa un proxy de reenvío.
Cuando una solicitud externa ingresa al sistema, el servidor proxy reenvía la solicitud a un servidor en el sistema. Para la solicitud externa, solo el servidor proxy interactúa con ella. En este momento, el servidor proxy implementa un proxy inverso.
En términos simples, el proxy directo es el proceso que el servidor proxy reemplaza al sistema interno para acceder a la red externa, y el proxy inverso es el proceso que el servidor externo reenvía al servidor interno a través del servidor proxy cuando solicita acceso al sistema.
Evolución de la arquitectura
Arquitectura independiente
Tomemos a Taobao como ejemplo: al comienzo del sitio web, el número de aplicaciones y el número de usuarios son pequeños, y puede implementar Tomcat y la base de datos en el mismo servidor.
Cuando el navegador inicia una solicitud a www.taobao.com , primero convierte el nombre de dominio a la dirección IP real 10.102.4.1 a través del servidor DNS (sistema de nombre de dominio), y el navegador accede a Tomcat correspondiente a la IP.
A medida que aumenta el número de usuarios, los recursos compiten entre Tomcat y la base de datos, y el rendimiento independiente es insuficiente para respaldar el negocio.
Primera evolución: Tomcat se implementa por separado de la base de datos
Tomcat y la base de datos monopolizan los recursos del servidor respectivamente, mejorando significativamente su rendimiento respectivo. A medida que aumenta el número de usuarios, las bases de datos de lectura y escritura concurrentes se convierten en un cuello de botella.
Segunda evolución: introducción de caché local y caché distribuida
Agregue un caché local en el mismo servidor que Tomcat o la misma JVM, y agregue un caché distribuido externamente para almacenar en caché información de productos populares o páginas HTML de productos populares.
El caché puede interceptar la mayoría de las solicitudes antes de leer y escribir en la base de datos, lo que reduce en gran medida la presión de la base de datos.
Las tecnologías involucradas incluyen el uso de Memcached como caché local y Redis como caché distribuida, así como problemas como la consistencia del caché, penetración / descomposición del caché, avalanchas de caché e invalidación de conjuntos de datos de puntos de acceso.
El caché resiste la mayoría de las solicitudes de acceso. A medida que crece el número de usuarios, la presión de concurrencia recae principalmente en el Tomcat autónomo, y la respuesta se ralentiza gradualmente.
La tercera evolución: la introducción del proxy inverso para lograr el equilibrio de carga
Implemente Tomcat en varios servidores por separado y use el software de proxy inverso (Nginx) para distribuir la solicitud de manera uniforme a cada Tomcat.
Aquí se supone que Tomcat admite un máximo de 100 concurrencias y Nginx admite un máximo de 50,000 concurrencias. En teoría, Nginx puede distribuir solicitudes a 500 Tomcats, que pueden resistir 50000 concurrencias.
Las tecnologías involucradas incluyen: Nginx y HAProxy, los cuales son software de proxy inverso que trabaja en la séptima capa de la red. Admiten principalmente el protocolo HTTP, y también involucran el intercambio de sesiones y problemas de carga y descarga de archivos.
El proxy inverso aumenta en gran medida la cantidad de concurrencia que el servidor de aplicaciones puede soportar, pero el aumento en la cantidad de concurrencia también significa que más solicitudes penetran en la base de datos, y la base de datos independiente eventualmente se convierte en un cuello de botella.
La cuarta evolución: separación de base de datos de lectura-escritura
Divida la base de datos en una biblioteca de lectura y una biblioteca de escritura. Puede haber múltiples bibliotecas de lectura. Sincronice los datos de la biblioteca de escritura con la biblioteca de lectura a través del mecanismo de sincronización. Para el escenario donde se deben consultar los últimos datos escritos, escriba una copia más en el caché Caché para obtener los últimos datos.
Las tecnologías involucradas incluyen: Mycat, que es un middleware de base de datos, que se puede utilizar para organizar la lectura y escritura por separado de la base de datos y la subbase de datos y subtabla. El cliente accede a la base de datos subyacente a través de ella, y también involucra problemas de sincronización de datos y consistencia de datos. .
Las empresas están aumentando gradualmente, y la brecha en el acceso entre las diferentes empresas es grande. Diferentes empresas compiten directamente por las bases de datos y afectan el rendimiento de las demás.
Quinta evolución: la base de datos se divide en bases de negocios
Guardar datos de diferentes empresas en diferentes bases de datos reduce la competencia de recursos entre las empresas. Para las empresas con una gran cantidad de visitas, se pueden implementar más servidores para admitirlas.
Al mismo tiempo, las tablas de negocios cruzados no pueden correlacionarse directamente y deben resolverse a través de otros canales, pero este no es el enfoque de este artículo: los interesados pueden buscar soluciones por sí mismos. A medida que aumenta el número de usuarios, la biblioteca de escritura independiente alcanzará gradualmente el cuello de botella de rendimiento.
Sexta evolución: dividir tablas grandes en tablas más pequeñas
Por ejemplo, para los datos de revisión, puede hacer hash de acuerdo con la ID del producto y enrutarlo a la tabla correspondiente para el almacenamiento; para los registros de pago, puede crear una tabla por hora, y cada tabla de horas continúa dividiéndose en tablas pequeñas, utilizando la ID de usuario o el número de registro para enrutar los datos .
Siempre que la cantidad de datos de la tabla para operaciones en tiempo real sea lo suficientemente pequeña y las solicitudes se puedan distribuir a tablas pequeñas en varios servidores de manera uniforme, la base de datos puede mejorar el rendimiento mediante la expansión horizontal. Entre ellos, Mycat mencionado anteriormente también admite el control de acceso cuando la tabla grande se divide en tablas pequeñas.
Este enfoque aumenta significativamente la dificultad de operación y mantenimiento de la base de datos, y tiene mayores requisitos para los DBA. Cuando la base de datos está diseñada para esta estructura, ya se puede llamar una base de datos distribuida.
Pero esto es solo una base de datos lógica en su conjunto. Diferentes componentes en la base de datos son implementados por diferentes componentes por separado.
Por ejemplo, Mycat implementa la gestión y distribución de solicitudes de subbibliotecas y subtablas. El análisis de SQL se implementa en una base de datos de una sola máquina. La puerta de enlace y la cola de mensajes pueden implementar la separación de lectura y escritura. Esta arquitectura es en realidad un tipo de implementación de la arquitectura MPP (procesamiento paralelo en masa).
En la actualidad, hay muchas bases de datos MPP tanto en aplicaciones de código abierto como comerciales. Entre las de código abierto, Greenplum, TiDB, Postgresql XC, HAWQ, etc., como GBase de Nanda General, Snowball DB de Ruifan Technology, LibrA de Huawei, etc.
Las diferentes bases de datos MPP tienen un énfasis diferente: por ejemplo, TiDB se enfoca más en escenarios OLTP distribuidos y Greenplum se enfoca más en escenarios OLAP distribuidos.
Estas bases de datos MPP básicamente proporcionan capacidades de soporte estándar de SQL como Postgresql, Oracle y MySQL. Pueden analizar una consulta en un plan de ejecución distribuido y distribuirlo a cada máquina para ejecución paralela. Finalmente, la base de datos agrega los datos y los devuelve.
También proporciona capacidades tales como administración de derechos, división de bases de datos y tablas, transacciones y copias de datos, y la mayoría de ellas pueden admitir clústeres de más de 100 nodos, lo que reduce en gran medida el costo de operación y mantenimiento de la base de datos, y permite que la base de datos logre una expansión horizontal.
Tanto la base de datos como Tomcat pueden expandirse horizontalmente, y la concurrencia soportable se mejora enormemente. Con el crecimiento del número de usuarios, el Nginx de la única máquina eventualmente se convertirá en un cuello de botella.
Séptima evolución: use LVS o F5 para equilibrar la carga de múltiples Nginx
Debido a que el cuello de botella está en Nginx, es imposible lograr el equilibrio de carga de múltiples Nginx a través de dos capas de Nginx.
El LVS y F5 en la figura son soluciones de equilibrio de carga que funcionan en la cuarta capa de la red. LVS es un software que se ejecuta en el estado del núcleo del sistema operativo y puede reenviar solicitudes TCP o protocolos de red de nivel superior.
Por lo tanto, los protocolos admitidos son más abundantes y el rendimiento es mucho más alto que Nginx. Se puede suponer que un solo LVS puede soportar cientos de miles de reenvíos de solicitudes concurrentes; F5 es un hardware de equilibrio de carga, similar a las capacidades proporcionadas por LVS, y el rendimiento es más que LVS Alto, pero caro.
Debido a que LVS es una versión independiente del software, si el servidor donde se ubica LVS se cae, no se podrá acceder a todo el sistema de fondo, por lo que se requiere un nodo en espera.
Puede usar el software Keepalived para simular la IP virtual y luego vincular la IP virtual a múltiples servidores LVS. Cuando el navegador accede a la IP virtual, el enrutador lo redirigirá al servidor LVS real.
Cuando el servidor LVS principal se cae, el software Keepalived actualizará automáticamente la tabla de enrutamiento en el enrutador y redirigirá la IP virtual a otro servidor LVS normal, logrando así el efecto de alta disponibilidad del servidor LVS.
Cabe señalar aquí que el dibujo de la capa de Nginx a la capa de Tomcat en la figura anterior no significa que todas las solicitudes de reenvío de Nginx a todos los Tomcat.
En el uso real, puede ser que varios Nginx estén conectados a una parte de Tomcat, y estos Nginx se realicen a través de Keepalived para alta disponibilidad, y el otro Nginx esté conectado a otro Tomcat, de modo que la cantidad de Tomcat accesible pueda duplicarse.
Dado que LVS también es independiente, ya que el número de concurrencia crece a cientos de miles, el servidor LVS eventualmente alcanzará un cuello de botella. En este momento, el número de usuarios llega a 10 millones o incluso cientos de millones. Los usuarios están distribuidos en diferentes regiones, y la distancia desde la sala de servidores es diferente, lo que resulta en El retraso del acceso será significativamente diferente.
La octava evolución: equilibrio de carga de salas de máquinas a través de encuestas DNS
Se puede configurar un nombre de dominio en el servidor DNS correspondiente a múltiples direcciones IP, y cada dirección IP corresponde a una IP virtual en una sala de computadoras diferente.
Cuando un usuario visita www.taobao.com , el servidor DNS utiliza una estrategia de sondeo u otras estrategias para seleccionar una IP para que el usuario acceda.
De esta manera, se puede lograr el equilibrio de carga de la sala de computadoras. En este punto, el sistema puede lograr la expansión horizontal del nivel de la sala de computadoras. La concurrencia de decenas de millones a 100 millones se puede resolver aumentando la sala de computadoras. El número de solicitudes simultáneas en la entrada del sistema ya no es un problema .
Con la riqueza de datos y el desarrollo de los negocios, la demanda de recuperación y análisis es cada vez más abundante. Confiar en la base de datos por sí sola no puede resolver una demanda tan rica.
La novena evolución: introducción de tecnologías como bases de datos NoSQL y motores de búsqueda
Cuando los datos en la base de datos alcanzan cierto tamaño, la base de datos no es adecuada para consultas complejas y, a menudo, solo puede cumplir con los escenarios de consulta comunes.
Para escenarios de informes estadísticos, es posible que los resultados no se puedan agotar cuando la cantidad de datos es grande, y provocará que otras consultas se ralenticen al ejecutar consultas complejas.Para escenarios como la recuperación de texto completo y estructuras de datos variables, la base de datos es inherentemente inaplicable.
Por lo tanto, es necesario introducir soluciones adecuadas para escenarios específicos. Para el almacenamiento masivo de archivos, se puede resolver a través del sistema de archivos distribuido HDFS.
Para los datos de tipo Key Value, se puede resolver a través de soluciones como HBase y Redis. Para escenarios de recuperación de texto completo, se puede resolver mediante motores de búsqueda como ElasticSearch. Para escenarios de análisis multidimensional, Kylin o Druid pueden resolverlo.
Por supuesto, la introducción de más componentes aumentará la complejidad del sistema al mismo tiempo: los datos guardados por diferentes componentes deben sincronizarse, debe considerarse la coherencia y se necesitan más operaciones y métodos de mantenimiento para administrar estos componentes.
Al introducir más componentes para resolver la rica demanda, la dimensión empresarial se puede ampliar en gran medida, y luego viene una aplicación que contiene demasiado código comercial, y la actualización empresarial iterativa se vuelve difícil.
Décima evolución: gran aplicación dividida en pequeñas aplicaciones
El código de la aplicación se divide según el sector empresarial para aclarar las responsabilidades de las aplicaciones individuales, y cada una puede actualizarse e iterarse de forma independiente.
En este momento, algunas configuraciones comunes pueden estar involucradas entre aplicaciones, lo que se puede resolver a través del centro de configuración distribuido Zookeeper.
Existen módulos comunes entre diferentes aplicaciones, y la administración separada de las aplicaciones dará como resultado múltiples copias del mismo código, lo que resultará en la actualización de todos los códigos de aplicación cuando se actualicen las funciones públicas.
La undécima evolución: la reutilización de múltiples funciones en microservicios
Si la administración de usuarios, pedidos, pagos, autenticación y otras funciones existen en múltiples aplicaciones, entonces el código de estas funciones se puede extraer por separado para formar un servicio separado para la administración.
Dicho servicio es un denominado microservicio, y las aplicaciones y servicios acceden a los servicios públicos a través de solicitudes HTTP, TCP o RPC y otros métodos. Cada servicio individual puede ser administrado por un equipo separado.
Además, se pueden implementar servicios como la gobernanza de servicios, la limitación actual, la fusión y la degradación a través de Dubbo, Spring Cloud y otros marcos para mejorar la estabilidad y la disponibilidad de los servicios.
Los diferentes servicios tienen diferentes métodos de acceso a la interfaz, y los códigos de aplicación deben adaptarse a los métodos de acceso múltiple para usar los servicios.
Además, las aplicaciones acceden a servicios, y los servicios también pueden acceder entre sí. La cadena de llamadas se volverá muy complicada y la lógica se volverá caótica.
Duodécima evolución: introducción del bus de servicio empresarial ESB para proteger las diferencias de acceso de las interfaces de servicio
La conversión del protocolo de acceso unificado a través de ESB, las aplicaciones acceden uniformemente a los servicios de fondo a través de ESB, y los servicios y servicios también se llaman entre sí a través de ESB, reduciendo así el grado de acoplamiento del sistema.
Esta aplicación única se divide en múltiples aplicaciones, los servicios públicos se extraen por separado para la administración y el bus de mensajes de la empresa se utiliza para resolver el problema del acoplamiento entre servicios. Esta es la denominada arquitectura SOA (orientada a servicios). Esta arquitectura está relacionada con los microservicios. La arquitectura es fácil de confundir porque la forma de expresión es muy similar.
Personalmente entiendo, la arquitectura de microservicios se refiere más a la idea de extraer los servicios públicos en el sistema para la gestión separada de operación y mantenimiento, y la arquitectura SOA se refiere a una idea arquitectónica de dividir servicios y unificar el acceso a la interfaz de servicio. Se incluye la idea de microservicios.
Con el desarrollo continuo de los negocios, las aplicaciones y los servicios continuarán aumentando, la implementación de aplicaciones y servicios se complica y la implementación de múltiples servicios en el mismo servidor también debe resolver el problema de los entornos operativos en conflicto.
Además, para escenarios que requieren una expansión y contracción dinámica, como una gran promoción, si necesita expandir horizontalmente el rendimiento del servicio, debe preparar el entorno operativo en el servicio recién agregado, implementar el servicio, etc., y la operación y el mantenimiento serán muy difíciles.
Decimotercera evolución: introducción de la tecnología de contenedorización para lograr el aislamiento del entorno operativo y la gestión dinámica del servicio.
Actualmente, la tecnología de contenedorización más popular es Docker, y el servicio de administración de contenedores más popular es Kubernetes (K8S). Las aplicaciones / servicios se pueden empaquetar como imágenes de Docker, y las imágenes se distribuyen e implementan dinámicamente a través de K8S.
La imagen de Docker se puede entender como un sistema operativo mínimo que puede ejecutar su aplicación / servicio, donde se coloca el código de ejecución de la aplicación / servicio y el entorno operativo se configura de acuerdo con las necesidades reales.
Después de que todo el "sistema operativo" se empaqueta como una imagen, se puede distribuir a las máquinas que necesitan implementar servicios relacionados, y el inicio directo de la imagen de Docker puede activar el servicio, simplificando la implementación, operación y mantenimiento del servicio.
Antes de la gran promoción, puede dividir el servidor en el clúster de máquinas existente para iniciar la imagen de Docker para mejorar el rendimiento del servicio. Después de la gran promoción, puede cerrar el espejo sin afectar otros servicios en la máquina (antes, el servicio se estaba ejecutando La configuración del sistema debe modificarse en la máquina recién agregada para adaptarse al servicio, lo que conducirá a la destrucción del entorno operativo requerido por otros servicios en la máquina).
Después de utilizar la tecnología de contenedorización, se puede resolver el problema de la expansión dinámica y la contracción de los servicios, pero la máquina aún debe ser administrada por la empresa. El costo es extremadamente alto y la tasa de utilización de recursos es baja.
Decimocuarta evolución: sistema de transporte con plataforma en la nube
El sistema se puede implementar en la nube pública, utilizando los recursos masivos de la máquina de la nube pública para resolver el problema de los recursos dinámicos de hardware.
En el período de tiempo de la gran promoción, solicite más recursos temporalmente en la plataforma en la nube, combine Docker y K8S para implementar servicios rápidamente, libere recursos después de la gran promoción, realmente pague a pedido, y la tasa de utilización de recursos mejora considerablemente. Reduce en gran medida los costos de operación y mantenimiento.
La denominada plataforma en la nube consiste en abstraer una gran cantidad de recursos de la máquina en un recurso completo a través de la gestión unificada de recursos. En la parte superior, puede solicitar dinámicamente recursos de hardware (como CPU, memoria, red, etc.) a pedido y proporcionar operaciones generales en él. Sistema.
Proporcione componentes técnicos de uso común (como la pila de tecnología Hadoop, la base de datos MPP, etc.) para que los usuarios los utilicen, e incluso proporcione aplicaciones desarrolladas, los usuarios pueden resolver las necesidades (como servicios de transcodificación de audio y video, correo electrónico Servicios, blogs personales, etc.).
Los siguientes conceptos estarán involucrados en la plataforma en la nube:
- IaaS: Infraestructura como servicio. En correspondencia con los recursos de la máquina mencionados anteriormente se unifican en todo el recurso, el nivel de recursos de hardware se puede aplicar dinámicamente.
- PaaS: Plataforma como servicio. En correspondencia con lo anterior, se proporcionan componentes técnicos comunes para facilitar el desarrollo y mantenimiento del sistema.
- SaaS: software como servicio. En correspondencia con la provisión mencionada anteriormente de aplicaciones o servicios desarrollados, el pago se realiza de acuerdo con los requisitos de función o rendimiento.
Hasta ahora, desde el problema de acceso de alta concurrencia mencionado anteriormente, hasta la arquitectura de servicio y el nivel de implementación del sistema, existen soluciones respectivas.
Pero al mismo tiempo, también debe tenerse en cuenta que en la introducción anterior, los problemas reales como la sincronización de datos entre salas de computadoras y la implementación de transacciones distribuidas se ignoran intencionalmente. Estos problemas tendrán la oportunidad de ser discutidos por separado más adelante.
Resumen de diseño de arquitectura
① ¿El ajuste de la estructura tiene que seguir el camino de evolución anterior?
No, la secuencia de evolución de la arquitectura mencionada anteriormente es solo para la mejora individual en un cierto lado. En el escenario real, puede haber varios problemas por resolver al mismo tiempo, o el cuello de botella puede ser alcanzado por otro aspecto en este momento. Debe resolverse de acuerdo con los problemas reales.
Por ejemplo, en el caso de los sitios web del gobierno, la concurrencia puede no ser grande, pero el negocio puede ser muy rico. La alta concurrencia no es un problema a resolver. En este momento, la solución que se requiere primero es una gran demanda.
② ¿En qué medida debe diseñarse la arquitectura para que se implemente el sistema?
Para un sistema de implementación única con indicadores de rendimiento claros, es suficiente diseñar la arquitectura para admitir los indicadores de rendimiento del sistema, pero dejar una interfaz para ampliar la arquitectura de modo que no sea necesaria.
Para los sistemas en evolución, como las plataformas de comercio electrónico, deben diseñarse para cumplir con los requisitos de la próxima etapa de volumen de usuario e indicadores de rendimiento, y la arquitectura debe actualizarse iterativamente de acuerdo con el crecimiento del negocio para admitir una mayor concurrencia y servicios más ricos. .
Hat¿Cuál es la diferencia entre la arquitectura del lado del servidor y la arquitectura de big data?
El llamado "big data" es en realidad un término general para soluciones para escenarios tales como recolección masiva de datos, limpieza, conversión, almacenamiento de datos, análisis de datos y servicios de datos. Cada escenario contiene múltiples tecnologías opcionales.
Por ejemplo, la recopilación de datos incluye Flume, Sqoop, Kettle, etc., el almacenamiento de datos incluye sistemas de archivos distribuidos HDFS, FastDFS, bases de datos NoSQL HBase, MongoDB, etc., y el análisis de datos incluye la pila de tecnología Spark, algoritmos de aprendizaje automático, etc.
En general, la arquitectura de big data es una arquitectura que integra varios componentes de big data de acuerdo con las necesidades del negocio, y generalmente proporciona almacenamiento distribuido, computación distribuida, análisis multidimensional, almacén de datos, algoritmos de aprendizaje automático y otras capacidades.
La arquitectura del lado del servidor se refiere más a la arquitectura a nivel de organización de la aplicación, y las capacidades subyacentes a menudo son proporcionadas por la arquitectura de big data.
④ ¿Hay algún principio de diseño arquitectónico?
Los principios de diseño son los siguientes:
- Diseño N + 1. Todos los componentes del sistema deben estar libres de puntos únicos de falla.
- Diseño de retroceso. Asegúrese de que el sistema sea compatible con versiones anteriores y de que haya una forma de revertir la versión cuando se actualice el sistema.
- Desactiva el diseño. Debe proporcionar una configuración para controlar si hay funciones específicas disponibles, y puede desconectarse rápidamente cuando el sistema falla.
- Diseño de monitoreo. En la etapa de diseño, debemos considerar los medios de monitoreo.
- Diseño de centro de datos multivive. Si el sistema requiere una disponibilidad extremadamente alta, debería considerar implementar múltiples actividades en múltiples centros de datos, ya que el sistema aún está disponible cuando al menos una sala de computadoras está apagada.
- Utiliza tecnología madura. Las tecnologías de código abierto o recientemente desarrolladas a menudo tienen muchos errores ocultos. Si hay un problema, ningún soporte comercial puede ser un desastre.
- Diseño de aislamiento de recursos. Un solo servicio debe evitar todos los recursos.
- La arquitectura debería poder escalar horizontalmente. Solo cuando el sistema puede expandirse horizontalmente se pueden evitar efectivamente los problemas de cuello de botella.
- No se compra el núcleo. Si las funciones no centrales requieren una gran cantidad de recursos de I + D para resolver, considere comprar productos maduros.
- Use hardware comercial. El hardware comercial puede reducir efectivamente la probabilidad de falla del hardware.
- Iterar rápidamente. El sistema debe desarrollar rápidamente pequeños módulos de funciones, conectarse en línea lo antes posible para la verificación y encontrar problemas temprano para reducir en gran medida el riesgo de entrega del sistema.
- Diseño sin estado. La interfaz de servicio debe hacerse sin estado, y el acceso actual a la interfaz no depende del estado de la última interfaz accedida.
Autor: China, Oushi
Introducción: tiene muchos años de experiencia en desarrollo en el campo de big data, comprende las tecnologías de big data más utilizadas y tiene cierta experiencia en diseño de arquitectura, alta concurrencia y distribución. Me gusta aprender nuevas tecnologías y estoy feliz de compartir. Bienvenido a seguir mi blog SegmentFault: huashiou.
aficionados a la ópera en el sub-: Autor
enlace: https: //www.jianshu.com/p/537b3ee7229d
Fuente: libros de Jane
tienen derechos de autor por el autor. Para la reproducción comercial, comuníquese con el autor para obtener autorización, y para la reproducción no comercial, indique la fuente.