1990 년대 초에 국내 은행업이 왕성하게 발전하였다. 90 년대 초, 모든 지점은 수작업으로 기재되어 있으며, 성급 지점이 정기적으로 본점 시스템에 제출한다. 국내 경제가 급속히 발전하면서 은행의 업무량도 급증했다. 이 작업 모델은 더 이상 수요를 충족시킬 수 없습니다. 이에 따라 1990 년대 초 4 대 국유은행은 과학기술부의 R&D 투자를 강화하고 미국과 영국의 은행체계 건설 경험을 참고해 현대은행체계를 구축하기 시작했다. 사실 그때 컴퓨터에 대한 사람들의 인상은 여전히 낯설었다. 각 카운터마다 컴퓨터를 설치했습니다. 당시 카운터 시스템은 통합 명령줄 모드였으며 시각적 인터페이스가 없었습니다. 백그라운드 시스템은 다음 그림과 같이 중앙 집중식 아키텍처를 사용합니다.
당시 은행체계는 기본적으로 이런 집권 구조였으며, 대형 국유은행도 일반적으로 이런 간단한 구조였다. 당시 대부분의 업계의 시스템도 이런 구조였다. 이 아키텍처에서 카운터의 프런트 엔드 및 백 엔드 시스템은 CS 아키텍처와 통통한 클라이언트 모델을 채택하고 있으며, 각 클라이언트 업그레이드마다 하루 전에 설치 패키지를 모든 지점으로 미리 전송해야 하는데, 지금은 비교적 낮은 것 같습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 은행 배경은 주요 핵심 모델입니다. 즉, 핵심 시스템이 주요 기능을 수행합니다. 계정, 예금 대출, 총계정 원장, 조정, 지불, 수금 등의 기능은 모두 중앙 집중식 대형 핵심 시스템에 있습니다. 핵심 시스템에서 몇 가지 기능만 분리되어 주변 시스템에 속합니다. 이러한 주변 시스템은 일반적으로 시장의 일부 소프트웨어 회사에서 제공하는 기성품으로, 간단한 2 차 개발만으로 수요를 충족시킬 수 있으며, 개발 비용을 절감하고 시스템 구현 진도를 가속화합니다. 그러나이 아키텍처의 시스템 운반 능력은 여전히 제한적입니다. 거래량이 급속히 증가함에 따라 곧 수요를 충족시킬 수 없게 되었다. 그해 은행의 선배가 소개한 장면을 듣고, 그들의 과학기술부는 매일 바빠서 매달 거래량이 크게 증가할 것이다. 매 분기의 이자일배치와 연말 결산은 모두를 밤새도록 바쁘게 할 것이다. 이 기억들은 또한 그 시대의 모든 은행가들의 고통스러운 기억이 되었다.
중앙 집중식 시스템은 빠르게 증가하는 비즈니스 요구를 점차 충족시킬 수 없게 되면서 상대적으로 규모가 큰 국유은행이 각 성급 지점에 1 본점의 기존 중앙 집중식 시스템을 배치하고 매일 밤 주정부 데이터를 대량으로 집중시키는 것을 고려하기 시작했다. 이 아키텍처는 온라인 성능 문제를 가장 빨리 해결할 수 있지만, 지방간 이체 거래는 실시간으로 입금할 수 없고, 같은 은행의 지방간 이체도 일반적으로 할 수 없다는 새로운 문제도 야기할 수 있다. 따라서 1990 년대 중반과 후반의 시스템 아키텍처 다이어그램은 다음 그림과 같습니다.
그림을 보면 본사의 중앙 집중식 배포 아키텍처를 각 성의 분산 아키텍처로 조정하는 것이 이전 아키텍처와의 주요 차이점이라는 것을 알 수 있습니다. 그러나 이 분산 아키텍처는 우리가 현재 논의하고 있는 인터넷 분산 아키텍처가 아니며, 당시에도 성숙한 분산 아키텍처 방안이 없었습니다. 따라서 당시의 분산 아키텍처는 실제로는 각 성 과학기술청에 핵심 시스템 세트와 보조 주변 시스템을 별도로 배치하고 독립적으로 유지 보수하는 것입니다. 이것은 마치 기관이 전체 행정 관계에서 일체인 것처럼 보이지만, 실제 과학 기술 시스템은 분리되어 있어 필연적인 연계가 없다. 매일 데이터 교환만 하고, 지방간 이체, 어음 수락 등의 업무를 실현하기 때문에 많은 은행 업무가 비효율적이어서 긴급한 고객 요구를 충족시키기가 어렵다. 마침내 몇 가지 현상이 나타났다. 고객이 지방 간 고객에게 송금하기 위해 가장 빠른 방법은 현지 카드로 현금을 인출한 다음 인육을 다른 곳으로 옮기는 것이다. 친구가 그에게 왜 현지에 가지 않는지 물었다.
2000 년 인터넷의 급속한 발전에 따라 최근 몇 년 동안 은행의 과학 기술 수준도 급속히 발전하여 각 은행의 수준이 점차 높아지고 있다. 구 성의 분산 배치 업무 문제가 점차 두드러지고 있다. 공행은 먼저 본점에서 이전에 흩어져 있던 성행 시스템을 모았다. 수집 시스템은 그렇게 간단하지 않습니다. 왜 그해 각 성이 별도로 배치되었습니까? 집중화된 시스템 아키텍처가 더 이상 일일 업무량의 고속 발전을 수용할 수 없기 때문이다. 각 지방의 데이터를 다시 한 번 수집하면 핵심 배치가 소진되어 주변 시스템에 배포되는 다음날에 영업할 수 있다는 뜻입니다. 이를 위해 과학기술부의 압력은 여전히 크며 1) 통합 데이터 구조, 데이터 매핑, 각 성의 데이터 수집, 데이터 마이그레이션 등 많은 문제를 해결해야 합니다. 2) 새로운 시스템 개발; 3) 수집 지방의 일상 업무에 대한 시스템 수집의 영향; 4) 지사 직원을위한 새로운 시스템 교육; 5) 신규 및 기존 시스템의 원활한 마이그레이션 및 신규 및 기존 시스템 간의 일상적인 호환성 상호 작용 6) 전체 생산 이전 계획 및 철수 계획. 나는 당시 중국 은행에서 이 과정을 경험한 특권을 누렸다. 전체 프로세스는 전체 시나리오 설계에서 시스템 구현, 후속 시스템 마이그레이션 및 온라인에 이르기까지 거의 4 년 동안 지속되었습니다. 이 과정은 매우 어렵고, 기본적으로 야근을 하는 것이 정상이지만, 나도 이 과정에서 많은 것을 배웠고, 빠르게 성장하는 시기이기도 하다. 전체 개조의 핵심 아키텍처 아이디어 중 하나는 핵심 시스템의 살을 빼고 간소화하여 핵심 시스템의 업무 처리 처리량을 높이고, 최신 메인프레임을 구입하여 처리 성능과 IO 성능을 보장하고, 대부분의 업무를 핵심 시스템에서 분리하는 것입니다. 기본적으로 이러한 전체 아키텍처는 평가 시 향후 65,438+00-20 년간의 비즈니스 발전을 보장합니다. 아래 그림은 당시의 전체 구조였지만, 이 아키텍처에서 볼 수 있듯이 전체 아키텍처의 핵심 시스템, 주변 시스템, 채널 시스템은 매우 혼란스럽고, 각 시스템은 완전히 메쉬되어 있고, 화면은 아직 완전히 그려지지 않았다. 그림을 그린 후 기본적으로 볼 수 없고, 매우 복잡한 거미줄이기 때문이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 예술명언) 일부 시스템은 아웃소싱되고 메시지 구조는 다른 시스템과 다르기 때문에 한 시스템이 이러한 외부 시스템에 연결되면 이러한 문제가 발생하고 이러한 외부 인터페이스에 대한 모든 메시지를 처리해야 하므로 많은 반복 작업이 발생합니다.
대부분의 은행들은 이러한 중앙 집중식 네트워크 아키텍처의 결함을 빠르게 인식하고 있으며, ESB 버스 아키텍처는 당시 유행했기 때문에 은행 시스템은 불가피하게 ESB 버스를 실현했습니다. 버스 아키텍처는 채널 시스템과 코어 및 주변 시스템 사이에 ESB 버스 브리지를 구축하는 것입니다. 주변 및 핵심 시스템의 모든 인터페이스는 ESB 버스에 등록 및 게시되며, 버스는 완전히 통합된 인터페이스 표준 프로토콜을 제공하므로 각 시스템이 동일한 표준 인터페이스 세트에 액세스할 필요가 없으므로 서로 다른 메시지 프로토콜을 반복할 필요가 없습니다. 이 아키텍처는 상쾌해 보이며 채널 시스템과 주변 시스템이 각 시스템의 인터페이스를 호출하는 것이 편리합니다. 이 아키텍처는 대부분의 은행이 여전히 이 아키텍처 모델을 채택하고 있는 것을 포함하여 은행 시스템에서 오랫동안 구현되어 왔습니다. 지금은 평범해 보이지만, 당시 보기에 이런 구조는 이미 완벽했다. 그리고 이런 구조는 지금도 중소 은행 사용에 매우 적합하다.
인터넷이 발달하면서 인터넷은행, 휴대전화 은행, 직판은행이 새로운 채널이 되면서 이 새로운 인터넷 채널을 빠르게 수용하기 시작했다. 문장 버스 아키텍처와 이전 아키텍처의 가장 큰 차이점은 보안 아키텍처이며, 이후 보안에 관한 두 개의 네트워크를 별도로 작성한다는 것입니다. 아키텍처의 다른 측면은 기본적으로 변하지 않지만 핵심 시스템이 큰 기능을 추가하지 않기 때문에 새로운 주변 제품을 지속적으로 추가하는 현상을 발견할 수 있습니다. 당시 중국은행에는 100 여 개의 주변 시스템이 있었는데, 아직 곧 오프라인이 될 시스템이 아니다. 업무량이 늘어남에 따라 핵심 시스템의 업무량이 점점 커지고, 버스의 압력도 점차 증가하고 있으며, 버스 기계도 계속 가로로 확장되고 있다. 떠나기 전에 버스 클러스터가 100 개 노드로 확장되었습니다.
20 12 이후 페이스북과 Amazon 오픈 플랫폼의 큰 성공으로 BAT 는 자체 인터페이스를 개방하고 오픈 플랫폼 생태계 전략을 구현함으로써 SOA 서비스의 빠른 발전을 추진했습니다. 은행은 그동안 서비스 실시 방안을 연구해 왔다. 하지만 ESB bus 아키텍처는 매우 안정적이고 문제가 없기 때문에 각 은행의 서비스 전환에 대한 동력은 그리 강하지 않으며, 이러한 전체 아키텍처 조정에는 매우 큰 부서와 업무 영향이 관련되어 있으며, 일반 은행처럼 비교적 안전한 회사도 큰 조치를 취하지 못하고 있다. 다행히 은행에서 중국은행의 인터넷 금융 파일럿을 따라잡아 새로 지은 인터넷 금융 시스템에 서비스 지향 아키텍처를 도입했다. 다음은 당시 중국은행의 인터넷 금융 서비스 구조였으며, 실제로는 전통은행 인터넷 금융의 절충구조였다.
구조도에서 볼 수 있듯이 왼쪽에는 은행의 전통적인 중앙 집중식 버스 아키텍처가 있고 오른쪽에는 오픈 플랫폼, 서비스 등록 및 검색, 서비스 제품 시스템을 포함한 인터넷 서비스 아키텍처가 있습니다. 왜 이렇게 디자인해야 합니까? 이는 전통은행의 제품체계가 비교적 안정적이기 때문이다. 은행체계에 진출한 모든 학생들은 전통은행이 새로운 체계를 세우거나 새로운 수요를 실현하는 데 오랜 주기가 필요하다는 것을 알고 있다. 전통적인 은행은 폭포수 개발 방식이며, 다양한 감사 승인 프로세스로 인해 수요 제기에서 기능선에 이르기까지 기본적으로 3 개월이 걸리며 효율성이 떨어집니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 당시 우리는 새로운 SOA 아키텍처뿐만 아니라 반복 개발도 시범 실시했기 때문에 인터넷 금융의 빠른 반복에 대한 요구를 전혀 충족시킬 수 없었습니다. 따라서 인터넷 금융 상품은 별도로 구현되고 배치됩니다. 제품 시스템에 기존 은행 제품 인터페이스 호출이 포함된 경우 모든 기존 은행 제품 시스템 인터페이스는 ESB 버스를 통해 호출됩니다. 모든 인터넷 금융 상품 시스템은 서비스 등록 센터에 인터페이스를 등록했다. 당시 우리의 모든 인터넷 금융 상품 시스템은 알리바바의 dubbo 를 기반으로 개발되었고, 모든 인터페이스는 zookeeper 에 등록되어 있었다. 두 시스템 간의 직접 서비스 상호 작용은 RPC 모드를 사용합니다. 오픈 플랫폼을 통한 인터페이스 노출을 통해 이 아키텍처는 기존 은행 시스템의 안정성을 보장하고 상호 금 수요의 신속한 반복 구현을 보장할 수 있으며, 새로운 인터넷 분산 기술을 활용하여 개발 및 운영 비용을 절감할 수 있습니다. 현재 내가 알고 있는 많은 은행들이 인터넷 금융 서비스를 실현하기 위해 이런 구조를 채택하고 있다.
최근 2 년 동안 컨테이너 기술이 발달하면서 프라이빗 클라우드 플랫폼과 devops 가 은행 시스템에서 파일럿을 진행하고 있습니다. 현재 내가 있는 작은 민영은행이 이 기술 시범을 진행하고 있다. Docker 는 기본 미러 관리, 구축 및 게시에 사용되며, 시스템 레벨은 포괄적인 서비스 지향 아키텍처를 사용합니다. 현재 우리는 springcloud 의 전체 솔루션을 사용하고 있다. 이 아키텍처는 명확하고 확장성이 뛰어나 향후 비즈니스 발전의 요구를 잘 충족할 수 있습니다. Docker 기술이 성숙해짐에 따라 후속 devops 가 대부분의 수동 운영 및 유지 관리를 점차 대체하게 됩니다. 내가 전에 머물렀던 한 인터넷 전기 회사, 80 여 개 제품 시스템에는 3 명의 운영 및 유지 관리 인력만 있었고, 일상적인 모니터링 및 버전 배포는 모두 자동화되어 있어 수작업이 거의 필요하지 않았다. (윌리엄 셰익스피어, 윈스턴, 컴퓨터명언) (윌리엄 셰익스피어, 윈스턴, 컴퓨터명언) 이 모델은 후속 은행이 필요로 하는 개발 및 운영 방식이기도 하다.
오늘 저는 단지 은행 시스템의 역사적 변화를 간단히 소개하겠습니다. 정말 간단한 소개일 뿐이에요. 사실, 모든 건물에는 많은 이야기가 있습니다. 나는 많은 것을 쓸 수 있습니다. 앞으로 시간이 있으면 나는 발생한 세부 사항을 많이 쓸 것이다:)