Sistema de visualización inteligente. Evolución de la arquitectura del servicio Atom.

Autor: Bump hombre - Manjiz

¿Qué es el átomo? Atom es una plataforma que integra todo tipo de diseñadores senior de comercio electrónico en la industria y ofrece servicios profesionales de diseño de programas y páginas inteligentes profesionales. Después de 2 años de iteraciones compactas, el proyecto se está volviendo cada vez más grande, los requisitos cambian y se optimizan constantemente, la lógica interna es complicada y los costos de mantenimiento están aumentando drásticamente. Al mismo tiempo, Atom ofrecerá más y más servicios y prestará servicios a más usuarios internos y comerciantes. Para adaptarse a estos cambios, las actualizaciones estructurales se convirtieron en un asunto urgente en ese momento. Deconstruiremos el módulo del lado del servidor para que el servicio sea ligero y modular. Para ampliar más fácilmente los escenarios empresariales.

El servidor Atom ha pasado por tres versiones de iteración, este artículo se centra en el análisis de la tercera versión.

Arquitectura 1.0

Esta es la versión más antigua de Atom. En esta versión, solo se planifica la función de la página del canal. El propósito es liberar a los desarrolladores del complicado desarrollo de la página del canal. Debido a que el propósito de la función es puro, la complejidad del sistema es baja. El servidor se desarrolla directamente utilizando el marco Koa. Este es un servicio monolítico. Todo el código se ejecuta en un proceso.

En términos de implementación, se utiliza una operación manual muy original: el desarrollador inicia sesión en la máquina, extrae el código e instala e inicia de manera similar al entorno local, y luego repite este proceso en diferentes máquinas.

Además, la versión anterior de Quark utiliza componentes con nombre.Los componentes con nombre limitan la escalabilidad de Quark en cierta medida, y no se expandirán aquí.

Arquitectura 2.0

Desde la plataforma de creación de páginas de canal hasta la plataforma de creación de páginas de escenarios múltiples, Atom usó menos de un año, componentes más ricos, más plantillas, más escenas, más diseñadores participantes, más usuarios, productos El desarrollo se está volviendo más especializado, y la operación y el mantenimiento manuales simples ya no son aplicables, por lo que el front-end y el servidor se han sometido a un importante intercambio de sangre. El servidor se reconstruye con Salak . Salak es un muy buen marco de servidores, y nos ha traído Para la función de generación automática de documentos de interfaz, tanto el front-end como el servidor dependen de Talos (una plataforma interna de implementación en contenedores) para su implementación. El servidor entró gradualmente en la era industrial.

Sin embargo, en esta etapa, el extenso método de desarrollo no se ha resuelto y la falta de planificación macro ha expuesto cada vez más los siguientes problemas:

• Altamente concentrado

  Más del 90% de los servicios se concentran en una sola arquitectura, el negocio es cada vez más complejo, el volumen del código aumenta, la legibilidad, la capacidad de mantenimiento y la escalabilidad del código disminuyen, el costo del acceso del desarrollador aumenta y el negocio se expande El costo ha aumentado exponencialmente, lo que dificulta la capacidad de entrega continua. Con más y más usuarios, la concurrencia que el programa tiene es cada vez mayor, y la capacidad de concurrencia de la aplicación de la arquitectura monolítica es limitada. A medida que aumenta la complejidad del sistema, la dificultad de las pruebas se vuelve cada vez más difícil.

• Alto acoplamiento

  Los módulos individuales en el monómero dependen el uno del otro, se afectan entre sí e interfieren entre sí, lo que resulta en una baja reutilización del código. El desarrollo de nuevas funciones a menudo elige reescribir debido al huevo oculto en la lógica de acoplamiento, ¡que no es lo que queremos ver!

• Confusión lógica

  Además de la confusión lógica causada por el acoplamiento, Atom, como plataforma que creció desde cero, ha acumulado muchas necesidades históricas, algunas ya no se usan y otras casi no se usan. Estas lógicas de código les dan a los desarrolladores una gran cantidad de Desafío: no se atreva a cambiar el código fácilmente mientras mantiene el código. Además, debe ser compatible con versiones anteriores en la iteración, de modo que el servidor tenga una pesada carga histórica.

• Redundancia de código

  Debido a que el marco no definió los estándares de especificación en la etapa inicial, la verificación del código se siguió estrictamente durante el proceso de desarrollo, y la lógica y las constantes del código se definieron repetidamente, lo que también dificultó el mantenimiento del proyecto. La premisa es modificar múltiples lugares al mismo tiempo.

