Cambios en las estructuras bancarias tradicionales
A principios de la década de 1990, la industria bancaria nacional estaba en auge. A principios de la década de 1990, todas las sucursales llevaban cuentas manualmente y las sucursales provinciales las presentaban periódicamente al sistema de la oficina central. Con el rápido desarrollo de la economía nacional, el volumen de negocios de los bancos también ha aumentado. Este modelo de trabajo ya no puede satisfacer la demanda. Por lo tanto, a principios de la década de 1990, los cuatro principales bancos estatales fortalecieron la inversión en I + D del Ministerio de Ciencia y Tecnología y comenzaron a construir un sistema bancario moderno basándose en la experiencia de construcción del sistema bancario de los Estados Unidos y el Reino Unido. De hecho, en aquella época, todo el mundo todavía no estaba muy familiarizado con las computadoras. Hay computadoras instaladas en cada mostrador. El sistema de contador en ese momento era un modo de línea de comando unificado sin interfaz visual. El sistema back-end adopta una arquitectura centralizada, como se muestra en la siguiente figura:
El sistema bancario en ese momento tenía básicamente una estructura tan centralizada, y los grandes bancos estatales generalmente tenían una estructura tan simple. Los sistemas de la mayoría de las industrias de aquella época también estaban estructurados de esta manera. Bajo esta arquitectura, los sistemas front-end y back-end del mostrador adoptan la arquitectura CS y el modo de cliente pesado. Cada actualización de cliente requiere que el paquete de instalación se envíe a todos los puntos de venta con un día de anticipación, lo que parece ser relativamente bajo ahora. El backend del banco es un modelo central grande, es decir, el sistema central asume las funciones principales de cuentas, depósitos y préstamos, libro mayor, conciliación, pago, cobro y otras funciones en el sistema central grande centralizado. Están separados del sistema central y pertenecen al sistema periférico. Estos sistemas periféricos son generalmente productos listos para usar proporcionados por algunas empresas de software en el mercado. Solo requieren un desarrollo secundario simple para satisfacer las necesidades. Por un lado, reduce el costo de desarrollo y, por otro, también lo acelera. el progreso de la implementación del sistema. Sin embargo, la capacidad de carga del sistema de esta arquitectura es todavía relativamente limitada. Con el rápido aumento del volumen de transacciones, pronto resultó imposible satisfacer la demanda. Al escuchar la escena presentada por las personas mayores del banco, su departamento de ciencia y tecnología estaba muy ocupado todos los días y el volumen de transacciones aumentaba significativamente cada mes. La acumulación de intereses trimestral y la liquidación de fin de año mantendrán a todos ocupados toda la noche. Estos recuerdos también se han convertido en recuerdos dolorosos para todos los banqueros de esa época.
Los sistemas centralizados gradualmente han sido incapaces de satisfacer las necesidades comerciales en rápido crecimiento, por lo que los bancos estatales relativamente grandes han comenzado a considerar implementar un sistema centralizado existente desde la oficina central en cada sucursal provincial y luego agruparlo en lotes. todas las noches Centralizar datos provinciales. Esta arquitectura puede resolver los problemas de rendimiento en línea lo más rápido posible, pero también generará nuevos problemas, es decir, las transacciones de transferencias interprovinciales no se pueden recibir en tiempo real e incluso las transferencias interprovinciales del mismo banco generalmente no son posibles. . Por lo tanto, el diagrama de arquitectura del sistema de mediados a finales de la década de 1990 es el que se muestra a continuación:
Mirando la imagen, podemos encontrar que la principal diferencia con la arquitectura anterior es ajustar la arquitectura de implementación centralizada de la oficina central a la arquitectura distribuida de cada provincia, pero esta arquitectura distribuida no es la arquitectura distribuida de Internet que estamos discutiendo ahora. No existía una solución de arquitectura distribuida madura en ese momento, por lo que la arquitectura distribuida en ese momento en realidad simplemente implementaba un conjunto. de sistemas centrales y sistemas de apoyo en cada departamento provincial de ciencia y tecnología. Los sistemas periféricos se operan y mantienen de forma independiente. Es como si la organización estuviera integrada en términos de relaciones administrativas generales, pero los sistemas tecnológicos reales estuvieran separados y no tuvieran ninguna conexión necesaria. Todos los días solo se realiza el intercambio de datos para realizar transferencias interprovinciales, aceptación de facturas y otros servicios. Por lo tanto, muchos servicios bancarios son relativamente ineficientes y difíciles de satisfacer algunas necesidades urgentes de los clientes. Finalmente algo sucedió. Para que los clientes puedan enviar dinero a clientes de otras provincias, la forma más rápida es retirar primero efectivo con su tarjeta local y luego transferirlo a otro lugar. Un amigo le preguntó por qué no iba al área local.
Con el rápido desarrollo de Internet en 2000, el nivel tecnológico de los bancos también se ha desarrollado rápidamente en los últimos años, y los niveles de varios bancos se han expandido gradualmente. Los problemas comerciales del despliegue distribuido en provincias antiguas se han ido haciendo evidentes gradualmente. El ICBC tomó la iniciativa en la integración de los sistemas bancarios provinciales anteriormente dispersos desde su oficina central. El sistema de recaudación no es tan sencillo.
¿Por qué se desplegaron las provincias por separado? Es precisamente porque la arquitectura del sistema centralizado ya no puede manejar el rápido desarrollo del volumen de negocios diario. Si los datos de cada provincia se recopilan nuevamente, significa que el lote principal puede agotarse y distribuirse al sistema periférico antes de que pueda abrirse al día siguiente. Para lograr esto, el departamento de ciencia y tecnología todavía está bajo una gran presión y necesita resolver muchos problemas, incluidos principalmente los siguientes: 1) estructura de datos unificada, mapeo de datos, recopilación de datos provinciales y migración de datos; 2) desarrollo de nuevos sistemas; 3) sistema El impacto de la cobranza en el negocio diario de la provincia de cobranza; 4) Capacitación sobre el nuevo sistema para los empleados de la sucursal; 5) Migración fluida de los sistemas antiguos y nuevos e interacciones diarias de compatibilidad entre los sistemas antiguos y nuevos; plan de migración y plan de retirada. Tuve la suerte de vivir este proceso en el Banco de China. Todo el proceso duró casi cuatro años, desde el diseño general de la solución hasta la implementación del sistema y la posterior migración y lanzamiento del sistema. Este proceso fue muy difícil y trabajar horas extras básicamente se convirtió en la norma, pero también aprendí mucho durante este proceso y también fue un período de rápido crecimiento. Una idea arquitectónica central de toda la transformación es adelgazar y simplificar el sistema central para mejorar el rendimiento del procesamiento comercial del sistema central, comprar la última computadora central para garantizar el rendimiento del procesamiento y el rendimiento de E/S, y separar la mayoría de las empresas del sistema central. . Básicamente, esta estructura general puede garantizar el desarrollo empresarial en los próximos 65.438+00-20 años en el momento de la evaluación. La siguiente imagen es la arquitectura general en ese momento, pero a partir de esta arquitectura podemos encontrar que el sistema central, el sistema periférico y el sistema de canales de la arquitectura general son muy caóticos. Cada sistema está completamente entrelazado. porque el dibujo estaba completo, era básicamente invisible después de eso, era una telaraña muy complicada. Debido a que algunos sistemas están subcontratados y la estructura de mensajes es diferente de la de otros sistemas, una vez que un sistema quiere conectarse a estos sistemas externos, encontrará ese problema y necesitará procesar todos los mensajes de estas interfaces externas, lo que genera muchas complicaciones. duplicación.
La mayoría de los bancos se dieron cuenta rápidamente de las deficiencias de esta arquitectura de red centralizada, y la arquitectura de bus ESB resultó ser popular en ese momento, por lo que los sistemas bancarios inevitablemente implementaron el bus ESB. La arquitectura del bus consiste en establecer un puente de bus ESB entre el sistema de canales y los sistemas central y periférico. Todas las interfaces de los sistemas periféricos y centrales están registradas y publicadas en el bus ESB. El bus proporciona un protocolo estándar de interfaz completamente unificado, lo que evita la necesidad de que cada sistema acceda al mismo conjunto de interfaces estándar y no necesita repetir diferentes protocolos de mensajes. . Esta arquitectura parece muy refrescante y es conveniente que el sistema de canales y los sistemas periféricos llamen a las interfaces de cada sistema. Esta arquitectura se ha implementado en el sistema bancario durante mucho tiempo y la mayoría de los bancos todavía utilizan este modelo de arquitectura. Aunque ahora parezca normal, en aquel momento esta arquitectura parecía perfecta. Y esta estructura es muy adecuada incluso para los bancos pequeños y medianos.
Con el desarrollo de Internet, la banca en línea, la banca móvil y la banca directa se han convertido en nuevos canales, y la gente ha comenzado a aceptar rápidamente este canal emergente de Internet. La mayor diferencia entre la arquitectura del bus de Internet y la arquitectura anterior es la arquitectura de seguridad. Más adelante escribiré dos artículos separados sobre seguridad. Otros aspectos de la arquitectura permanecen básicamente sin cambios, pero encontraremos un fenómeno que debido a que el sistema central no agrega funciones importantes, constantemente se agregan nuevos productos periféricos. En ese momento, el Banco de China tenía más de 100 sistemas periféricos, sin contar algunos sistemas que estaban a punto de desconectarse. A medida que el volumen de negocios continúa aumentando, el volumen de negocios del sistema central es cada vez mayor, la presión sobre el autobús aumenta gradualmente y la máquina del autobús también se expande continuamente horizontalmente. Antes de partir, el grupo de autobuses se había ampliado a 100 nodos.
Después de 2012, con el gran éxito de las plataformas abiertas de Facebook y Amazon, BAT abrió gradualmente sus propias interfaces e implementó la estrategia de ecosistema de plataforma abierta, promoviendo así un desarrollo más rápido de los servicios SOA. El banco ha estado estudiando opciones de implementación para el servicio. Sin embargo, dado que la arquitectura del bus ESB funciona de manera muy estable y no tiene problemas, los bancos no están muy motivados para transformar sus servicios. Además, este ajuste de la arquitectura general implica un impacto departamental y comercial muy grande, incluso para bancos relativamente seguros como los bancos generales. La empresa tampoco se atreve a hacer grandes movimientos. Tuve la suerte de ponerme al día con el programa piloto de finanzas por Internet del Banco de China en el banco e implementar una arquitectura orientada a servicios para el recién construido sistema financiero de Internet. La siguiente es la estructura de servicios financieros por Internet del Banco de China en ese momento, que en realidad es una estructura de compromiso de las finanzas bancarias por Internet tradicionales.
Como se puede ver en el diagrama de arquitectura, el lado izquierdo es la arquitectura de bus centralizada tradicional del banco, y el lado derecho es la arquitectura de servicios de Internet, incluida la plataforma abierta, el registro y descubrimiento de servicios y el servicio. sistema de producto. ¿Por qué está diseñado de esta manera? Esto se debe a que los sistemas de productos de los bancos tradicionales son relativamente estables. Todos los estudiantes que han ingresado al sistema bancario saben que a los bancos tradicionales les lleva mucho tiempo establecer un nuevo sistema o realizar una nueva demanda. Los bancos tradicionales utilizan un método de desarrollo en cascada y varios procesos de revisión y aprobación. Como resultado, básicamente pasan tres meses desde la solicitud hasta el lanzamiento de la función, y la eficiencia sigue siendo bastante baja. Era completamente incapaz de satisfacer las necesidades de iteración rápida de las finanzas de Internet, porque en ese momento no solo probamos una nueva arquitectura SOA, sino que también pusimos a prueba el desarrollo iterativo. Por lo tanto, los productos financieros de Internet se implementan y despliegan por separado. Si el sistema del producto implica llamar a interfaces de productos bancarios tradicionales, entonces todas las interfaces del sistema de productos bancarios tradicionales se llaman a través del bus ESB. Todos los sistemas de productos financieros de Internet tienen interfaces registradas con el centro de registro de servicios. En ese momento, todos nuestros sistemas de productos financieros de Internet se desarrollaron en base al dubbo de Alibaba y todas las interfaces se registraron en zookeeper. La interacción de servicio directa entre los dos sistemas adopta el modo RPC. Al proporcionar exposición de interfaz a través de una plataforma abierta, se puede encontrar que esta arquitectura no solo puede garantizar la estabilidad del sistema bancario tradicional, sino también satisfacer la rápida implementación iterativa de las necesidades financieras mutuas y también puede utilizar tecnologías distribuidas de Internet emergentes para reducir costos de desarrollo y operación y mantenimiento. En la actualidad, muchos bancos que conozco están utilizando esta arquitectura para implementar servicios financieros de Internet.
En los últimos dos años, con el desarrollo continuo de la tecnología de contenedores, las plataformas de nube privada y devops se han ido poniendo a prueba gradualmente en los sistemas bancarios. Actualmente, un pequeño banco privado donde trabajo está probando esta tecnología. Docker se utiliza para la gestión, construcción y lanzamiento de imágenes subyacentes, y el nivel del sistema adopta una arquitectura integral orientada a servicios. Actualmente estamos utilizando la solución general de springcloud. Esta arquitectura también parece muy clara, altamente escalable y puede satisfacer las necesidades del desarrollo empresarial futuro. A medida que la tecnología Docker siga madurando, los desarrollos posteriores reemplazarán gradualmente la mayoría de las operaciones y el mantenimiento manuales. Una empresa de comercio electrónico de Internet para la que trabajé antes tenía solo tres personas de operación y mantenimiento para más de 80 sistemas de productos. El monitoreo diario y la implementación de versiones estaban completamente automatizados, básicamente sin necesidad de intervención manual. Este modelo es también el método de desarrollo, operación y mantenimiento que los bancos necesitarán en el futuro.
Hoy sólo presentaré brevemente los cambios históricos del sistema bancario. En realidad es sólo una breve introducción. De hecho, cada edificio tiene muchas historias y puedo escribir muchas. Escribiré muchos detalles sobre lo que pasó cuando tenga tiempo en el futuro :)