| Un modelo industrial y producirlo rápidamente. "Rápido" es la primera prioridad y no es necesario gastar demasiada energía en el diseño arquitectónico. Solo cuando el sitio web entra en el período de expansión necesita invertir más energía en la arquitectura para transportar el tráfico del sitio web cuando explota. Ele.me se estableció durante 8 años y ahora el volumen de pedidos diarios ha superado los 9 millones. También tenemos una estructura de sitio web relativamente completa. |
1. Infraestructura del sitio web
Al principio utilizamos un marco que facilitaba la extensión de SOA. Usamos el marco SOA para resolver dos cosas:
1. División del trabajo y colaboración
En los primeros días de un sitio web, podía haber solo de 1 a 5 programadores, pero en ese momento todos podían estar ocupados con lo mismo. Todos entienden el trabajo de los demás y, a menudo, resuelven los problemas "gritando".
Pero a medida que aumenta el número de personas, este método obviamente no es factible: es imposible que una persona actualice el código y luego vuelva a poner en línea los códigos de todas las demás, ¿verdad? Por lo tanto, debemos considerar la cuestión de la división del trabajo y la colaboración.
2. Rápida expansión
En el pasado, el volumen de pedidos puede haber oscilado entre 1.000 y 10 000. Aunque se ha multiplicado por 10, el volumen total no es muy alto y la presión sobre un sitio web no es tan grande. Cuando el volumen de pedidos realmente pasa de 100.000 a 1.000.000, y de 1.000.000 a 2.000.000, es posible que el número solo se expanda 10 veces, pero es un gran desafío para la arquitectura de todo el sitio web.
Nuestros antecedentes van desde el avance de 1 millón en 2014 hasta los 9 millones actuales. El equipo técnico ha crecido de más de 30 personas al principio a un equipo de más de 900 personas ahora. En este momento, la división del trabajo y la colaboración son un gran desafío. La división e integración de servicios y la división e integración de equipos requieren un sistema marco que los respalde, lo que también es una función del marco SOA.
Eche un vistazo a nuestra situación actual: el medio es todo nuestro sistema de arquitectura y el lado derecho son algunos conceptos básicos relacionados con la servitización, incluidos los componentes o servicios básicos.
Hablemos primero del lenguaje: nuestro sitio web original se basó en PHP y luego nos transformamos lentamente.
Los fundadores son todos estudiantes universitarios que inician sus propios negocios, por lo que, por supuesto, Python es una buena primera opción. Hasta ahora Python también es una buena opción, pero ¿por qué deberíamos expandirnos a Java y Go?
Mucha gente puede escribir Python, pero no mucha gente puede hacerlo realmente bien. A medida que el negocio crece, se necesitan más desarrolladores. Teniendo en cuenta el entorno ecológico maduro de Java y el ecosistema Go emergente, finalmente elegimos un ecosistema donde Python, Java y Go coexisten en múltiples idiomas.
WebAPI realiza principalmente algunas operaciones comunes que no tienen nada que ver con la lógica empresarial, como la descarga HTTPS, la limitación actual y la verificación de seguridad.
Service Orchestrator es una capa de orquestación de servicios que realiza la conversión de protocolos de redes internas y externas y la agregación y adaptación de servicios a través de la configuración.
En el lado derecho del diagrama de arquitectura se encuentran algunos sistemas auxiliares que rodean estos marcos orientados a servicios, como el sistema Job para ejecutar regularmente una tarea. Contamos con cerca de 1.000 servicios ¿Cómo monitorizamos estos sistemas? Por eso debe haber un sistema de seguimiento. Cuando al principio solo había más de 30 personas, éramos mejores corriendo hacia la máquina para buscar registros, pero cuando hay más de 900 personas, no todos pueden ir a la máquina para buscar registros. un sistema de registro centralizado. Otros sistemas no se describirán uno por uno aquí.
Roma no se construyó en un día, la infraestructura es un proceso evolutivo. Nuestra energía es limitada, entonces, ¿qué debemos hacer primero?
2. División de servicios
A medida que el sitio web creció, la estructura original ya no pudo seguir el ritmo del desarrollo. Lo primero que debemos hacer es:
Divida el repositorio grande en un repositorio pequeño, divida el servicio grande en servicios pequeños y divida nuestros servicios básicos centralizados en diferentes máquinas físicas.
Sólo la división del servicio tardó más de un año en completarse, lo que fue un proceso relativamente largo.
En este proceso, primero debemos hacer una buena definición de la API. Porque una vez que su API está en línea, el costo de realizar algunas modificaciones es bastante alto. Habrá muchas personas que dependerán de su API y muchas veces no sabrá quién depende de su API, lo cual es un gran problema.
Luego abstraiga algunos servicios básicos. Muchos servicios originales en realidad están acoplados en el código comercial original. Por ejemplo, en el negocio de pagos, cuando el negocio es muy simple, el código estrechamente acoplado no importa, pero cuando cada vez más negocios se expanden y requieren servicios de pago, ¿tiene que hacer uno para cada negocio (como la función de pago)? ?? Por tanto, necesitamos extraer estos servicios básicos, como servicios de pago, servicios de SMS, servicios push, etc.
Desmantelar los servicios parece sencillo y de poco valor, pero eso es exactamente lo que tenemos que hacer desde el principio. De hecho, durante este período, todas las arquitecturas anteriores se pueden posponer, porque si no se hacen ajustes arquitectónicos, la gente no morirá, pero si no se desmantelan los servicios, la gente realmente morirá.
La división de servicios debe ser un proceso largo, pero en realidad es un proceso muy doloroso y requiere mucha ingeniería de sistemas de soporte.
3. Sistema de publicación
La liberación es el mayor factor desestabilizador. Muchas empresas tienen límites estrictos en los plazos de lanzamiento, por ejemplo:
- Sólo hay dos días a la semana en los que puedes publicar;
- Está absolutamente prohibido publicar durante los fines de semana;
- La publicación está absolutamente prohibida durante los períodos de mayor actividad comercial;
- etc……
Descubrimos que el mayor problema con la publicación es que no existe una operación de reversión ejecutable simple después de la publicación. ¿Quién realizará la operación de reversión? ¿Puede realizarla el personal de liberación o se requiere una persona dedicada para realizarla? Si es una editorial, la editorial no trabaja online las 24 horas del día, ¿qué debo hacer si hay un problema y no encuentro a alguien? Si hay una persona dedicada a realizar la reversión y no existe una operación de reversión simple y unificada, entonces esta persona debe estar familiarizada con el código del editor, lo cual básicamente no es factible.
Entonces necesitamos un sistema de publicación. El sistema de publicación define una operación de reversión unificada. Todos los servicios deben seguir la operación de reversión definida por el sistema de publicación.
Es un requisito obligatorio para todos conectarse al sistema de publicación en Ele.me. Todos los sistemas deben estar conectados al sistema de publicación. El marco del sistema de publicación es muy importante, esto en realidad es muy importante para la empresa y debe considerarse en la cola de primera prioridad.
4. Marco de servicio
El siguiente es el marco de servicios de Ele.me, que divide un Repo grande en un Repo pequeño y un servicio grande en un servicio pequeño, para que nuestros servicios puedan ser lo más independientes posible, lo que requiere un conjunto de servicios distribuidos. .
El marco de servicios distribuidos incluye registro de servicios, descubrimiento, equilibrio de carga, enrutamiento, control de flujo, disyuntores, degradación y otras funciones, que no se discutirán una por una aquí. Como se mencionó anteriormente, Ele.me es un ecosistema multilingüe, que incluye Python y Java, y nuestro marco orientado a servicios también es multilingüe. Esto tendrá un impacto en nuestra selección posterior de algún middleware, como la capa DAL.
5. Capa de acceso a datos DAL
Cuando el volumen de negocios sea cada vez mayor, la base de datos se convertirá en un cuello de botella.
En la etapa inicial, el rendimiento de la base de datos se puede mejorar actualizando el hardware. Por ejemplo:
- Actualice a una máquina con más CPU;
- Cambia el disco duro a un SSD o algo más avanzado.
Pero, en última instancia, la mejora del hardware tiene un límite de capacidad. Además, muchos socios comerciales operan directamente la base de datos al escribir código y ha habido muchos casos en los que la base de datos explotó tan pronto como el servicio se puso en línea. Una vez destruida la base de datos, no hay otra posibilidad de restaurar el negocio a menos que se restaure la base de datos.
Si los datos de la base de datos son normales, la empresa puede compensarlos. Entonces, cuando construimos la capa de servicio DAL, lo primero que debemos hacer es limitar el flujo de corriente y se pueden dejar de lado otras cosas. Luego, para la reutilización de la conexión, nuestro marco Python utiliza un modelo multiproceso, de un solo subproceso y de rutina.
De hecho, varios procesos no pueden compartir una conexión. Por ejemplo: se implementan 10 procesos de Python en una máquina y cada proceso tiene 10 conexiones de base de datos. Ampliando a 10 máquinas, hay 1000 conexiones de bases de datos. Para las bases de datos, las conexiones son algo muy costoso y nuestra capa DAL necesita reutilizar las conexiones.
Esta reutilización de la conexión no se trata de la reutilización de la conexión del servicio en sí, sino de la reutilización de la conexión en la capa DAL. Es decir, el servicio tiene 1000 conexiones a la capa DAL. Después de la reutilización de la conexión, solo puede mantener una docena de conexiones a la base de datos. . . Una vez que se descubre que una solicitud de base de datos es una transacción, DAL lo ayudará a conservar la relación correspondiente de esta conexión. Cuando finaliza la transacción, la conexión de la base de datos se vuelve a colocar en el grupo compartido para que otros la utilicen.
Luego fuma y fusiona. La base de datos también puede fusionarse. Cuando la base de datos fuma, eliminaremos algunas solicitudes de la base de datos para asegurarnos de que la base de datos no falle.
6. Gobernanza del servicio
Después del marco de servicios, se trata de la cuestión de la gobernanza de los servicios. La gobernanza de servicios es en realidad un gran concepto. El primero es enterrar puntos, es necesario enterrar muchos puntos de monitoreo.
Por ejemplo, si hay una solicitud, si la solicitud fue exitosa o fallida y cuál es el tiempo de respuesta de la solicitud, coloque todos los indicadores de monitoreo en el sistema de monitoreo. Disponemos de una gran pantalla de seguimiento con muchos indicadores de seguimiento. Hay un equipo dedicado vigilando esta pantalla las 72 horas del día, si hay alguna fluctuación en la curva, se encontrará a alguien para solucionarlo. El otro es el sistema de alarma. Las cosas que se muestran en una pantalla de monitoreo siempre son limitadas y solo pueden mostrar aquellos indicadores clave muy importantes. En este momento se necesita un sistema de alarma.
Roma no se construyó en un día y la infraestructura es un proceso evolutivo. Nuestros recursos y tiempo son siempre limitados. Como arquitecto y CTO, ¿cómo podemos producir cosas más importantes con recursos tan limitados?
Hemos construido muchos sistemas y sentimos que hemos hecho un buen trabajo, pero en realidad no es así. Siento que hemos regresado a la Edad de Piedra, porque cada vez hay más problemas y más demandas. Siempre se siente así. como si faltara algo en su sistema. Hay muchas cosas y funciones que quiero hacer.
Por ejemplo, para el sistema de control de flujo, todavía necesitamos que el usuario configure un número de concurrencia, entonces, ¿no necesita el usuario configurar este número de concurrencia en absoluto? ¿Es posible controlar automáticamente el número de concurrencia en función del estado de nuestro servicio?
Luego está el método de actualización: la actualización del SDK es algo muy doloroso. Por ejemplo, nuestro marco de servicio 2.0 se lanzó en diciembre del año pasado y algunas personas todavía usan 1.0. ¿Es posible lograr una actualización del SDK sin pérdidas? Podemos controlar el tiempo y el ritmo de la actualización nosotros mismos.
Además, nuestro monitoreo actual solo admite la agregación en el mismo servicio y no está dividido en clústeres o máquinas. Entonces, ¿se pueden dividir los indicadores futuros en clústeres y máquinas? Para dar el ejemplo más simple, si hay 10 máquinas en un servicio, puede haber un problema solo en una máquina, pero todos sus indicadores se distribuirán uniformemente a las otras 9 máquinas. Simplemente ve un aumento en la latencia general del servicio, pero es posible que solo una máquina esté ralentizando todo el clúster de servicios. Pero todavía no podemos monitorear en más dimensiones.
También existen alarmas inteligentes. Esta alarma tiene que ser rápida, completa y precisa. Ahora podemos hacerlo de forma más rápida y completa. ¿Cómo podemos hacerlo con mayor precisión? Durante las horas pico de cada día, se envían más de 1.000 alarmas cada minuto. ¿Son útiles las mil alarmas? Después de llamar a la policía demasiadas veces, equivale a no llamar a la policía en absoluto. Todos estaban cansados y dejaron de mirar. ¿Cómo puedo distinguir esta alarma con mayor precisión? ¿Existe un análisis de enlaces más inteligente? En el futuro, ¿no deberíamos incluir indicadores de seguimiento en nuestro seguimiento, sino análisis de enlaces, para que podamos saber claramente a qué nodo corresponde el problema?
Estas preguntas implican un principio de nuestro trabajo: mientras las cosas sean suficientes, debemos poder planificar y planificar con antelación.