Nuevas metas de arquitectura

De acuerdo con las ventajas y desventajas de la arquitectura original, establecemos los objetivos de esta actualización de arquitectura:

• Modularidad de servicio
• Servicio de generalización
• Sitio de complemento
• Escenario de complemento
• Estándares y especificaciones

Explicación de términos:

• Sitio: desacoplar el servidor de la plataforma, del servicio original como la plataforma, para proporcionar el mismo servicio para múltiples plataformas que están aisladas unas de otras.

• Escenarios: conceptos configurados en respuesta a diferentes tipos de negocios. Los diferentes escenarios tienen diferentes métodos y procesos de gestión.

Arquitectura general

La arquitectura general se divide en 4 partes: capa de aplicación web, capa de interfaz, capa de servicio y capa de datos, por lo que la división puede lograr una entrada unificada, la implementación de un solo punto en la implementación hace que la publicación sea más conveniente, y la implementación independiente reduce el impacto en el servicio general :

• Capa de aplicación web: incluida la plataforma Atom y otras aplicaciones de plataforma
• Capa de interfaz: proporciona servicios de puerta de enlace, y las solicitudes de la capa de aplicación se controlan y reenvían a través de la puerta de enlace
• Capa de servicio:
  • Comunicación de servicio: MQ para comunicación asíncrona y HTTP para comunicación RPC
  • Módulo empresarial: código central, desmantelamiento de muchas aplicaciones de módulos pequeños
  • Servicio básico: control unificado de usuarios y permisos
  • Gestión de servicios: mejorar la estabilidad, robustez y flexibilidad de los servicios.
• Capa de datos: almacenamiento de datos centrales

La puerta de enlace sirve como la entrada de tráfico de todo el servidor, procesa todo el tráfico, intercepta solicitudes ilegales, analiza el estado de inicio de sesión y lo transmite hacia abajo, verifica los permisos de interfaz y las respuestas de tiempo de espera, etc., y los controla de manera uniforme, mientras reduce la presión aguas abajo.

Implementar

Plan / preparación / evaluación

Antes de iniciar oficialmente el desarrollo de la actualización, el equipo discutió la necesidad y la viabilidad de la actualización de la arquitectura a través de una reunión. La razón directa para solicitarnos que realicemos la actualización es los nuevos requisitos del sitio y los requisitos del escenario de la plataforma. Si este requisito se cumple en la arquitectura original, definitivamente será Agregue más lógica de acoplamiento a la lógica caótica original, y la razón indirecta, es decir, la necesidad de actualizar, es hacer que el sistema sea modular, estandarizado y generalizado, aclarar la lógica del sistema y mejorar la capacidad de mantenimiento de todo el sistema. .

Después de nuestra discusión repetida, el sistema original se dividió de acuerdo con las funciones y luego, según las funciones, se dividió aún más de acuerdo con la versatilidad, se agregó el trabajo de soporte de la nueva arquitectura, se evaluó la carga de trabajo y el tiempo estimado de este trabajo, y finalmente se llevaron a cabo las tareas. Se libera la distribución.

Implementar

Modular

¿Por qué modular? A medida que la plataforma se hace más y más grande, queremos hacer que las funciones de cada parte sean más independientes, claras y claras, minimizar el impacto entre cada parte, operar y mantener cada parte por separado, y evitar la situación de tirar de todo el cuerpo de un solo golpe .

Esta actualización divide el proyecto en más de 10 módulos de acuerdo con la función y la versatilidad: como un módulo dedicado a la compilación, un módulo dedicado a la gestión de plantillas, un módulo responsable de las tareas programadas, una puerta de entrada para la entrada, etc.

Entre ellos, se dividen varios servicios generales, que son independientes del sistema Atom y pueden proporcionar servicios para Atom y otros sistemas.

Lo más problemático de desarmar el proyecto es cortar la lógica asociada. La eliminación y reparación del módulo inevitablemente causará un problema: el mismo código aparece repetidamente en diferentes módulos. Para resolver este problema, incluimos algunos de estos códigos en el paquete de herramientas npm. Estos códigos incluyen: constantes, definiciones de tipo de TypeScript, asignación de permisos, definiciones de esquema de mangosta, complementos de Salak y métodos de herramientas, etc.

Otra pregunta es que en la arquitectura original, los módulos pueden ser llamados directamente por código. ¿Cómo "restaurar" esta función en la nueva arquitectura? Para garantizar el grado de desacoplamiento, solo unas pocas funciones en la nueva arquitectura que deben llamarse de inmediato se llaman directamente a través de la interfaz entre los módulos, y el resto se comunican con la base de datos a través de la cola de mensajes MQ.

Para la comunicación MQ, aquí hay un ejemplo: compilar. La compilación del lado del servidor generalmente lleva mucho tiempo, y la ocupación a largo plazo de la conexión afectará el rendimiento del servicio, y el resultado de la compilación no requiere una respuesta sincrónica. Para el módulo de compilación, si el visitante se niega, habrá mucha presión sobre el servicio. Entonces decidimos usar la cola de mensajes para completar la comunicación entre los distintos módulos:

1. El módulo del proyecto llama directamente al módulo de lanzamiento a través de la interfaz para iniciar la operación de lanzamiento;
2. El módulo de publicación empuja un mensaje "Quiero compilar" al grupo de mensajes;
3. Después de que el módulo de compilación recibe el mensaje, juzga si puede ingresar a la compilación por su propia situación, de lo contrario no responderá primero;
4. Cada estado de compilación también es impulsado por mensaje;
5. Finalmente, el módulo del proyecto realiza varios procesamientos después de recibir el mensaje de estado de compilación.

Generalización

Como se mencionó anteriormente, en el trabajo de modularización, desmantelamos cuatro módulos de servicios generales, que son independientes del sistema Atom y pueden proporcionar servicios para Atom y otros sistemas. La generalización del módulo se basa en dos consideraciones:

1. Enriquecer los servicios del departamento y reducir la duplicación de funciones de desarrollo.
2. Elimine el código no esencial de Atom y haga que el sistema sea delgado

Una pregunta que acompaña es digna de nuestra consideración, ¿cómo considerar si una función es digna de generalización? Debemos hacer todo lo posible para evitar caer en un malentendido: la modularización del sistema consiste en desmontar el sistema lo mejor posible. Si la división es demasiado fina, la carga de trabajo de operación y mantenimiento aumentará inevitablemente. Al dividir los módulos, consideramos si las funciones en un módulo son completas e independientes, y la demanda del departamento o la compañía para este servicio común, y realmente alcanzamos un bajo acoplamiento y una alta cohesión .

Estandarización

A nivel de código, la siguiente es una comparación simple:

Contraste	Arquitectura antigua	Nueva arquitectura
Idioma principal	JavaScript	Mecanografiado
Detección de código	Incumplimiento	Requerido
Nombre de la interfaz	Variedad	Forma unificada
Salida de interfaz	Flores florecientes	Forma unificada

TypeScript es bueno. La gente de front-end sabe que nos brinda autocompletado y sistema de tipo opcional, para que podamos usar más funciones nuevas de JavaScript, etc. Para más información, consulte " Por qué elegir TypeScript ". ¿Cuáles son las razones de los siguientes tres puntos? La arquitectura antigua experimentó un proceso de cero a uno. El proyecto carecía de planificación inicial y no tenía tiempo suficiente para corregir el sistema en las etapas media y tardía. El doble papel del tiempo y los cambios en la demanda condujeron a la codificación del código.

Con este fin, hemos enfatizado la estandarización del código en el desarrollo de la nueva arquitectura. Cada presentación debe someterse a una inspección del código y luego a la interfaz unificada de la variedad:

• ruta interfaz unificada: la arquitectura antigua, la ruta puede ser una lista de interfaces /xxx/list, puede ser /xxx/xxxes, y así sucesivamente, nosotros, basado en normas API REST ruta del recurso de sustantivos y semántica del protocolo HTTP se define en la nueva interfaz de arquitectura unificada;
• Nombre del parámetro uniforme: una lista de los parámetros tales como el número de la página que podría llamarse pageSizepuede ser llamado count, por lo ponemos en un nombre unificado, requerido para cumplir la presente convención en desarrollo;
• salida unificada: Los datos de salida a los datos de procesado front-end de pre-selección, incluyendo el sacrificio _idy __vasí sucesivamente datos no relacionados, en forma de salida ha hecho un unificado, todos los requisitos de salida se sustituyen _ID aparecerá en el nombre de identificación, etc.

El beneficio de la estandarización del código es hacer que el código sea más fácil de mantener, los desarrolladores pueden localizar rápidamente el código de interfaz correspondiente y, para el front-end, reduce la memoria de identificación de la interfaz.

Sitio de complemento

Como se mencionó anteriormente, la razón directa de esta actualización de arquitectura son los requisitos del sitio y los requisitos del escenario. Si los requisitos del sitio se repiten bajo la arquitectura anterior, solo aumentará aún más el grado de acoplamiento. Por esta razón, hemos agregado un módulo de administración del sitio, campos del sitio agregados a casi todos los elementos de datos y hemos traído parámetros del sitio a casi todas las consultas de la base de datos. A través de estos esfuerzos, ahora el nuevo sitio solo necesita agregar un nuevo sitio a través del módulo del sitio, y luego hacer una configuración inicial para completar.

Además de los requisitos más altos para las funciones de Atom, el concepto de sitio también plantea nuevos desafíos para el sistema de permisos original. En la versión previa a la actualización, los permisos del usuario son solo un conjunto. Para lograr diferentes permisos para cada sitio, solo hay dos perspectivas:

1. Permiso que significa división (proporcione un conjunto separado de permisos para cada sitio)
2. Los permisos de usuario agregan una capa de abstracción (los permisos de usuario cambian a múltiples colecciones para cambiar según el sitio)

Después de comparar las dos modificaciones, el significado de los permisos divididos es más fácil de entender y el código no ha cambiado mucho. Sin embargo, aumenta en gran medida la dificultad de mantener la tabla de permisos, lo que equivale a agregar un conjunto de permisos para nuevos escenarios, que no se pueden conectar. Finalmente, en la capa de puerta de enlace
, se agrega la lógica para cambiar el conjunto de permisos de acuerdo con el acceso del usuario al sitio .

Escenario de complemento

La escena está a una latitud debajo del sitio. Hay varias escenas importantes de actividades existentes, canales, pruebas de psicología, SNS y tiendas. Si se agrega una nueva escena bajo la arquitectura anterior, debe programarse para su desarrollo, y el código también puede agregar una gran cantidad de diferentes escenarios if-else. Para expandir y mantener la escena de manera más conveniente y sin preocupaciones, desarmamos el código relacionado con la escena desde la perspectiva de la gestión de recursos.

recursos átomo en cada escena tiene principalmente 模板/项目/标签/权限cuatro categorías:

标签       页面
 |         |
模板------>项目

权限     

introduce la estructura del proyecto módulo de directorio, los códigos de proyectos basados módulo de modelo de política de la organización, la lógica de negocio para cada escena dividida en archivos separados, llamados directamente por una lógica de programación para evitar el dopaje los diferentes escenarios.

• El archivo del planificador se llama base_资源_service
• El archivo de estrategia de escena se llama 场景小写_资源_service
• El archivo de política general se llama common_资源_service

Cuando entra un usuario, el planificador llama directamente al método en el archivo de estrategia correspondiente de acuerdo con la condición de consulta ( generalmente, no está permitido llamar directamente a la estrategia de la escena especificada a menos que se confirme que no estará relacionado con los datos de otras escenas ). la próxima estrategia llamará al defecto common_servicelógica, por lo que cada escena necesita heredar common_service. Para los servicios de gestión de la página, por ejemplo, el planificador para el src/service/pagedirectorio base_page_service, la lógica común common_page_service, la lógica escena página del canal ch_page_service.

Por la unidad de los métodos públicos abstractas de escenario, método de servicio CRUD interfaces de uso común colocados en el AbstractServiceClassarchivo

├── src
│   ├── service
│   │   └── {resource}
│   │       ├── base_{resource}_service 策略文件调用器,controller/mq 直接调用
│   │       ├── common_{resource}_service 通用策略文件，例如列表查询共用的参数处理
│   │       └── {scene}_{resource}_service 场景策略文件，场景特殊的

Implementar

Migración de datos

En vista de los cambios drásticos en esta actualización, debemos tener cuidado al cambiar entre las versiones nuevas y antiguas. Además del gran número de ajustes conjuntos realizados por el front-end y el servidor para este propósito, también realizamos la migración de compatibilidad de datos. El método principal es transferir los datos antiguos a través del script de migración. Realice un procesamiento múltiple de acuerdo con las necesidades de la nueva arquitectura y luego escríbala en la nueva base de datos.

Despliegue ininterrumpido

En una arquitectura monolítica, cada implementación de lanzamiento de servicio provocará unos minutos de ventanas vacías.

Para evitar esta situación, en el entorno de producción, nos aseguramos de que cada módulo tenga al menos dos contenedores. Durante la implementación, algunos de los contenedores se eliminan del equilibrio de carga, y luego el contenedor se detecta cíclicamente si hay tráfico, y no se actualiza hasta que no ingrese tráfico. Después de que se inicia la operación, el servicio se agrega nuevamente al equilibrador de carga y luego se realiza la misma operación en los contenedores restantes.La ventaja de esto es que todo el proceso de implementación está garantizado y el servicio es ininterrumpido, evitando lagunas en el proceso de implementación.

O y M

Para evitar repetir la pobre experiencia de operación y mantenimiento y la gestión del código del proyecto bajo la arquitectura anterior, organizamos un documento de operación y mantenimiento para la nueva arquitectura, que incluye detalles de acceso rápido, desarrollo, depuración y despliegue.

Se agregó monitoreo al sistema para monitorear el rendimiento y la disponibilidad de cada interfaz.

Efecto

Después de esta actualización, los resultados planificados se lograron básicamente:

• Claridad: peinado lógico, eliminación de redundancia, reconstrucción de TS, ESNext
• Modularidad: desacople 10+ módulos, opere independientemente; múltiples métodos de comunicación como HTTP, MQ, capa de datos, etc.
• Estandarización: especificación de código fuerte; interfaz unificada; respuesta unificada
• Generalización: 4+ módulos universales, independientes de la plataforma; extraer bibliotecas públicas, configuraciones, complementos, middleware, etc.
• Migración fácil: inicialización de una tecla; implementación de una tecla, punto único, independiente; entrada unificada
• Fácil de expandir: + agregue capacidades de expansión del sitio; ajuste la expansión de la escena; ahorre costos de tiempo de trabajo en un 95% +
• Fácil de mantener: agregue registros; implementación con un clic; implementación ininterrumpida
• Acoplamiento fácil: documentación completa de Joi; registros detallados de cambio de interfaz; tanta compatibilidad hacia arriba como sea posible

Herramientas / Métodos / Colaboración

Las herramientas tienen un impacto muy importante en el buen progreso del proyecto, por lo que en esta actualización, probamos una variedad de herramientas.

Con el fin de garantizar que los miembros del proyecto tengan una comprensión clara de sus propios módulos responsables y una imagen clara de la transformación de los módulos, el equipo introdujo herramientas de diagrama de flujo para clasificar los módulos de la arquitectura antigua y dividir el trabajo, ordenar la lógica dentro de los módulos de la nueva arquitectura, etc.

En términos de programación, utilizamos el diagrama de Gantt en la práctica. El diagrama de Gantt se usó para dividir las tareas de acuerdo con el módulo, y luego se asignó a la persona correspondiente a cargo y establecer la hora programada. El progreso general se sincronizó todos los días. Desde el diagrama de Gantt, puede Una comprensión clara de la asignación y programación de recursos del proyecto, así como la comparación entre el plan del proyecto y la situación real, ayuda a controlar el progreso general del proyecto.

El diagrama de Gantt divide inicialmente la tarea de actualización del proyecto. Para una división más detallada, colocamos IssueBoard . IssueBoard es como una versión simplificada del tablero de tareas, pero es más que suficiente para nosotros. Además, elíjalo La razón también incluye: admite enlaces con git commits, adecuados para que los desarrolladores los usen, y puede cerrar el problema correspondiente con cada commit.

Reflexión resumen

En este proceso de actualización, también se expusieron algunas deficiencias, principalmente reflejadas en la programación y expectativas y en la comunicación temprana.

• Horarios y expectativas

  El programa al comienzo del plan de actualización era demasiado optimista, y no se hicieron más enmiendas durante el proceso de actualización. Por supuesto, esto fue causado por razones objetivas. El equipo debe completar la actualización dentro del período de ventana de demanda limitada para evitar mantener dos versiones al mismo tiempo, lo que conduce La consecuencia es que el equipo debe pasar más tiempo cada día de lo previsto.

• Comunicar

  Cuando se actualizó el servidor, no se comunicaron detalles específicos con el front-end, y esta actualización no es completamente compatible con versiones anteriores, por lo que el front-end causó algunos problemas e inconvenientes durante la depuración conjunta.

Referencia

• Átomo: https://ling.jd.com/atom
• Salak: https://salakjs.github.io/docs/docs/zh-cn/introduction.html
• API RESTful: http://www.ruanyifeng.com/blog/2014/05/restful_api.html

Dirección original: https://aotu.io/notes/2020/04/21/atom-services-upgrade/

---

Bienvenido al blog de Bump Lab: aotu.io

O siga la cuenta pública de AOTULabs (AOTULabs) y envíe artículos de vez en cuando: